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

Text File | 1993-12-31 | 321.0 KB | 7,418 lines

1-May-89 02:15:13-MDT,2306;000000000000
Return-Path: <[e-mail]>
Date: Mon,  1 May 89 01:30:18 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #118
To: [e-mail]

PACKET-RADIO Digest         Mon,  1 May 89       Volume 89 : Issue 118

Today's Topics:
            "Wormhole" connections
              Coastguard Packet
----------------------------------------------------------------------

Date: 30 Apr 89 02:41:37 GMT
From: encore!cloud9!jjmhome![e-mail]  (Dave Pascoe KM3T)
Subject: "Wormhole" connections

Is anyone familiar with the various "wormhole" packet radio connections in
North America?  I am familiar with the one between Ontario and Alberta and
the one between Washington, D.C. and Minnesota.  There used to be one between
Washington and San Francisco but that is long gone.  I am just wondering if
there are any other ones out there.

For those not familiar, a "wormhole" connection is one which carries packet
transmissions between two distant points using a private commercial
transmission medium, such as a spare satellite channel.

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

Date: 30 Apr 89 18:43:37 GMT
From: texbell!bigtex!helps!bongo![e-mail]  (julian macassey)
Subject: Coastguard Packet

    In the June 1989 issue of Popular Communications (Page 42) is a piece
about the Coastguard using packet. Here is the item:

"
    One day recently, Kenneth MacLeod of Washington State turn on his ICOM
IC-R7000 scanning receiver and tuned to 171.155 MHz, where he picked up a
1200-baud packet radio transmission of the U.S. Coast Guard. He monitored
NAVH, USCGC Pont Bennett and NMW47, USCG, Bellinham, WA., exchanged traffic
between 0130 and 0200 UTC.

    Ken would like to hear from any of you who may have piked(sic) up
similar transmissions on 171.155 where you live. You may write him at P.O.
Box 2495, Friday Harbour, WA 98250.

"
Yours
--
Julian Macassey, n6are  julian@bongo    ucla-an!denwa!bongo!julian
n6are@wb6ymh (Packet Radio) n6are.ampr.org [44.16.0.81] voice [phone]

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

End of PACKET-RADIO Digest
******************************
 1-May-89 11:16:08-MDT,20099;000000000000
Mail-From: KPETERSEN created at  1-May-89 11:05:23
Return-Path: <[e-mail]>
Date: Mon,  1 May 89 11:05:22 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #119
To: [e-mail]

PACKET-RADIO Digest         Mon,  1 May 89       Volume 89 : Issue 119

Today's Topics:
  FCC's recognition of repeater coordination is a disaster (2 msgs)
       FCC's recognition of repeater coordinators is a disaster
            PACKET-RADIO Digest V89 #115
----------------------------------------------------------------------

Date: 1 May 89 12:07:52 GMT
From: sun-barr!male!pitstop!texsun!texbell!splut![e-mail]  (Jay "you ignorant splut!" Maynard)
Subject: FCC's recognition of repeater coordination is a disaster

In article <[e-mail]> [e-mail] (Bert Campbell) writes:
>In article <[e-mail]> [e-mail] (Jay "you ignorant splut!" Maynard) writes:
>>Nope...first-come, first-served is nothing more than objective, and a
>>realization of the simple fact that it's next to impossible to move or
>>shut down a repeater without the consent of the trustee. Given that,
>>it's only common sense to implement rules that will be respected and
>>work.
>The question is "accepted by who" and "define working".  I contend
>that the "no value judgement" agrument is at best a shirking of
>responsibility on the part of the coordination organization, and at worst
>just a red herring to maintain the status quo.  The idea that no consensus
>can be reached regarding what is fair is preposterous.  Of course everyone
>can't have his/her way, but most amateurs I've dealt with are a fairness-
>minded lot who will operate within the rules if they are percieved fairly
>grounded.  I really doubt if the majority of amateurs believe that the
>current system of "get a channel now, it's yours forever" is realistic
>or fair.

It may not be totally fair, but it is, and will be, perceived as more
fair than any other way to assign pairs that people have come up with.
Accepted by who? By our membership, and the amateur community at large.
There has been no groundswell of opinion that the rules need to be
changed. Working? I won't argue that there are problems, but I contend
that there would be far more problems under any system that set
priorities and made some repeaters shut down or share frequencies -
because there will be no consensus as to exactly what those priorities
are. If you think that some consensus could be reached, I suggest you
come to the next Society general meeting (August 4-6, 1989, in Austin),
and propose a system that you think is fair.

>The band plan itself is a huge exercise in value judgement.  This much
>space for packet, this much for satellite, this much for reteaters, etc.
>Are we supposed to believe that the band plan(s) can never be changed
>because that would involve a "value judgement"?  Do the frequency
>coordination organizations have any input on the "official" band plan?
>What are they going to do when space for voice repeaters or other "modes"
>is reduced to make way for new patterns of activity?   I always try to
>follow band plan guidelines, and find that most amateurs do also.

The band plan we have on two meters was originally written by the Texas
VHF-FM Society. It was adopted nationally, by general consensus.
Subsequent changes have been made, primarily by the ARRL's VHF Repeater
Advisory Committee and VHF/UHF Advisory Committee. There are constant
proposals for change, the most recent being a proposal from an ATV group
to allocate 420-444 MHz for ATV, conveniently forgetting the 432 and 435
MHz weak-signal segments and the repeaters with inputs or outputs
(depending on the state) from 442-444 MHz. Most of these don't go much
of anywhere.
Changing a band plan to reduce the amount of spectrum available to
repeaters, in the absence of significant external force (such as the
220-222 MHz theft), is a political blunder simply because that kind of
thing will get ignored - it will involve a revocation of a coordination
due to no fault of the trustee. We've had to do a massive sales job to
those repeaters that would be moved from the lower 200 kHz of the 220
repeater band to get them to move if/when the FCC finalizes the grab; I
think they'll all move, but I'm not certain.

>I didn't get Mr Maynard's response to my last posting about repeater
>inequities, (news problems in TX) but did see a portion of it in
>someones reponse to his response (whew)...  As usual the point is
>missed, turning the machine off would be fine.

Turning what machine off? If you're saying that telling a trustee to
turn his machine off will work, and such a request would be honored,
then I invite you to put yourself in the shoes of someone who's spent
$2000, and a couple of man-years, on a repeater who's been told to shut
it off to make room for someone who wants to use packet. Will you
listen? Experience tells me others in similar situations have not.

--
Jay Maynard, EMT-P, K5ZC, PP-ASEL   | Never ascribe to malice that which can
uucp:        uunet!nuchat!   (eieio)| adequately be explained by stupidity.
    hoptoad!academ!uhnix1!splut!jay +----------------------------------------
{killer,bellcore}!texbell!          | "Less great!" "Tastes filling!"

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

Date: 1 May 89 12:25:39 GMT
From: sun-barr!male!pitstop!texsun!texbell!splut![e-mail]  (Jay "you ignorant splut!" Maynard)
Subject: FCC's recognition of repeater coordination is a disaster

In article <[e-mail]> [e-mail] (Fred R. Goldstein k1io) writes:
>In article <[e-mail]> [e-mail] (Jay "you ignorant splut!" Maynard) writes:
>>In article <[e-mail]> [e-mail] writes:
>>>2. "No benefit is enough to put up with repeater wars".
>>An accurate summation. So far, only Fred Goldstein has disagreed with
>>it.
>And not an accurate summation of my position, either.

OK, what is?

>A quiet night on 20M is far more prone to QRM than any "repeater war"
>except for intentionally malicious ones.

That's where we differ: Any repeater war involves malicious interference.

>Repeater frequency conflicts (pre-Gosrepeater) occur in two modes.
>One is the all-out "repeater war", when one group intentionally tries
>to clobber another one.  This is quite rare, and typically falls under
>the rubric "malicious interference".  Thus it is not prevented by
>coordination; previous rules prevented it, and coordination is a
>secondary issue.  I don't think this is a good way to use the spectrum
>either, unless the two groups involved are willing to do it as, say,
>a test of interference-reduction technology.  And that's not the norm!

This is exactly what I refer to when I say "repeater war". Any
coordination conflict can, and usually will, result in this kind of
disreputable state of affairs. This is the kind of thing that led to
frequency coordination in the amateur service in the first place. This
kind of thing is why frequency coordination is used by the amateur
community: because they had it, and don't want it any more.

>But the second kind of "repeater war" is the incidental conflict, when
>two repeaters overlap in coverage the way DC band users hear each other
>without killing the QSO. [...]

You're the only person I've ever seen who calls this a repeater war.
Even this level of interference causes problems: witness the discussion
I've been having with AA5AV here about just such a conflict.
Your assertion that people in the Northeast tolerate such is only
marginally applicable here: the Texas amateur community decided that
what's usable in the Northeast is not necessarily usable here, and they
wanted a higher quality of service.

>Absent Gosrepeater (the current plan), we'd still have voluntary
>coordinators, who'd suggest the least-interference route.  We'd play
>with antenna patterns, PL and anti-PL, etc., to minimize conflict.
>We'd act like HAMS.  Even like low-band hams, most of whom try to
>minimize QRM even if the band has 8 times as many users as "quiet"
>bands would have (i.e., average of 8 stations per 3 kHz -- just a
>random number).  On occasion, there'd be "repeater wars", when
>people got upset about the failure of these measures to keep things
>from interfering, or when an existing user got peeved about a new one
>making things tougher.  But what was 20M like in 1929?  Probably less
>crowded than now.  And probably a lot of today's hams were there then,
>judging by the age stats!

You have an annoying habit of assigning provocative names to things. I
bet you agree with Tim Sevener's tactics in talk.politics.misc, too.

We do play with antenna patterns, ERP, and other technical factors to
insure little to no interference between repeaters. We won't tolerate
Northeast-level "usability", though. We are acting like hams. The
difference is that we do not consider any significant level of
interference satisfactory unless the trustees involved agree to it. If
they do, fine, but we cannot force them into it.

>>No, voice repeaters don't own the spectrum. Whoever has gotten there
>>first has the ability to use that frequency - for whatever choice they
>>desire, including packet - but they don't own it.
>Just think how easily one of these OOT's could have worked 300 countries
>if he could have had the exclusive right to call CQ on 3 kHz of 20M!

Aw, cmon. You're being deliberately obtuse. There's a world of
difference between 3 kHz of 20 and a repeater coordination: the repeater
coordination can be geographically reused.

>>I admit that I don't have the answers. What I do have is experience in
>>the coordination arena. So far, none of the proposed solutions I've seen
>>can work. That doesn't mean that there isn't one that will.
>Of course you can't ahve "the answers".  Because the problem has no
>easy solution.  Having the FCC grant you the imprimatur to treat
>ham bands like commercial frequencies doesn't make things better, it
>just changes the problem.  I prefer the old problems and solutions.

You're the only person I've talked to who wants to return to the bad old
days.
Like any other complex problem, this one has a number of simple, easily
understandable, easily implementable wrong answers. The coordinating
bodies are in the trenches working to find the right answers. The FCC's
action made our job a little easier; to those of us working to find the
answer, it's not a disaster. It's a greater responsibility.

--
Jay Maynard, EMT-P, K5ZC, PP-ASEL   | Never ascribe to malice that which can
uucp:        uunet!nuchat!   (eieio)| adequately be explained by stupidity.
    hoptoad!academ!uhnix1!splut!jay +----------------------------------------
{killer,bellcore}!texbell!          | "Less great!" "Tastes filling!"

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

Date: 1 May 89 12:55:40 GMT
From: sun-barr!male!pitstop!texsun!texbell!splut![e-mail]  (Jay "you ignorant splut!" Maynard)
Subject: FCC's recognition of repeater coordinators is a disaster

In article <[e-mail]> [e-mail] writes:
>Concerning this issue, I think that what we are really seeing here is a
>split occurring among the amateur ranks on what amateur radio is really
>all about. Jay Maynard has made his points on how he feels recoordination
>of any repeater is basically impossible for a number of reasons. He has
>replied to my criticism of "You can't get there from here" with an answer
>that basically says "That's right"!
>His answers and epitomes tended to aggravate me with terms such as
>"politically impossible" and "value judgments" and his basic emphasis on
>"he who gets here first gets the goodies and if YOU want some, move to
>another band".

So far, I haven't seen a different answer that would be perceived as
fair and equitable.
I'm not happy with the current state of affairs either, but I honestly
know of no better way to get there from here. I know, from first-hand
experience, that the things I say are politically impossible are indeed
so; I've floated a number of them in discussions with hams around
Texas. First-come-first-served affects me, too; if I wanted to put up a
2-meter repeater, I couldn't get a coordination. It affects everyone
equally, unlike any other system.

>It seems that EVERYONE is for technical advancement as long as
>it doesn't cause ME any inconvenience!

The "not in my backyard" factor is indeed alive and well. I didn't
create it, but I'd be a fool not to recognize it.

>In this regard the "FCC's Recognition of
>Frequency Coordinators IS A DISASTER"!!!!!!!!  Darn tooting it is!! Because
>we are losing the ability to battle it out as a group and instead now have to
>place the problem in the lap of a SMALL group of people such as those with
>the beliefs of Jay Maynard.

People in the position of frequency coordinator have generally come to
the same conclusions as I have for one reason: we've been here doing it.
Battling it out as a group is nice in theory, but disastrous in
practice.

>I personally react STRONGLY to advocates of "whoever was here first get the
>goodies"! Why? Because it eliminates anything new... it always will. Not just
>packet but just about ANYTHING! The only exception being things that everyone
>sees as beneficial right at the start... and how many things over the years
>have you EVER seen that meet that definition?

That assumes that all the goodies are gone.  All the 2-meter pairs may
be allocated, but that doesn't include other bands or other parts of the
two-meter band.  Amateur satellites use up 500 kHz of the 2-meter band.
Should this be immune to reuse by earth-to-earth links? Personally, I
think so - but why are voice repeaters the only things under attack?

>Not everyone can be a Phil Karn software genius or design and build a AMSAT,
>but I like to think that the vast majority of us SUPPORT those that DO advance
>our hobby through technical achievement.  If it means that a sacrifice some-
>times be made...  SO BE IT!

Sacrifices are always acceptable to those who are not sacrificed.  Tell
me honestly: if you had a repeater that you'd put $2000 and a man-year
into, would you voluntarily shut it down permanently in the name of
technical innovation? Especially if you'd done some innovating yourself
on it? The vast majority of amateurs would, to be completely honest,
answer "no".

>But it seems that this is not the case anymore. We have legal suits being
>instigated against fellow hams, and we see that there is some really EMPHATIC
>resistance being made to change. Two meter voice repeaters have become almost
>SACRED to a certain faction among us.  This makes me a little sick to my
>stomach!

I'm not overly fond of it either, but to think otherwise is to deny
reality.  We don't live in the best of all possible worlds; we're stuck
with the one we have.

>Jay is representing the "keep it as it is" concept and we are pushing the
>"let's develop new things no matter what" concept.  I doubt that we will
>ever see eye to eye on this, the differences in beliefs are so fundamental
>as to never be resolved.

"Let's develop new things, no matter what." No matter what other
considerations apply. No matter whether or not the program is practical.

I agree that development of new things is a Good Thing. I disagree that
it should be allowed to overrule all other considerations.

>Frequency Coordinators make me nervous.  Their reason for being was to allow
>growth with less conflict, but now they allow zero growth to avoid conflict.
>We have always had conflict and we have always risen above it in the long
>run, but when the FCC basically gave REGULATORY powers to groups that started
>life as people that were initially only ADVISORARY in nature, they opened
>Pandora's box.  Now the ADVISORS are afraid to REGULATE and the users refuse
>to be ADVISED! I can see where "repeater wars" might be better in the LONG
>RUN than what we are faced with now!

Frequency coordinators' regulatory abilities are extremely limited in
nature. You want us to regulate some voice repeaters into unusability,
if not downright legislate them out of existence. We don't have that
power. We cannot order someone off the air.
Growth always has an upper limit. We have reached that limit on one band
in some areas. That does not mean that other bands, or other areas,
have the same problem. I hear lots of calls for technical innovation,
but nobody wants to innovate the use of other bands. Do I detect a
consistency problem here?

>Jay Maynard says that there is nothing that could be worse than repeater
>wars, I say there is one thing that is worse....  stagnation.

We will only stagnate if we allow ourselves to. So far, the only place I
see the possibility occurring is on 2 meters. I see no practical,
implementable alternative, though.


--
Jay Maynard, EMT-P, K5ZC, PP-ASEL   | Never ascribe to malice that which can
uucp:        uunet!nuchat!   (eieio)| adequately be explained by stupidity.
    hoptoad!academ!uhnix1!splut!jay +----------------------------------------
{killer,bellcore}!texbell!          | "Less great!" "Tastes filling!"

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

Date: Mon, 01 May 89 09:32:39 EDT
From: [e-mail]
Subject: PACKET-RADIO Digest V89 #115

To me, one thing that comes across very clearly from this discussion
is that Mr. Maynard has no solution to this problem.  If this is an
important enough problem, I would encourage him to resign and let
someone else deal with it.

Another thing that I get out of this discussion, is that any "value
judgements" that are employed must not be that of one or two
individuals, but of the whole group in the frequency coordinated area.
(Remember the language in the announcement where the FCC recognized
frequency coordinators that they derive their "authority" by consent
of the people that they are coordinating).

I think that there is indeed a political solution to the repeater
usage problem.  Those who do not like it should band together and call
for a special election.  Then make it an issue in the election of
whether or not perpetual frequency assignments for repeaters or other
users will be supported by the ham public.  This may end up voting
the current frequency coordinators out of office.  More importantly,
it makes the issue one of public debate amoung the whole group, and it
may be politically possible then to follow through with whatever the
outcome is.

However, an election is a two-edged sword.  Those people who will want
to keep their allocations will probably be very interested in
retaining the status-quo with "educating" the users of their repeaters
about their own point of view.  So be prepared to do your own
"education", persuasion, or whatever.  And the repeater users may end
up out voting you.  If this happens, you can simply do more
education, and try again later.

To the best of my knowledge, the FCC did not make a frequency
coordinator's tenure permanent.  I did not recall a specific
procedure set up by which one recognizes a new one, though.

Where there is a will, there is a way....

English:        Peter T. Baldwin
Arpa:           [e-mail]
Phone:          [phone] (days)
Ham/packet:     wa1snh@wa1phy-9
Snail Mail:     Mitre Corp, MS K306, Burlington Rd, Bedford, Ma.  01730
Voice:          Peter!

Disclaimer:  The opinions expressed in this mail-gram are my own, and
do not necessarily express the views or opinions of Mitre or any
government sponsor (of course!).

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

End of PACKET-RADIO Digest
******************************
 2-May-89 02:11:48-MDT,3684;000000000000
Return-Path: <[e-mail]>
Date: Tue,  2 May 89 01:30:48 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #120
To: [e-mail]

PACKET-RADIO Digest         Tue,  2 May 89       Volume 89 : Issue 120

Today's Topics:
       FCC's recognition of repeater coordinators is a disaster
             PACKET-RADIO Digest V89 #112
----------------------------------------------------------------------

Date: 1 May 89 22:11:38 GMT
From: jupiter![e-mail]  (Phil R. Karn)
Subject: FCC's recognition of repeater coordinators is a disaster

>>His [Jay's] answers and epitomes tended to aggravate me with terms such as
>>"politically impossible" and "value judgments" and his basic emphasis on
>>"he who gets here first gets the goodies and if YOU want some, move to
>>another band".
>
>So far, I haven't seen a different answer that would be perceived as
>fair and equitable.

I don't perceive your answer as "fair and equitable" either.

>Amateur satellites use up 500 kHz of the 2-meter band.
>Should this be immune to reuse by earth-to-earth links? Personally, I
>think so - but why are voice repeaters the only things under attack?

First of all, the amateur satellite allocation on 2m is from 145.8 to
146.0. That's only 200 KHz, not 500 KHz. There are many simplex users
(voice and packet) in the 145.5-145.8 range around here.

Second, I'd like to see how you are going to avoid QRM to satellite
operations (which are inherently weak-signal in nature) from terrestrial
operations. Quite a few satellites are already crowded into this limited
segment. For example, the Microsats will all have their uplinks in the
145.8-146.0 range.  Remember that the 2m band in Europe, a very densely
populated continent, is only half as large as ours. Yet this hasn't kept
them from adhering to the international agreement to reserve 145.8-146.0
for satellites. In some cases a few repeaters had to be moved or shut
down, yet, believe it or not, the world didn't end.

>Sacrifices are always acceptable to those who are not sacrificed.  Tell
>me honestly: if you had a repeater that you'd put $2000 and a man-year
>into, would you voluntarily shut it down permanently in the name of
>technical innovation? Especially if you'd done some innovating yourself
>on it? The vast majority of amateurs would, to be completely honest,
>answer "no".

In this area several of us have built a functioning 56kbps TCP/IP packet
network on 220.55 MHz. Each modem costs about $500 to build. About half
this cost is attributable to the 28/220 MHz transverter. This investment
would be lost if we are unable to obtain a new allocation above 222 MHz
in the event Docket 87-14 becomes final. Are repeater operators the only
ones whose investments in time and money are to be counted?

Phil

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

Date: 1 May 89 13:20:00 EDT
From: "SWEIGERT, DAVID" <[e-mail]>
Subject: PACKET-RADIO Digest V89 #112

   ATTENTION  --  HAM TESTS

  At 10 am, Saturday, May 6th, W5YI examinations will be given at
the University of Maryland in College Park, MD.

  Tests are sponsored by the U of M ARC.  Bring $ 5.00 and positive
photo I.D. to the Student Activities Building, next to the TERPs
basketball stadium.  Testing is near room 114, on the same end
of the building as the video arcade, next floor up.


  WB9VKO
  P.O. Box 4423
  Annapolis, MD  21402

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

End of PACKET-RADIO Digest
******************************
 3-May-89 02:56:17-MDT,8381;000000000000
Return-Path: <[e-mail]>
Date: Wed,  3 May 89 01:30:23 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #121
To: [e-mail]

PACKET-RADIO Digest         Wed,  3 May 89       Volume 89 : Issue 121

Today's Topics:
         Amateur Digital Systems Conference? (2 msgs)
        Copying RTTY with Sony 2010 and PK 232
                 Help
----------------------------------------------------------------------

Date: 2 May 89 22:06:06 GMT
From: tektronix!orca!tekecs!ka7axd.WV.TEK.COM![e-mail]  (Michael T. Horne)
Subject: Amateur Digital Systems Conference?

>
> >ARRL Amateur Radio Computer Networking Conference (what a mouthful) will be
>                     ^
>                     ^---- and will this be the year we dump this word as part
>                           of the title?
>
> It may take computers to do it but we should be looking forward to something
> even more comprehensive. What about voice mail, picture mail and other apps...

Agreed.  I would suggest that something like "Amateur Digital Systems
Conference" would be more appropriate.  This covers the majority of the
current and future work under one umbrella.

I've been toying with some ideas for a voice mail interface, perhaps using
Phil's package for the transfer (there exists a voice mail protocol, though
it is old and pretty much outdated).  In a PC-based system, it wouldn't take
much to set up a rudimentary VM interface.  A DAC/ADC pair with a little analog
glue on a board is all that is really necessary.  The interface would be a
microphone and speaker for I/O, with the software interface being a simple VM
browser, allowing the user to 'read' mail and queue messages for delivery to
other amateurs.  The NET package would do the delivery, though ideally a new
protocol would be implemented so that true binary transfers could take place
(skipping the binary-to-ascii conversion and allowing data compression and
perhaps (maybe someday) encryption).  As an alternative to having the PC
spoon feed the DAC/ADC pair, a Motorola 56K can be placed on the board to do
all the work (and in its spare time it can be used as a modem or image
processor).

Along the same lines, we have the potential to do some really exciting things
with imaging, using amateur digital communications as the transport medium.
Besides the obvious uses of `picture mail' and other one-shot style image
exchange, we can start using amateur radio to do `real work'.  Images from
space can be downloaded from satellites for image processing and display on
the user's screen (one of the AMSAT/TAPR microsats will apparently have this
capability).  The CCD-array observatory down the road can be controlled
remotely via packet radio, with the scanned images transferred and displayed
at one or more locations in the area.  Here amateur radio becomes more of
a tool for other hobbies rather than the main hobby of interest.

The hardware to do these kinds of tasks (reasonable compute power, usable
monitor resolutions, etc.) is available today.  Of course, to reduce the
data transfer times down to a reasonable level, high-speed modems are the
hardware of choice, with much work to be done to make them available cheaply.

I don't think we should limit ourselves to just "Gee, Bob, I lost another
tooth today..." type communications (as we see often in packet radio).  There
are a lot of other exciting things we can do with our hobby, perhaps attracting
new, interesting people to the hobby in the process.

Mike  -ka7axd

Michael T. Horne - KA7AXD    Interactive Technologies Division, Tektronix, Inc.
[e-mail]                                          [phone]

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

Date: 3 May 89 01:00:12 GMT
From: tektronix!tekcrl!tekgvs![e-mail]  (Jan Steinman)
Subject: Amateur Digital Systems Conference?

<...I've been toying with some ideas for a voice mail interface... (there
exists a voice mail protocol, though it is old and pretty much outdated)...>

What's NeXT using?  Their machines come with a nifty voice mail, that is
somehow glued to regular Unix mail.  I had one for a few days, and did 'od -x'
on some mail enough to see there was a jumble of binary data.

I'm all for stealing, er, ah, *reusing* things others have worked the bugs out
of, rather than rolling my own.

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

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

Date: 2 May 89 17:03:00 EST
From: "NJITX::HXN8477" <[e-mail]>
Subject: Copying RTTY with Sony 2010 and PK 232

Has anybody tried to copy rtty using a Sony ICF2010 and
a PK232.  I have been trying to do this to no avail.  I am
simplifying things by trying to copy the ARRL's daily rtty
news bulletins since I know the mode and speed, and I receive them
clearly.  I have managed to copy MORSE but after I adjusted
the speed my self to 20 WPM (The manual claims that the PK232
is able to adjust the speed automatically).  But I have not been able
at all to copy rtty signals (either BAUOT, AMTOR, or ASCII).
As a matter of fact, I have not been able to copy Packet either, but
I am assuming that that needs a better HF receiver.  If someone has tried
this copying with this setup, or a similar one, with success, I would
greatly appreciate their advice.


______________________________________________________________________________
|Hamed Nassar               |Internet  : [e-mail] |
|EE Department              |UUCP      : bellcore!argus!mars!nancy           |
|NJ Institute of Technology |CompuServe: 74000,130                           |
|Newark, NJ 07102           |Fidonet   : 1:107/701                           |
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
------

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

Date: Tue, 2 May 89 10:19:58-0000
From: r p gordon <[e-mail]>
Subject: Help

Hi, this is a general plea for help with the Z8530 SCC from Zilog.......

We have built up a small micro based board (6303 + Z8530 + AM7911) to serve as
a digi in the locality. The software consists of high-level decoding/monitoring
routines which use low-level interrupt driven IO/buffer handlers.

When tested with a commercial TNC on both an audio and digital link the unit
functions as expected. However, when used on air it appears that spurious chars
creep into the start of each receive frame buffer. Using a buit in debugging
tool we have found (as expected) that the additional bytes are due to start-up
(TXDELAY) and tail delays on frame transmissions for which the 8530 generates
receive interrupts (rightly?). Correctly received frames pass the CRC test,
and so the net result is an offset frame in the buffer.

ARE WE MISSING A TRICK WITH THE 8530?

We have presently skirted around the problem for the majority of recevied frames
by implementing a high-level 'filter', which recognizes some AX.25 frame charac-
teristics. Obviously, this is unsatisfactory and still very much prone to error.

We had also thought about constructing a better carrier detect circuit (tone
filter) than the AM7910 provides to reduce the dead carrier time heard by the
8530, but since we know others use the 8530,7911 combination have not done so.

If some kind soul could shed some light on a possible cure, and save us more
hours of head scratching and EPROM programming your e-mail would be greatly
appreciated......

Thanks in adavnce, Ray Gordon (G1XRN)......

----------------------------------------------------------------------------
   Ray Gordon,                 ARPA: eegordon @ pyr.swan.ac.uk ....

   Dept of Electrical and Electronic Engineering,
   Room 404, ASB,
   University College of Swansea,
   Swansea, SA2 8PP.
   Wales, UK.

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

End of PACKET-RADIO Digest
******************************
 4-May-89 02:41:19-MDT,20845;000000000000
Return-Path: <[e-mail]>
Date: Thu,  4 May 89 01:30:54 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #122
To: [e-mail]

PACKET-RADIO Digest         Thu,  4 May 89       Volume 89 : Issue 122

Today's Topics:
           Computer Networking Conference (2 msgs)
        Copying RTTY with Sony 2010 and PK 232
       FCC's recognition of repeater coordination is a disaster
             KISS in Heath Pocket Packet
              TNC reviews - info request
             wanted: TEXNET info
----------------------------------------------------------------------

Date: 2 May 89 21:45:44 GMT
From: hpfcdc!hpldola!hp-lsd!col![e-mail]  (Bdale Garbee)
Subject: Computer Networking Conference

/ col:rec.ham-radio.packet / [e-mail] (julian macassey) /  8:50 am  Apr 24, 1989 /

    I have been able to find out that on Saturday October 7 the 8th annual
ARRL Amateur Radio Computer Networking Conference (what a mouthful) will be
held in Colorado Springs.

So:

Who is hosting it?

Where exactly is it?

Any hotel lists, prices?

    Could someone who is "au fait" please post the exciting details or tell
us where we can find them.

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

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

Date: 2 May 89 21:56:31 GMT
From: hpfcdc!hpldola!hp-lsd!col![e-mail]  (Bdale Garbee)
Subject: Computer Networking Conference

>I have been able to find out that on Saturday October 7 the 8th annual
>ARRL Amateur Radio Computer Networking Conference (what a mouthful) will
>be held in Colorado Springs.

Yep.  At the US Air Force Academy, about 5 miles west of my house... :-)

>Who is hosting it?

TAPR (Tucson Amateur Packet Radio, President N0CCZ and myself as Treasurer both
live in town), RMPRA, the Rocky Mountain Packet Radio Association, and the
Air Force Academy Amateur Radio Club.  The work is being done by Andy
Freeborn N0CCZ at the moment.

>Where exactly is it?

The meeting will be held at the Air Force Academy, which is on the west side
of I-25 just north of Colorado Springs.  About an hour drive south of Denver.
There will be a semi-organized get-together on Friday night, the program will
run all day Saturday with lunch provided at the Academy, and then there will
be an organized get-together on Saturday night.

>Any hotel lists, prices?

Last I heard Andy was working on a conference rate at the brand-new Marriot
about 5 miles south of the Academy, which has a pretty awesome view of Pike's
Peak and the front range.  The rate seemed to be quite reasonable, but I
regret that I don't remember it offhand.  Will ask Andy.  There are also a
slew of cheap places on North Academy boulevard, just outside the south
entrance to the Academy, across I-25.  Lots of decent places to eat for cheap
too.  Once you've made it to the Springs, this should be a very economical
conference to attend...

>Could someone who is "au fait" please post the exciting details or tell
>us where we can find them.

Stay tuned for more info as the event unfolds.

73 - Bdale, N3EUA

ps:  I'm open to suggestions for things folks would like to do on Sunday, or
     is a Sunday organized event even called for?  We've got a couple of things
     like NORAD and the Space Command here in town, don't know what would be
     interesting...

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

Date: 3 May 89 19:58:44 GMT
From: shelby!lindy![e-mail]  (Kevin J. Burnett)
Subject: Copying RTTY with Sony 2010 and PK 232

In article <[e-mail]> "NJITX::HXN8477" <[e-mail]> writes:
->
->Has anybody tried to copy rtty using a Sony ICF2010 and
->a PK232.  I have been trying to do this to no avail.  I am
->simplifying things by trying to copy the ARRL's daily rtty
->news bulletins since I know the mode and speed, and I receive them
Well, I have a (still broken) PK-232 and (used to) have a 2010, and
I had some success copying RTTY, although not much more than you.
One you might try copying is Prensa Latina in Havana on 18192.5kHz,
which runs an English news bulletin at 2000UTC every day.  To
try to get it, you might try using WIDESHIFT ON, and use the
SIGNAL mode (it's described in Appendix N in my edition of the
manual).

->clearly.  I have managed to copy MORSE but after I adjusted
->the speed my self to 20 WPM (The manual claims that the PK232
->is able to adjust the speed automatically).  But I have not been able
->at all to copy rtty signals (either BAUOT, AMTOR, or ASCII).
I didn't have much trouble in copying CW; when you get the signal tuned
properly, use the LOCK command to get the PK-232 on the right speed..

->As a matter of fact, I have not been able to copy Packet either, but
->I am assuming that that needs a better HF receiver.  If someone has tried
->this copying with this setup, or a similar one, with success, I would
->greatly appreciate their advice.
I didn't try copying HF packet, but I did successfully get it to work
using a hand-held scanner...

I hope this helps some.
--
Kevin Burnett, KC6AOA                   AMPR.ORG: 44.4.0.231
"She was an acrobat's daughter, she swung by her teeth from a noose;
 but then one day, her dentures gate way, and she flew through the air
 like a goose." - Daffy

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

Date: Wed, 3 May 89 22:19 CDT
From: <[e-mail]>
Subject: FCC's recognition of repeater coordination is a disaster

In PACKET-RADIO Digest V89 #117, Jay Maynard writes:

>Recoordinating a repeater should be a fairly simple process. The red
>tape involved is no more intricate than a new coordination.

Yes, it shouldn't be that bad.  This particular situation was the
first time I had personally ever dealt with a frequency coordinator.
Possibly it left a bad taste in my mouth because the lawsuit in
Dallas was in progress, and I felt like nothing could be done.

There are some things I would like to tell you concerning how viewpoints
towards the coordination process were developed by users of the local
repeater.  The image perceived may or may not have complete facts to back it
up, so I will send mail to you directly.  Maybe we can improve the
coordination process.  I am as interested in improving the procedure, as
I am in fixing this particular problem.


73, Charles, AA5AV
CJB8753@TAMSIGMA (Bitnet)
AA5AV @ W5AC (packet)

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

Date: 2 May 89 21:45:18 GMT
From: hpfcdc!hpldola!hp-lsd!col![e-mail]  (Bdale Garbee)
Subject: KISS in Heath Pocket Packet

I started working on it, but never got finished, mostly because the priority
to me was too low.

I have the Toshiba databook on my desk for the monster chip in the box.  The
bottom line is that the I/O addresses for the SIO are different from a normal
TNC-2, and that you have to program up the CTC clone to do baud rate
generation.

I won't get around to it for a while if ever, my priorities have shifted in
other directions.

Bdale, N3EUA

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

Date: 3 May 89 16:38:06 GMT
From: shelby!csli![e-mail]  (Goh Kawai)
Subject: TNC reviews - info request

Dear all,
Can anybody give me reviews of the Kantronics KAM, the AEA PK-232, and
the MFJ MFJ-1278?  I am considering buying one of these.  I want a TNC
that handles not only HF packet, but also RTTY, AMTOR, and CW.  I have
heard negative reviews about the KAM; is this a wide-spread opinion?
Also, do I really need the optional software packages to use these TNCs?
I have a non-IBM compatible machine (the NEC PC-9801uv2, in case you
heard about it), which precludes me from using such software.  I noticed
some reviews on this bboard a while back -- unfortunately, my site
purged those files, and I cannot retrieve them.

Thanks,
>goh< ([e-mail] [arpanet])(n6uok)

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

Date: 3 May 89 05:21:16 GMT
From: convex!iex!ntvax![e-mail]  (Greg Jones)
Subject: wanted: TEXNET info

In article <[e-mail]> [e-mail] writes:
>is there someone out in networld who could enlighten me about some
>details of the TEXNET stuff? Any info would be appreciated.
>Please e-mail direkt to c0033003 @ dbstu1.bitnet
>
>tnx in advance.
>
>73s de Detlef ( dk4eg @ dk0mav )

Hi Detlef - you should be receiving some files concerning TexNet
via your BITNET account, but for the rest of the folks out there
in net land - here is what I sent.

Hope the info helps --- greg

 /*---------------------------------------------------------------
  Greg Jones (WD5IVD)                  Dept of Computer Sciences
                       University of North Texas
                       Denton, Tx
  =============================================================
  UUCP   : {convex,infoswx,texsun,utd,killer}!ntvax!greg
  CSNET  : [e-mail]
  BITNET : greg@untvax
  BIX    : gregj
  CIS    : 72047,3455
  PACKET : WD5IVD @ WA5MWD
  TexNet : Use PMS @ DALLAS (Texas Network only)
  =============================================================
 ---------------------------------------------------------------*/

First of all TexNet source and everything is available via
anonymous ftp at dept.csci.unt.edu or ntvax.unt.edu [129.120.1.2]

Files are located under pub/TPRS

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

Texas Packet Radio Society, Inc.

TPRS was founded in 1985 as an educational, public service, and scientific
research non-profit corporation.  The primary goal of the Texas Packet
Radio Society is to design and research amateur radio packet networks.
In 1987, the Texas VHF-FM Society commissioned the TPRS to coordinate
digital communication networks within the state of Texas.  Both
organizations have recognized the need for reliable network systems to
handle large volumes of packet radio traffic efficiently.

TPRS has organizing state-wide working groups to cover various
networking topics.  New groups are planned to form as needed to provide
channels for discussion and to help provide direction for that area of
digital communications.  The current working groups are the Texas Network
Group, the Mailbox/BBS Group, and the TexNet Support Groups (Software and
Hardware).  TPRS hopes that these working groups will help promote packet
in Texas.

TEXNET
TPRS has been establishing a digital packet network protocol, a standard
hardware package for the network nodes, and conducting on-the-air tests of
the software modules that implement the TexNet network.

The basic design philosophy of TexNet is of an open, inexpensive,
multi-resource, high speed "backbone" with access through multi-connect
capable local nodes.  On the high speed side, TexNet is a 9600 baud
network system.  For local access, compatibility with the typical 2 meter
AX.25, 1200 baud, AFSK/FM station is the operational norm.  Other baud
rates and modulation techniques can be supported on the primary user port
or a secondary port.  The system is totally compatible with both versions
of the AX.25 protocol specifications for user connections.  With these
general specifications, TexNet has been designed and tested to enable all
users to take advantage of this high speed, full protocol protected packet
network system.

Each node offers, in addition to TexNet access, local area digipeater
service, 2 conference bridges for full protocol protected roundtable or
net operation, a full multi-connect, multi-user mailbox system, a local
console for installation and maintenance setups, a debugger module for
long distance and local software monitoring, and a weather information
server for the regional weather teletype wire loop.

The TexNet network system has been operational since October 1986.  Use of
the TexNet system is open to all amateur operators.  TPRS has been
coordinating the installation of the Texas TexNet system.  Currently the
network runs from Dallas to Rockport on the gluf.  TexNet boards have been
distributed to California, Michigan, Oklahoma, OPhio, Indiana, Alaska,
Belgium, and Japan.  Network nodes have been built primarily by local groups.
Further expansion of the system depends entirely upon the amateur
radio community.

INFORMATION
TPRS is interested in spreading our information and research efforts as
widely as possible.  We want other groups involved with network efforts to
get in contact with us.  We will provide information for those amateur
packet groups that are interested in this system for their areas.  In addition,
TPRS has been raising its level of general packet information to help support
packet radio operators in general within Texas.  If you would like more
information concerning TPRS or TexNet, please drop a letter to :

Texas Packet Radio Society, Inc.
P.O. Box 831566
Richardson, Texas  75083

TPRS MEMBERSHIP
TPRS membership is widespread with most members located in Texas, but a
few members are located in other states and in DX locations.  Membership
is open to any interested person.

If you are interested in becoming a member and receiving the TPRS
Quarterly Report, please send your name, address and call to the address
above and we will send you the necessary information.


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

Texas Packet Radio Society, Inc.                              Product Sheet

========================================== (Prices Valid through June 1990)

Name : _____________________  Address : __________________________________

Call : _____________________  City : __________ State : _____  Zip : _____

===========================================================================
TPRS Membership (SEE BELOW for Membership Application)

***** Software / Manuals / Documents
TNC 64 .................................. TPRS Member Price  $20.00 ______
 (Packet Terminal Program for the C-64)    Non-Member Price  $25.00 ______
TexNet User's Manual ........................................ $1.00 ______
TexNet Administrator's Manual ............................... $1.00 ______
RCA 700 Modifications Document .............................. $5.00 ______
9600 Baud Clock Recovery EPROM ............................. $10.00 ______
1200 Baud Clock Recovery EPROM ............................. $10.00 ______
TexNet Software Disk ....................................... $10.00 ______
  Includes :  Soucre Code
          Eprom Iamges: FIRCODE,1200 & 9600 Clock Recovery,NCP Image
          Basic Programs to change FIRCODE and NCP Image
          Current revision information  (5)


***** TexNet Boards  (*)
   NCP 2.1 Board (1) ....................................... $45.00 ______
       (Board combines NCP, 1200b modem, 9600b modem sections)

   Daughter Board (4) ...................................... $10.00 ______
   Individual 1200 Baud Modem Board Section (2) ............ $15.00 ______
   Individual 9600 Baud Modem Board Section (3) ............ $20.00 ______



***** TexNet Parts and Kits
   TexNet parts and kits are available.
   Contact the TPRS on price and availability.


                           ******* TOTAL : _______

---------
Notes :
(*) Full Documentation/Construction information is included with boards.
(1) Requires NCP EPROM, optional FIRCODE EPROM, and 1200 & 9600 baud clock
     recovery EPROMS for operation.
(2) Requires a 1200 baud clock recovery EPROM for operation.
(3) Requires a 9600 baud clock recovery EPROM for operation.
(4) Required for PMS operation.
(5) These files are also available via Compuserve.
---------

*** Amateurs in the Texas TexNet network should contact the TPRS TexNet
    Coordinator about technical help, EPROM burning, and node coordination.

** Additional information sheets are available on all items above.
   If you would like further information send a SASE to the TPRS
   requesting the information needed.

** Make Checks payable to the Texas Packet Radio Society.


================================ Cut-Here =================================

Texas Packet Radio Society -- Membership Application

Name : ____________________________________         Call : _______________

Address : _________________________________         Apt : ________________

      _________________________________

      _________________________________

City/State : ______________________________         Zip : ________________

Home Phone :  (   ) ________________   Work Phone : (   ) ________________

* Is this a renewal ? (Yes/No) ________
* Membership os $12 per year.  Number of years : ________________

Make Checks payable to Texas Packet Radio Society.
Mail to the address below.

================================ Cut-Here =================================


ADDRESS :
Texas Packet Radio Society
P.O. Box 831566
Richardson, Texas
75083


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



              Texas Packet Radio Society
           TexNet User's Manual 3.5 Summary
               August 1, 1988
             Greg Jones, WD5IVD
=============================================================================

Introduction :
  TexNet is a dedicated, remote sited, multi-access, multi-resource network
system.  Each node offers, in addition to TexNet access, several network
services which are descirbed below. Use of any of the node services is
selected by Secondary Station Identification numbers (SSID).  TexNet is open
to all amateur radio operators to use.

TexNet Node Services :
 Each service is connected to by using an ssid. Example : c WR5C-4 will
 connect the user to the DALLAS TexNet node on 145.05 in Plano, Texas.

 0 - Digipeater Operation
   All TexNet nodes can be used as digipeaters.
   The nodes call or alias can be used to digipeat through.
   Use of a node as a wide area digipeater is not encouraged.

 2 & 3 - Conference Bridge
   Each node maintains 2 conference bridges (ssid 2 & 3).
   Once connected all transmitted packets are sent to all other
   users connected to the conference bridge, providing roundtable
   communications.
   Control-U will list all other users connected to your bridge.

 4 - TexNet Network
   The TexNet network is made up of a network of nodes connected by
   450Mhz 9600 baud links (backbone).  The following is a description
   of the current network commands.  Commands are entered at the
   command prompt : NETWORK CMD?.

     Help or ?
       Returns a listing of the user commands.

     Bye or b
       At the NETWORK CMD ? prompt will disconnect you from the network.

     Location or L
       Returns a listing of all nodes on the network by name.

     Message @ NODE or M @ NODE
       Make a connection to a message server (PMS) @ NODE.
       PMS commands are a subset of the W0RLI BBS command set.
       PMS Commands : Bye, List, Kill, Read, Send  (B,L,K,R,S)
       [Example: M @ DALLAS]

     Weather or W
       Make a connection to the network weather server.
       LW lists the general weather statements.
       LS lists the server weather statements.

     Circuit or C
       Circuit allows a user at one node to make a connection to a user
       at another node over the network. Example : C K5ABC @ HOUSTON
       would allow a user to try to connect to K5ABC at the Houston
       node over the network.

     C CQ @ NODE
       Transmits a CQ using your call at the node indicated.
       To respond to a CQ call, just connect to the network and
       then type 'C CALL @ NODE'.  The network should handle
       the rest. To finish a QSO, one user must do a manual disconnect
       from the TNC cmd: prompt.

General :
  The TexNet User's Manual contains a full description of the TexNet
  node services and network commands.

  For more information concerning TexNet write :
    Texas Packet Radio Society
    P.O. Box 831566
    Richardson, Texas 75083

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

End of PACKET-RADIO Digest
******************************
 5-May-89 02:26:43-MDT,1923;000000000000
Return-Path: <[e-mail]>
Date: Fri,  5 May 89 01:30:37 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #123
To: [e-mail]

PACKET-RADIO Digest         Fri,  5 May 89       Volume 89 : Issue 123

Today's Topics:
       Macintosh KA9Q code available for anonymous FTP
----------------------------------------------------------------------

Date: 5 May 89 05:07:09 GMT
From: [e-mail]  (Patty Winter)
Subject: Macintosh KA9Q code available for anonymous FTP

The latest release of the Macintosh version of the KA9Q TCP/IP
package is now available for anonymous FTP from flash.bellcore.com
(128.96.32.20).

There are four files: source code and executable program each for
NET and BM. The files are in Stuffit 1.5.1 binary format. They are
also BinHexed, so you'll have to unBinHex them before you unStuff them.

This is the version we distributed at Dayton. Its official name
is 871225.33a4 Macintosh version 1.0.

Any questions about the files themselves, please contact Doug Thom
([e-mail]) or Mike Chepponis ([e-mail]). I hope that
various people will download the files to BBSs and such to make them
available to those who don't have direct Internet access. Two Bay
Area BBSs that have the current object files are MacScience at
[phone], and Digikron Systems (Doug's machine) at [phone].


Patty
=============================================================================
Patty Winter N6BIS                        INTERNET: [e-mail]
AMPR.ORG: [44.4.0.44]                     UUCP: {decwrl,nsc,sun}!apple!winter
=============================================================================

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

End of PACKET-RADIO Digest
******************************
 6-May-89 02:10:13-MDT,10998;000000000000
Return-Path: <[e-mail]>
Date: Sat,  6 May 89 01:30:31 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #124
To: [e-mail]

PACKET-RADIO Digest         Sat,  6 May 89       Volume 89 : Issue 124

Today's Topics:
       FCC's recognition of repeater coordination is a disaster
            Help me (possibly others) !!!
             KISS in Heath Pocket Packet
             PACKET-RADIO Digest V89 #122
                TNC-on-a-card
              TNC reviews - info request
----------------------------------------------------------------------

Date: 1 May 89 18:03:16 GMT
From: schlep.dec.com!jfcl.dec.com![e-mail]  (Fred R. Goldstein)
Subject: FCC's recognition of repeater coordination is a disaster

In article <[e-mail]> [e-mail] (Jay "you ignorant splut!" Maynard) writes:
>In article <[e-mail]> [e-mail] (Fred R. Goldstein) writes:
>>Repeater wars were disastrous to those who didn't expect them, or
>>who didn't know how to cope with them.  Malicious interference was
>>part of some such wars, and should not be condoned.  That's different
>>from the "wars" that go on constantly on the DC bands, where QRM is
>>simply expected.
>
>Malicious interference was part of ALL such wars that I've ever heard
>of, as well as a lot of other, even less savory things. Do you really
>want that? I don't. As Mike Waters has said, that kind of thing is even
>more damaging.

Last night there was quite a "war" on my favorite frequency (14.010),
caused by a rather large number of people interested in working a JY9.
And an even bigger one at 14.198 surrounding a YI2.  Yet I heard no
malicious interference, just a lot of people playing the game.  I did
however hear quite a bit of malicious interference on 3.895, with
fewer than a half-dozen operators trying to carry on a silly
conversation (about par for that band).

I don't want malicious interference, but we have separate rules about
it.  Nonmalicious "interference", the inevitable result of sharing
frequencies, is at the heart of ham radio.

>>Co-channeling repeaters where they are warned that they have some
>>overlapping coverage is not the same as putting two open repeaters
>>five miles apart on the same pair.  Commercial users have gone
>>to PL, anti-PL, etc.; these techniques work, especially when the
>>primary coverage areas differ but secondary areas overlap.
>
>These techniques may work in the commercial world, but there is no
>covenant there. There is one in the amateur coordination field. We can't
>unilaterally overturn that covenant.

Covenant?  Interesting term.  Is that as in a deed restriction, or
as in what in Hebrew (Ashkenazic) is called "bris"?  Sorry, but my
ham license disclaims frequency ownership.

>The semi-idle repeaters have made an agreement: they put up (to a
>certain extent) with us telling then where they should operate, and
>within what technical parameters, and we protect them. We can't
>unilaterally change that, and that's exactly what you're calling for.

Yes, you can unilaterally change that!  Conditions change, and
the terms of grant change.  How do you think the clear channel AM
broadcasters felt when the FCC loosened up the AM rules?  The AMST
complained but the frequencies are the public's, and the FCC is
exercising judgement over what is the current best way to use them.

>During the 20 kHz discussions, this was a common thread: "They use
>upright 15 kHz channels in the Northeast, why can't we here?"
>People who had operated there, and who had moved here, were unanimous:
>repeaters there were much less usable than they are here. Lots of
>interference, and lots of arguments, and lots of adjacent-channel
>problems. The users and trustees of Texas repeaters decided they didn't
>want that.

That doesn't really relate to abolishing Gosrepeater coordination.
The bandplan and the allocation of channels are two different
issues.  I rather like the inverse-split 15 kHz (California) plan,
but we don't really have problems with the 15 kHz plan here any
more; we're used to it.

Sure, it was a pain at first, but we chose our frequencies more
carefully, use tighter crystal filters, etc.  Basically, we decided
as a whole that the 1971-vintage radios weren't adequate any more.
Sort of like the way we stopped running AM at 14.210.
      fred k1io

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

Date: 5 May 89 01:32:22 GMT
From: mcvax!ukc!kl-cs![e-mail]  (Atula Herath)
Subject: Help me (possibly others) !!!

Hi everybody.

I am an amature to the amature radio. Over past few weeks say(5-6) I was
regularly reading, rec.ham-radio and rec.ham-radio.packet. Things appeard
were remarkable, and grate, despite the problem that I know nothing about
that. But I would like to carry on, because it is fasinating. But some
wizard(s) may like to help me or possibly quite a lot of people like me.
The area which I am particularly interested is in radio packet switching.
There were quite a few terms which I collected over past few weeks, that
I don't understand is :

BAOUT
AMTOR
KISS
TNC
PK232
.......
,.....

list is longer but I suppose this would say someting about my knowledge. :-)
I would like somebody write brief introdcuction to this group about this
and possibly how to start up. In otherwords what I am asking may be
how to start up as an amature.  Most possibly these questions have been
asked sevaral times in the past. I would be  most grateful for some overviews
and possibly pointers to good startup books and start-up kits. etc. etc.


Thanks for your patience.


Athula.

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

Date: Fri, 5 May 89 09:34:38 PDT
From: Doug Faunt N6TQS 415-688-8269 <[e-mail]>
Subject: KISS in Heath Pocket Packet

It turns out, one of the local packeteers, in a message about
something else, told me that the Japanese version of the Heath Pocket
Packet already has KISS built in, and he's got a copy.  As soon as I
can get together with him, I'll have it.  Now, to get the keyboard on
my Portable Plus repaired.

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

Date: 5 May 89 09:05:18 PDT (Friday)
From: "wayne_a._lightsey.RochXRC"@Xerox.COM
Subject: PACKET-RADIO Digest V89 #122

re:3 May 89 16:38:06 GMT
From: shelby!csli![e-mail]  (Goh Kawai)
Subject: TNC reviews - info request

Dear all,
Can anybody give me reviews of the Kantronics KAM, the AEA PK-232, and
the MFJ MFJ-1278?

YOUR QUESTION IS SOMEWHAT SUBJECTIVE AS WILL BE THE REPLY. I PERSONALLY USE
A PK-232 AND LOCAL PACKETEERS ARE USING KAM, AND MFJ. I WILL COMMENT ON MY
EXPERIENCES AND RELATE THEIR COMMENTS.

YOU DO NOT NEED THE OPTIONAL SOFTWARE TO USE ANY OF THESE UNITS. THEY ALL
OPERATE EQUALLY WELL FROM A DUMB ASCII TERMINAL OR VIA ANY TERMINAL
EMULATOR PACKAGE RUNNING ON A MICROPROCESSOR - EXCEPT FOR FAX MODE. THE
ASSOCIATED SOFTWARE PACKAGES DO MAKE SOME OF THE COMMUNICATIONS MODES
EASIER TO USE AND PROVIDE MORE PLEASANT DISPLAYS - LIKE A SPLIT SCREEN FOR
TRANSMIT BUFFER AND RECEIVE BUFFER IN PACKET MODE. THERE IS A FAIR AMOUNT
OF SHAREWARE AROUND ON BBS' THAT DO MUCH OF THE SAME.
 FOR FAX MODE, THE FAX SOFTWARE (PK-FAX) ALLOWS VIEWING FAX PICTURES ON THE
CRT AND STORING THEM ON THE DISK , PRINTING,  ETC.  LACKING THE SOFTWARE,
THE PK-232 CAN PRINT THE FAX PICTURE DIRECTLY TO A CENTRONICS PARALLEL
INTERFACE COMPATIBLE PRINTER.

I HAVE USED MY PK-232 IN ALL MODES - PACKET (VHF & HF), AMTOR, RTTY, FAX,
AND CW.  IT PERFORMS AS ADVERTISED AND HAS MET ALL MY EXPECTATIONS.   THE
PK-232 HAS A NICE FEATURE WHERE IT MONITORS A SIGNAL AND THEN GUESSES WHAT
IT IS - BAUDOT, ASCII, AMTOR, ETC.   WHEN IT DISPLAYS A PROBABILITY FACTOR
ABOVE 70%, IT IS ALMOST ALWAYS CORRECT.

THE SECRET TO SUCCESS WITH THE PK-232 WAS LEARNING TO TUNE THE SIGNALS
CORRECTLY. THE MULTI-LED DISPLAY IS ADEQUATE ONCE YOU KNOW WHAT YOU ARE
DOING BUT A  'SCOPE  (CONNECTOR PROVIDED) WOULD BE MUCH BETTER FOR THE
BEGINNER.

 STATIC CRASHES AND QRM ARE ANATHEMA TO CW - WEAK SIGNAL PERFORMANCE IS
POOR. WITH GOOD SIGNALS, CW COPY IS EXCELLENT - DEPENDING UPON THE FIST OF
THE SENDER.  RUN-TOGETHER CHARACTERS ARE INTERPRETED AS "?" OR "_" SYMBOLS.
IT IS A GOOD TEST OF CW SENDING SKILLS TO HAVE THE PK-232 MONITOR YOUR
FIST!

THE UNIT DOES WHAT IT IS ADVERTISED TO DO. THE PK-232'S LED DISPLAY IS VERY
HANDY IN DETERMINING WHAT IS GOING ON, THE KAM AND MFJ UNITS TEND TO BE
SPARSE IN THE REGARD.

SOME OF THE PK-232 DEFICIENCIES I HAVE HEARD ABOUT BUT NOT EXPERIENCED: RFI
; INADEQUATE PROTECTION ON THE 12VDC INPUT LEAD (NO REVERSE POLARITY OR
SPIKE PROTECTION).; BATTERIES FALLING OUT OF THE INTERNAL HOLDER [MOUNTED
IN THE LID] . SIMPLE MODS EXIST TO CORRECT ALL THESE PROBLEMS.

WHAT I HAVE HEARD ABOUT KANTRONICS AND MFJ GEAR IS UNSUBSTANTIATED
HEAR-SAY, SO I WILL NOT REPEAT IT HERE.
ONE FEATURE OF THE KAM I DO LIKE IS THE DUAL MODEM / DUAL CHANNEL
CAPABILITY WHICH  PERMITS SIMULTANEOUS HF/VHF PACKET OPERATION. THE PK-232
CAN DO ONE OR THE OTHER BUT NOT BOTH CONCURRENTLY. IF YOU PLAN OPERATIONS
AS A GATEWAY BETWEEN HF AND VHF PACKET, THIS MIGHT IINTEREST YOU.

FROM PERSONAL EXPERIENCE, IF I WERE IN THE MARKET AGAIN, I WOULD CONSIDER
EITHER THE PK-232 OR THE KAM TO BE EQUAL CONTENDERS WITH THE DECISION
RESTING UPON FACTORS LIKE THE KAM'S DUAL CHANNEL CAPABILITY AND MY NEED FOR
THAT FEATURE. I WOULD AVOID MFJ - WHICH ONE DEALER DESCRIBED AS "My
Friend's Junk" .  MY EXPERIENCE WITH MFJ PURCHASES HAVE BEEN CONSISTENT
WITH THAT DESCRIPTION. MFJ'S LOWER PRICES ARA ACHIEVED THROUGH QUALITY
TRADE-OFFS. 73, WAYNE, KB6CSP

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

Date: 5 May 89 22:08:25 GMT
From: att!chinet![e-mail]  (John E. Thomason)
Subject: TNC-on-a-card

I just saw an ad by Digital Radio Systems for their PC*Packet Adapter
System for IBM PC and Clones (Packet Radio without a Packet Radio TNC)

I would be interested in receiving email concerning the performance of
this product from anyone who has actually used it.  Thank you.

--
John E. Thomason
AH2N

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

Date: 5 May 89 15:07:11 GMT
From: elbereth.rutgers.edu!ron.rutgers.edu![e-mail]  (Ron Natalie)
Subject: TNC reviews - info request

I have an AEA PK-232.  It's fairly good for Packet, RTTY, and AMTOR.
I don't do much HF Packet, but use it fairly heavily for VHF Packet
and RTTY/AMTOR.  I also have the PC Packratt software with it, which
is convenient, but has a handful of really annoying bugs.  The FAX
mode is a joke, it's not much use except for making illegible copies
of weather maps.

-Ron (WO2L)

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

End of PACKET-RADIO Digest
******************************
 7-May-89 01:53:07-MDT,5144;000000000000
Return-Path: <[e-mail]>
Date: Sun,  7 May 89 01:30:53 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #125
To: [e-mail]

PACKET-RADIO Digest         Sun,  7 May 89       Volume 89 : Issue 125

Today's Topics:
             PACKET-RADIO Digest V89 #115
----------------------------------------------------------------------

Date: 7 May 89 02:49:08 GMT
From: sun-barr!texsun!texbell!nuchat!splut![e-mail]  (Jay "you ignorant splut!" Maynard)
Subject: PACKET-RADIO Digest V89 #115

In article <[e-mail]> [e-mail] writes:
>To me, one thing that comes across very clearly from this discussion
>is that Mr. Maynard has no solution to this problem.  If this is an
>important enough problem, I would encourage him to resign and let
>someone else deal with it.

I said that I didn't have the solution at the very beginning.
I do, however, have the desire and the willingness to work on a
solution. So far, I have seen few others who are actively working in the
coordination process. I put my time and energy where my mouth is.

Lots of other people hold offices where they don't have answers, but are
working on them. Would you turn them out as well? Better start with
Congress, your state legislature,...

>Another thing that I get out of this discussion, is that any "value
>judgements" that are employed must not be that of one or two
>individuals, but of the whole group in the frequency coordinated area.
>(Remember the language in the announcement where the FCC recognized
>frequency coordinators that they derive their "authority" by consent
>of the people that they are coordinating).

This is the only way I see out of this. The ham population at large has
told us that they perceive the present system is the only fair,
equitable way to get there from here. If the ham population tells us
differently, then maybe we have a solution. I can only speak for Texas,
but the Texas VHF-FM Society is a membership organization open to all
hams. I invite anyone who thinks our priorities to come to the next
Society board meeting, athe ARRL National in June, and tell us all about
it. It would help if you had specific ideas for a change.

>I think that there is indeed a political solution to the repeater
>usage problem.  Those who do not like it should band together and call
>for a special election.  Then make it an issue in the election of
>whether or not perpetual frequency assignments for repeaters or other
>users will be supported by the ham public.  This may end up voting
>the current frequency coordinators out of office.  More importantly,
>it makes the issue one of public debate amoung the whole group, and it
>may be politically possible then to follow through with whatever the
>outcome is.

No special election is necessary, at least in Texas. The Board is
elected for two-year terms, half every other year, and any ham can join
the Society and run. Further, any Society policy can be (and often is)
changed at the general membership meeting. The next membership meeting
will be in Austin, the first weekend in August.

>However, an election is a two-edged sword.  Those people who will want
>to keep their allocations will probably be very interested in
>retaining the status-quo with "educating" the users of their repeaters
>about their own point of view.  So be prepared to do your own
>"education", persuasion, or whatever.  And the repeater users may end
>up out voting you.  If this happens, you can simply do more
>education, and try again later.

An enlightened approach; remember, though, that elections reflect the
will of the people who are interested enough to vote. "Education" (or,
more honestly, politicking) may or may not help. Remember also that a
loss may not mean that you haven't educated everyone enough; there's
also the (strong) possibility that the result reflects what the ham
community really wants.

>To the best of my knowledge, the FCC did not make a frequency
>coordinator's tenure permanent.  I did not recall a specific
>procedure set up by which one recognizes a new one, though.

There is no procedure by which a coordinator is recognized, period. The
recent mess in Southern California on 220 shows what happens when
someone doesn't work within the system: chaos ensues.
The Texas VHF-FM Society has been defacto recognized as the coordination
body for Texas primarily because we've been doing it for 25 years, and
nobody else has. By now, we've earned the respect of the general Texas
ham public.

--
Jay Maynard, EMT-P, K5ZC, PP-ASEL   | Never ascribe to malice that which can
uucp:        uunet!nuchat!   (eieio)| adequately be explained by stupidity.
    hoptoad!academ!uhnix1!splut!jay +----------------------------------------
{killer,bellcore}!texbell!          | "Less great!" "Tastes filling!"

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

End of PACKET-RADIO Digest
******************************
 8-May-89 02:03:53-MDT,11979;000000000000
Return-Path: <[e-mail]>
Date: Mon,  8 May 89 01:30:28 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #126
To: [e-mail]

PACKET-RADIO Digest         Mon,  8 May 89       Volume 89 : Issue 126

Today's Topics:
  FCC's recognition of repeater coordinators is a disaster (3 msgs)
           Where to get the latest KA9Q Software...
----------------------------------------------------------------------

Date: 7 May 89 11:20:55 GMT
From: sun-barr!texsun!texbell!splut![e-mail]  (Jay "you ignorant splut!" Maynard)
Subject: FCC's recognition of repeater coordinators is a disaster

In article <[e-mail]> [e-mail] (Phil R. Karn) writes:
>>(I wrote, in reference to "first-come, first-served):
>>So far, I haven't seen a different answer that would be perceived as
>>fair and equitable.
>I don't perceive your answer as "fair and equitable" either.

You're in the tiny minority. I do have to consider the larger ham
community, and they've told us that they do perceive it that way.

>First of all, the amateur satellite allocation on 2m is from 145.8 to
>146.0. That's only 200 KHz, not 500 KHz. There are many simplex users
>(voice and packet) in the 145.5-145.8 range around here.

Wanna use that space for repeaters? Go talk to the FCC, not me.
There has been some complaining, though - even before the shuttle
flights with hams aboard - about terrestrial FM simplex on 145.555 in
particular, and the reason given was that it interfered with satellite
use.

>Remember that the 2m band in Europe, a very densely
>populated continent, is only half as large as ours. Yet this hasn't kept
>them from adhering to the international agreement to reserve 145.8-146.0
>for satellites. In some cases a few repeaters had to be moved or shut
>down, yet, believe it or not, the world didn't end.

Europe is different. They have very tightly controlled repeater
allocations - the government does it, and the government can tell them
to shut down a repeater and make it stick. We can't. Their repeaters are
also run, not by individuals, but by (large) ham clubs.

>In this area several of us have built a functioning 56kbps TCP/IP packet
>network on 220.55 MHz. Each modem costs about $500 to build. About half
>this cost is attributable to the 28/220 MHz transverter. This investment
>would be lost if we are unable to obtain a new allocation above 222 MHz
>in the event Docket 87-14 becomes final. Are repeater operators the only
>ones whose investments in time and money are to be counted?

I've said before that 220 is a special case: the FCC's grab makes it
obvious to repeater trustees that they will have to move. The band's
also not so full that there's no place for them to move to. Neither
condition exists on 2 meters.
Have you forgotten that I'm doing my best to see that packet gets half
of whatever spectrum is freed up by moving repeaters?

--
Jay Maynard, EMT-P, K5ZC, PP-ASEL   | Never ascribe to malice that which can
uucp:        uunet!nuchat!   (eieio)| adequately be explained by stupidity.
    hoptoad!academ!uhnix1!splut!jay +----------------------------------------
{killer,bellcore}!texbell!          | "Less great!" "Tastes filling!"

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

Date: 7 May 89 21:06:51 GMT
From: ka9q.bellcore.com![e-mail]  (Phil Karn)
Subject: FCC's recognition of repeater coordinators is a disaster

>You're in the tiny minority. I do have to consider the larger ham
>community, and they've told us that they do perceive it that way.

The minority of what? If you only canvass the existing repeater owners
(which dominiate every frequency coordinating body I've ever seen -- which
is why they're usually called "repeater councils") of COURSE you will find
that most want to preserve the status quo.

>Wanna use that space for repeaters? [145.5-145.8] Go talk to the FCC, not me.

What gave you this idea? We already have plenty of space, perhaps too much
space, on 2m that is occupied by repeaters. There needs to be room for other
modes, e.g., FM simplex, SSB and weak signal work, packet, satellite and so
on. The reason we still have repeater subbands on 2m even in this era of
deregulation is recognition by the FCC that without subbands, FM repeaters
would immediately swallow up the entire band.

>There has been some complaining, though - even before the shuttle
>flights with hams aboard - about terrestrial FM simplex on 145.555 in
>particular, and the reason given was that it interfered with satellite
>use.

This is news to me. A check of my references shows that EVERY unmanned
amateur satellite -- with one exception -- from Oscar-6 to the present that
uses 2m does (or did) so in the 145.8-146.0 segment. (The one exception is
Oscar-13, whose mode J uplink listens between 144.425 and 144.475 MHz.) Even
the Russian RS satellites follow this convention.  The *only* space
operation I know of on 145.55 MHz has been the US and Soviet 'ham-in-space'
flights. Being more like DX-peditions than anything else, these are
obviously in a special category.

>Europe is different. They have very tightly controlled repeater
>allocations - the government does it, and the government can tell them
>to shut down a repeater and make it stick. We can't. Their repeaters are
>also run, not by individuals, but by (large) ham clubs.

Sigh. Remember the Prose Walker days of the early 1970s? I much prefer the
way things are now, with the hams regulating themselves, even if it's a
little anarchic at times. The problem is, our much-touted self-regulation
seems to be largely a paper tiger, which is why we still have things like
repeater subbands. I wish hams understood that it's always better to be
able to regulate yourself than to have the government do it for you.

>I've said before that 220 is a special case: the FCC's grab makes it
>obvious to repeater trustees that they will have to move. The band's
>also not so full that there's no place for them to move to.

Halllujah! Now we're getting somewhere. Can you please tell this to the
local TSARC people?

Phil

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

Date: 7 May 89 19:11:31 GMT
From: texbell!bigtex!helps!bongo![e-mail]  (julian macassey)
Subject: FCC's recognition of repeater coordinators is a disaster

In article <[e-mail]>, [e-mail] (Jay "you ignorant splut!" Maynard) writes:
>
> >Remember that the 2m band in Europe, a very densely
> >populated continent, is only half as large as ours. Yet this hasn't kept
> >them from adhering to the international agreement to reserve 145.8-146.0
> >for satellites. In some cases a few repeaters had to be moved or shut
> >down, yet, believe it or not, the world didn't end.
>
> Europe is different. They have very tightly controlled repeater
> allocations - the government does it, and the government can tell them
> to shut down a repeater and make it stick. We can't. Their repeaters are
> also run, not by individuals, but by (large) ham clubs.

    Here we go again! Europe is different. Yes, it is different, they find
they can live without a repeater on every channel. I know of several
repeaters in EU run by individuals, and some run be clubs. Mr Maynard has
already admitted he knows nothing about EU VHF conditions, why oh why does
he then persist on telling us that things are different over there. The only
difference is that there seems to be more attention paid to uses other than
personal repeaters over there. There are no private repeaters over there and
the VHF bands have not been monopolised by repeater barons serving their own
agenda.

    Do I have to present my antecedents here so Mr Maynard will nopt come
back yet again and tell me I don't understand? Would the fact that I used to
be on a Region 1 VHF sub committee help? Please, please lets hear no more
about the chaos of US bands being because: We can't change anything. You
don't understand. It's different over there.

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

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

Date: 6 May 89 23:55:02 GMT
From: dogie.macc.wisc.edu!indri!aplcen!wb3ffv![e-mail]  ( WB3FFV)
Subject: Where to get the latest KA9Q Software...

   Hello,

 It has been a while since I have posted this information, and with the NEW
release of the KA9Q TCP/IP Software I felt I should probably do it again!
Here is the information on how to retreive the latest bits from the WB3FFV
telephone based bulletin board. PLEASE don't leave me a ton of Email, as I
don't have much time to reply...



+------------------------------------------------------------------------------+
    HOW TO ACCESS THE WB3FFV AMATEUR RADIO TELEPHONE BBS !!!


 I have placed a BBS system on-line that is mainly oriented towards the
Amateur Community (but there is other stuff on-line). As of now I have not
attempted to promote this system any place except in the amateur channels
(PACKET, USENET, & word of mouth), and will continue under this policy, as
I hope to keep it oriented toward amateur radio. The various software for
UP/DOWNload is available via telephone dialup and Packet TCP/IP, and through
user support I hope to keep the latest and greatest ham software on-line.
Below is the information that is needed in order to access the BBS via
Telephone -or- TCP/IP, please pass it around to as many ham's as possible.

 System Name: WB3FFV
 Login: bbs
 Number: (301)-335-0858 -- 1200 & 2400 (Non-MNP)
 Number: (301)-335-1955 -- 2400 (MNP), 9600 & 19200 (PEP)
 Data Settings: 8 Bits, NO Parity, 1 Stop Bit
 Times: 24hrs/365days  (except for routine maintenance)
 Software: XBBS  (UNIX/Xenix Multiuser BBS)
 IP Address: 44.60.0.1 {wb3ffv.ampr.org}  [for FTP access on 145.550 mhz ONLY]
 Misc. Info: Machine is an 80386 computer running UNIX V.3.2 and features 300+
         meg of on-line storage. Most transfer protocols are available!!


 I attempt to keep the latest and greatest HAM software on-line, and encourage
all to upload anything new that they come up with, as it is of benefit to all.
Here is a sample of a couple pieces of software that is available for DOWNLOAD:

 KA9Q TCP/IP Software for the PC (Latest OFFICIAL release + TEST Versions)
 KA9Q TCP/IP for the Atari-ST, MAC, & Amiga
 KA9Q TCP/IP for UNIX based systems
 WA7MBL BBS for the PC (Versions 3.31, 4.31 & 5.12)
 W0RLI BBS for the PC (Versions 6.xx, 7.xx, 8.xx, 9.xx)
 Various BBS utilities and enhancements
 Several MORSE CODE Tutors
 TheNet software by NORD><LINK  (Version 1.01)
 Modifications for many HAM Rigs and Scanners
 Digital Signal Processing software (DSP)
 DX and contesting programs
 ARRL Newsletters & Gateway
 W5YI Electronic Edition

 There is much more available on the BBS, and I don't want to waste a lot of
PACKET BBS space trying to list it all, so if you are interested give it a
call and see for yourself !!!

 For anybody that desires to use UUCP for file transfer, use a login
of uucpanon and no password!


P.S. -  This system will be kept current within several days when it
    comes to the TCP/IP software, as I am trying my best to promote
    IP in the PACKET community...


-------------------------------------------------------------------------------
Internet  : [e-mail]     |       Howard D. Leadmon
UUCP      : wb3ffv!howardl              |       Fast Computer Service, Inc.
TELEX     : 152252474                   |       P. O. Box 171
Telephone : [phone]              |       Chase, MD  21027-0171

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

End of PACKET-RADIO Digest
******************************
 9-May-89 02:04:24-MDT,5608;000000000000
Return-Path: <[e-mail]>
Date: Tue,  9 May 89 01:30:11 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #127
To: [e-mail]

PACKET-RADIO Digest         Tue,  9 May 89       Volume 89 : Issue 127

Today's Topics:
        AMPRnet and Re: Help me (and possibly others!)
                KAM vs PK-232
----------------------------------------------------------------------

Date: 8 May 89 12:39:00 EST
From: "NJITX::HXN8477" <[e-mail]>
Subject: AMPRnet and Re: Help me (and possibly others!)

>From: mcvax!ukc!kl-cs![e-mail]  (Atula Herath)
>Subject: Help me (possibly others) !!!
>
>Hi everybody.
>
>I am an amature to the amature radio. Over past few weeks say(5-6) I was
>regularly reading, rec.ham-radio and rec.ham-radio.packet. Things appeard
>were remarkable, and grate, despite the problem that I know nothing about
>that. But I would like to carry on, because it is fasinating. But some
>wizard(s) may like to help me or possibly quite a lot of people like me.
 ^^^^^^
>The area which I am particularly interested is in radio packet switching.
>There were quite a few terms which I collected over past few weeks, that
>I don't understand is :

>BAOUT
>AMTOR
>KISS
>TNC
>PK232
>.......
>,.....

Although I am not the "wizard" that you are probably looking for, I
will volunteer an answer here because I asked a similar question last
year.  What you are looking for is an introduction to packet radio.  This
can best be done by picking up a book on packet.  (I wouldn't say
a magazine article, as magazines usually assume that you know something,
whereas books invariably start from scratch).  One such book is:

           Digital Communications with Amateur Radio
             by Jim Grubbs, k9ei

which is published by Radio Shack, and sells for only $7.  This is
an elementary book which gives you the basics you need to be able
to understand magazine articles on packet, or discussions going on
among 'packeteers'.

As to the list you have above, I think you took the word BAOUT from
a message I posted last week.  I am afraid, this was a typo, where
the actual word is BAUDOT (a digital transimission mode, where every
character is coded as 5 bits).

>......

Now to the rest of the net, I have these questions:

Where can I find info on AMPRnet? (Magazine article, electronic files,
BBS, ftp...etc)  Or if someone can write a few paragraphs about it
it would be appreciated (mainly its current extent, how a station can be
a node on it, who administers it, gateways, if any, to land
networks, such as the Internet, uucp, fidonet, ... etc.)?

Thanks in advance.

      "The only stupid question is the one that is never asked."
______________________________________________________________________________
|Hamed Nassar, PhD          |Internet  : [e-mail] |
|EE Department              |UUCP      : bellcore!argus!mars!nancy           |
|NJ Institute of Technology |CompuServe: 74000,130                           |
|Newark, NJ 07102           |Fidonet   : 1:107/701                           |
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
------

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

Date: 8 May 89 12:41:17 GMT
From: encore!necis![e-mail]  (Rich Bono)
Subject: KAM vs PK-232

I have see a few questions about the differences betweent the Kantronix
KAM and the AEA PK-232.

I own a KAM, and have not had (before now) the chance to compare the KAM
and PK-232 together.  I am very happy with the KAM.  Others (the infamous
"THEY"), have said that the PK-232 is better on HF modes than the KAM, but
the KAM is better at packet (and it gateways between HF and VHF packet).
I have always taken this as a possibility, but have not had the chance to
compare, side-by-side, the KAM and the PK-232.

The next part of this story is as follows:  I happend to be at a friend's
house (Doug, N1FUB), who had recently acquired a PK-233 in a package deal
with some equipment that he purchased.  He already owned a KAM.  This set
the stage for the test that I have been meaning to do... compare the
two under identical conditions.

I am sorry to report that the test FAILED misserably!!! (SP?) The PK-232
put out SO MUCH RFI (noise!) that we couln't hear any signals unless they
were stronger than S9 (much stronger!)...  Yes, the cables were all shielded
and grounds were in place.  The KAM didn't put out any detectable noise.
His computer (a IBM-AT) did put small amount of noise on various frequencies.

So this test will have to be conducted at a later date.... when we get the
PK-232 to be quieter....

Note: The receiving antenna was close the the "shack"... and may account
for the STRONG pick-up of the noise.   OR maybe the PK-232 is sick in some
way... We hope to continue this test.  Maybe at my shack where the antennas
are at least 60 feet from the shack.

                Rich, NM1D

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

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

End of PACKET-RADIO Digest
******************************
10-May-89 02:24:12-MDT,18403;000000000000
Return-Path: <[e-mail]>
Date: Wed, 10 May 89 01:30:37 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #128
To: [e-mail]

PACKET-RADIO Digest         Wed, 10 May 89       Volume 89 : Issue 128

Today's Topics:
                KAM vs PK-232
          Spectrum Planning vs coordinators
           TheNetRom & software innovation (3 msgs)
----------------------------------------------------------------------

Date: 9 May 89 03:19:32 GMT
From: sun-barr!texsun!texbell!bigtex!helps!bongo![e-mail]  (julian macassey)
Subject: KAM vs PK-232

In article <[e-mail]>, [e-mail] (Rich Bono) writes:
> I have see a few questions about the differences betweent the Kantronix
> KAM and the AEA PK-232.
>
> I am sorry to report that the test FAILED misserably!!! (SP?) The PK-232
> put out SO MUCH RFI (noise!) that we couln't hear any signals unless they
> were stronger than S9 (much stronger!)...  Yes, the cables were all shielded
> and grounds were in place.  The KAM didn't put out any detectable noise.
> His computer (a IBM-AT) did put small amount of noise on various frequencies.
>
> So this test will have to be conducted at a later date.... when we get the
> PK-232 to be quieter....
>
> Note: The receiving antenna was close the the "shack"... and may account
> for the STRONG pick-up of the noise.   OR maybe the PK-232 is sick in some
> way... We hope to continue this test.  Maybe at my shack where the antennas
> are at least 60 feet from the shack.

    Am I glad to see this, not because I hate AEA or love Kantronics. In
fact right now, I don't own equipment made by either company. My bone of
contention is RFI generated by "Ham Equipment". When my Toshiba T1100P
laptop spews out junk that interferes with my FM BC reception and clobbers
my walkie talkie, I can't say too much. Sure the equipment is supposed to
pass FCC Part 15 Subpart J, Class B. But just what does it mean?

    As many readers can tell you, and many also have done. You can make any
piece of equipment with Microprocessors in it RF quiet. Manufacturers can
too. In fact it is easier for them. They can do it in production, cheaply,
and easily. If they follow a few simple rules they can make quiet equipment.

    The sad truth alas is that they don't design equipment to be quiet. What
do they care if it radiates? Not a whit until they take the pilot production
stuff into the FCC lab and it radiates like a hooker at a sales meeting. At
this point, panic stricken, they whip, out the ferrites and extra screws on
the case etc. and they get it to squeak by. The shocking secret is that the
unit that passes with all the custom kludges is not the unit that goes into
production. The unit sold to the customers radiates as badly as the unit
that first found its way into the FCC lab.

    So Joe consumer, dosn't really know that his home computer is wiping out
20 meters for the ham two streets away. If his home burgler alarm is causing
herringbones on channel two he blames the TV or the Antenna, maybe even the
ham two streets away.

    We bemoan FCC's lack of vigilence on the ham bands, even commercial
freqs are rotten with pirates in some localities, but the current situation
with computing equipment is shameful. Each day, more and more of these
wideband radiators are entering our neighbourhoods. The impulse crud is bad
enough, but then we also have to fight light dimmer buzz and digital dirt.

    The fact of the matter is that manufacturers are cheating. They kludge a
model together that squeaks through Part 15, Sub J. Then they fob off crap
to the public. Most do that. I have seen some production big name stuff on
test turntables that failed miserably. I bet the salted version the lab saw
passed OK. Some poor soul making peripherals who was foolish enough to buy
one off the shelf to use as a test platform got a nasty shock.

    All this is bad enough, but then we come to TNCs. I have an old
homebuilt TNC-1 in the "Gucci" case. I made a few filtering mods on the in
and out lines as I assembled it and it is the quietest TNC I own. I also own
a Pac-Comm Tiny-2 TNC, its footprint may be tiny, but its RF output is
pretty prodigious. As it came out of the box, it was unusable, there wasn't
a signal on the 2 Meter band louder than the crud from the Tiny-2. Now, come
on, this damn thing is supposed to work with radios. Did anyone ever test it
with a real radio? Well I fixed it myself on the diningroom table. If I
could do it that way, couldn't the manufacturer have done a better job with
a lab and production facilities?

    Then foolishly, I bought a Heath Pocket Packet TNC (HK-21). It seems,
the smaller the TNC, the more it radiates. This thing is a pig. Out of the
box, it is damn near unusable. I expect better from Heath, what were "The
Hams at Heath" doing? I have covered the plastic case with copper foil. With
that and getting it far enough away from antennas and radios, it sorta
works. One day I will get so mad at it, I will fix it. But here's the best
part: It is a certified Part 15 sub J class B device! Says so right there in
the first page of the manual. Has the number on the case too, but I had to
cover mine with copper tape to try and keep the crud in. How did they test
this thing for emissions? The only way I could see them doing it is with the
unit switched off. Seeing as this unit is sold especially for portable
packet where the rig, antenna and TNC are in close prximity it is pretty
negligent. I know, this is a Japanese device purchased by Heath, but they
put their name on it and are exclusive importers to the US.

    I bitch to manufacurers about this, but they don't seem to care. I know
they can make stuff that doesn't wipe out everything from 2 to 300 Megs. It
does not cost anymore to make anything RF quiet to meet Class B. It is not
difficult to do, it is really easy to do in the design stage. It is not too
hard to do at the prototype stage. I am sorry if I have rambled on for too
long, but this is a pet peeve. I hope what I have said was relatively
coherent.

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

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

Date: 9 May 89 16:20:00 GMT
From: ux1.cso.uiuc.edu![e-mail]
Subject: Spectrum Planning vs coordinators

There is a clear distinction between the functions of a repeater coordinating
group, and a spectrum planning group.  The spectrum planning function needs
to consider all uses of radio spectrum.  I hear (although do not agree with)
the arguments that only repeater owners should determine the policies for
repeater coordinators.  However, when a group such as Illinois Repeater
Association is starting to do spectrum planning, and still only allows the
owners of repeaters to have voting membership, then I something is seriously
wrong.  What it may be is simply the vacuum of no one else doing the
spectrum planning function.  At this point I am going to be looking into
the creation of a new organization, probably to be called the Illinois
Spectrum Planning Association, which would be open to all licensed amateurs
residing in the state.  Then the issues of packet vs. repeaters vs. ATV vs.
satellites vs. spread spectrum vs. whatever-else-comes-along-next can be
equally and fairly discussed and resolved.

That will still leave open the problems of repeaters being spectrum hogs by
not making an effort to tighten up their spacings, use PL and anti-PL, and
not consider every case of overlap as interference.  It still does not solve
the problem of the repeater owners ganging together for little more than to
protect their turf.  I believe the FCC's decision to not recognize official
coordinators is correct.  Anyone CAN be a coordinator.  I am still thinking
about it.

--phil ka9wgn--

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

Date: 9 May 89 14:48:00 GMT
From: ux1.cso.uiuc.edu![e-mail]
Subject: TheNetRom & software innovation

The issues in a past posting here, and in a recent (June!) article in 73
Magazine about the alleged theft of Net/ROM code in TheNet has got me to
thinking again about these issues.

First of all, The FCC has nothing to do whatsoever with software piracy.
Anyone who wants the FCC to do something about it should go read the
Communications Act and see if they can find anything in there about it.
I can save you some time and tell you it isn't in there.  Software
piracy just is not a communications issue; it's one of commerce, and
international in this case.

Reverse engineering is in fact quite commonplace.  I suspect that many of
the mods to our computer controlled radios are determined by reverse
engineering since the manufacturers do not admit to them in many cases.
Of course some of this could just be leaks from inside the companies.

Reverse engineering is still commonplace in the entire electronics and
computer industry.  The clone makers do it to see what is REALLY going on
since it is almost impossible to build a clone from specs alone the first
time around due to the poor quality of those specs.  IBM has no burning
need to make the specs so thorough that anyone can duplicate their machines.

Reverse engineering of software is even more commonplace than for hardware
just because the specs here are so vague.  Anyone who does this, though,
has to be extra careful not to let the original code slip into the clone
product.  Apparently, the makers of TheNet messed up on this one, or else
hoped that no one would notice.

One thing I do wonder about is how good the specs are, and if they are even
available to anyone who wants them.  Take for example the TNC-2 that Net/ROM
and TheNet were designed for.  Are there a set of specs that do in fact tell
you all that you need to know about the hardware so that you could write
software for it?  Are they available to anyone who wants them?  Would TAPR
be willing to give them out for copying costs, sell them, or are they just
wanting to keep them as a trade secret (and a challenge to hackers)?

Also, would the make of Net/ROM be equally as willing to reveal the protocol
details about how Net/ROM nodes talk to each other (what goes over the air)
so that a truly legitimate original effect at cloning Net/ROM would be at
the least, compatible with Net/ROM as a network component?

I'm not sure who to contact about getting the above information, so I have
not yet actually tried.  This information is clearly NOT as readily available
as DDN/Internet protocols are, nor are they as readily available as mods to
popular Japanese radios.

Can someone supply some information about the availability of this
information?  I want to continue the ham spirit of home-brew and building,
but in the software context.

I am a programmer, not an electrical engineer, so my construction tools are
assemblers, compilers, editors, and loaders.  Hardware is still needed.
I see no reason that there cannot be hardware sold commercially that can be
the base for a programming effort, and not be a full blown PC with a ton of
added cards.  What I would like to see is for the manufacturer of each kind
of equipment for amateur radio that uses a processor (TNC's, HT's, base rigs,
mobile rigs, and even repeater controllers) to supply clear and complete
programming specs for their hardware so that the software hams among us all
have a chance to program the hardware to do the things we want (and think of).

Let's have some innovation on the software side as well.  Net/ROM was just
a start.

--phil ka9wgn--

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

Date: 10 May 89 03:20:48 GMT
From: jupiter![e-mail]  (Phil R. Karn)
Subject: TheNetRom & software innovation

>One thing I do wonder about is how good the specs are, and if they are even
>available to anyone who wants them.  Take for example the TNC-2 that Net/ROM
>and TheNet were designed for.  Are there a set of specs that do in fact tell
>you all that you need to know about the hardware so that you could write
>software for it?  Are they available to anyone who wants them?  Would TAPR
>be willing to give them out for copying costs, sell them, or are they just
>wanting to keep them as a trade secret (and a challenge to hackers)?

Buy a (licensed) clone of a TAPR TNC (e.g., the MFJ) and you will find a
complete schematic in the back of the manual. This plus standard data
sheets for each of the main components (CPU, SIO, etc) are really about
all you need for "hardware specs" when it comes to programming.  (In the
case of the SIO you'll probably find your biggest handicap to be Zilog's
very poorly written programming manual.)

>Also, would the make of Net/ROM be equally as willing to reveal the protocol
>details about how Net/ROM nodes talk to each other (what goes over the air)
>so that a truly legitimate original effect at cloning Net/ROM would be at
>the least, compatible with Net/ROM as a network component?

The NET/ROM manual contains an (admittedly sketchy) description of the
internal protocol headers. Even without these, however, one can "reverse
engineer" the protocol without ever removing the EPROM from its socket
and disassembling the code -- you simply watch how it behaves
externally. Ask Dan Frank, W9NK, who wrote the NET/ROM emulation code in
my TCP/IP package -- I'm sure he can tell you in gory detail how he did
it. Software 2000 has repeatedly stated that Dan's work does not in any
way infringe their copyright, and that they in fact welcome his work.

Phil

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

Date: 10 May 89 02:41:34 GMT
From: bbn.com![e-mail]  (Bob Clements)
Subject: TheNetRom & software innovation

In article <[e-mail]> [e-mail] writes:
>
>The issues in a past posting here, and in a recent (June!) article in 73
>Magazine about the alleged theft of Net/ROM code in TheNet has got me to
>thinking again about these issues.

Good!  THe silence has been deafening.  When I posted on the subject, I
got almost no response, except for a few pieces of email such as one
from a non-sentient who said "TheNet works for me and that's all I care."

>Reverse engineering is in fact quite commonplace.

Sure. But there's a difference between reverse engineering to figure
out how something works and reverse engineering to be able to mechanically
copy the original author's work. TheNet is the latter.  It's called "theft".

>One thing I do wonder about is how good the specs are, and if they are even
>available to anyone who wants them.  Take for example the TNC-2 that Net/ROM
>and TheNet were designed for.  Are there a set of specs that do in fact tell
>you all that you need to know about the hardware so that you could write
>software for it?  Are they available to anyone who wants them?

The TNC-2 was always sold with complete schematics and technical descriptions.
All the chips are off-the-shelf and their programming info is available from
the chip vendors.

>Would TAPR
>be willing to give them out for copying costs, sell them, or are they just
>wanting to keep them as a trade secret (and a challenge to hackers)?

They came with every kit.  I don't know if you can get them
without buying even one kit.  I would guess so but I dunno.  But
then the kits were pretty cheap and you need one to run your code
on, don't you?

>Also, would the make of Net/ROM be equally as willing to reveal the protocol
>details about how Net/ROM nodes talk to each other (what goes over the air)
>so that a truly legitimate original effect at cloning Net/ROM would be at
>the least, compatible with Net/ROM as a network component?

Yes. The protocol manual was sold to all comers for $5.  It specifically
invited others to make compatible products.  And Dan Frank has implemented
just that in the Phil Karn (et al) TCP/IP system.

>I'm not sure who to contact about getting the above information, so I have
>not yet actually tried.  This information is clearly NOT as readily available
>as DDN/Internet protocols are, nor are they as readily available as mods to
>popular Japanese radios.

Pretty available.  If you want specific mailing addresses, rather than just
an answer to the question "is it available", send me email and I'll
dig them up.

>I see no reason that there cannot be hardware sold commercially that can be
>the base for a programming effort, and not be a full blown PC with a ton of
>added cards.

TAPR has done that with the TNC-1 and TNC-2, and the less-successful NNC.
On the other hand, a basic clone PC with a floppy is as cheap as
just about any new radio/HT/mobile rig you can name.

>What I would like to see is for the manufacturer of each kind
>of equipment for amateur radio that uses a processor (TNC's, HT's, base rigs,
>mobile rigs, and even repeater controllers) to supply clear and complete
>programming specs for their hardware so that the software hams among us all
>have a chance to program the hardware to do the things we want (and think of).

This is unfortunately less likely.  TAPR is a ham club.  The
others you mention are not.  NET/ROM is from a small company (two
hams, I think) and they published their protocol but not their
code.  The radio makers are publishing their computer-controlled
interface specs.  But code for a repeater controller is pretty
unlikely, since that's their bread and butter.  If you'll sign a
non-disclosure agreement, I'll show you mine.  It's been on the
air on four or five machines here in Boston for over a decade.
Nice easy Z-80 assembler.  :-)

>Let's have some innovation on the software side as well.  Net/ROM was just
>a start.

You are aware of the KA9Q TCP/IP effort, I assume?  Lots of us have
contributed to that.

>--phil ka9wgn--

73,
Bob, K1BC
[e-mail]

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

End of PACKET-RADIO Digest
******************************
11-May-89 02:26:27-MDT,15626;000000000000
Return-Path: <[e-mail]>
Date: Thu, 11 May 89 01:30:36 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #129
To: [e-mail]

PACKET-RADIO Digest         Thu, 11 May 89       Volume 89 : Issue 129

Today's Topics:
       FCC's recognition of repeater coordinators is a disaster
           How to access the WB3FFV BBS...
         TCP/IP over AX25 using a Sun (help required)
              TNC reviews - info request
            TNC RFI (was Re: KAM vs PK-232
             wanted: TEXNET info
        What kind of PSK is used on FO-12? MicroSats?
----------------------------------------------------------------------

Date: 9 May 89 22:50:13 GMT
From: mcvax!hp4nl!phigate!nlgvax![e-mail]  (Geert Jan de Groot)
Subject: FCC's recognition of repeater coordinators is a disaster

Some notes from Holland, where we seem to manage with only 2MHz on 144..

In article <[e-mail]> [e-mail] (Jay "you ignorant splut!" Maynard) writes:
>In article <[e-mail]> [e-mail] (Phil R. Karn) writes:
>>First of all, the amateur satellite allocation on 2m is from 145.8 to
>>146.0. That's only 200 KHz, not 500 KHz. There are many simplex users
>>(voice and packet) in the 145.5-145.8 range around here.
>
>Wanna use that space for repeaters? Go talk to the FCC, not me.
>There has been some complaining, though - even before the shuttle
>flights with hams aboard - about terrestrial FM simplex on 145.555 in
>particular, and the reason given was that it interfered with satellite
>use.

Huh? 145.550 is used in Europe as a simplex channel. I can't imagine
any satelite group using that frequency for satelites. Has the complaint
been checked?
Apart from Shuttle and MIR activities (where people were just requested
to QSY if they interfered), I see no connection between 145.550 and
space operations.

>>Remember that the 2m band in Europe, a very densely
>>populated continent, is only half as large as ours. Yet this hasn't kept
>>them from adhering to the international agreement to reserve 145.8-146.0
>>for satellites. In some cases a few repeaters had to be moved or shut
>>down, yet, believe it or not, the world didn't end.
>
>Europe is different. They have very tightly controlled repeater
>allocations - the government does it, and the government can tell them
>to shut down a repeater and make it stick. We can't. Their repeaters are
>also run, not by individuals, but by (large) ham clubs.

Not true, at least not in Holland. Yes, government officially gives
the special repeater licenses. However, they do this directly on the
directions given by the amateur radio clubs. Thus, in fact, the clubs
manage the repeater allocations.

What's different is, that we didn't allow any repeaters for special
groups, or more than one repeater for the same working area.
Some years ago, someone got a map of Holland, drew some circles
on that, and every circle just got ONE repeater allocated - per band.
If somebody else wants to set up a repeater, he can't get a license
and cannot run the machine unattended (note that experimental repeaters
can be set up, but if the owner leaves, that repeater must be SHUT OFF.
The same applies for digipeaters, BBS and other stations.)

Also, closed repeaters are out of the question. We can't have the luxury
(hope i spelled that correct - it's late) of reserved frequencies on
tightly used bands. If I read all your messages, I wonder if the USA
still can afford closed repeaters on 2. Why not move those repeaters to
higher bands?

In the past, some repeaters were set up on 145.800 and 145.825.
These frequencies are no longer available for repeaters, and the existing
repeaters have moved. Thus, it can be done!

73
Geert Jan


--8<--nip-nip---------------------------------------------------------------

Geert Jan de Groot,                     Email: [e-mail]
Philips Research Laboratories,                 ..!mcvax!nlgvax!geertj
Project Centre Geldrop,                 Ham: PE1HZG
Building XP, Room 4,
Willem Alexanderlaan 7B,                "MS-DOS is just a bootstrap" - me
5664 AN Geldrop, The Netherlands.
phone: [phone]                    [Standard disclaimers apply]

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

Date: 9 May 89 22:36:33 GMT
From: indri!aplcen!wb3ffv![e-mail]  (Howard Leadmon - WB3FFV)
Subject: How to access the WB3FFV BBS...

   Hello All,

 I sent out a message the other day telling people how to get the latest
bits (KA9Q release 890421.0) from my BBS, and mentioned that anyone
interested could use anonymous UUCP to access the files. What I forgot
was to tell everybody how to find the information on the files you desire
to retrieve. Well here one more time is the listing, and hopefully with
enough information to allow anybody access that desires the information...




+------------------------------------------------------------------------------+
    HOW TO ACCESS THE WB3FFV AMATEUR RADIO TELEPHONE BBS !!!


 I have placed a BBS system on-line that is mainly oriented towards the
Amateur Community (but there is other stuff on-line). As of now I have not
attempted to promote this system any place except in the amateur channels
(PACKET, USENET, & word of mouth), and will continue under this policy, as
I hope to keep it oriented toward amateur radio. The various software for
UP/DOWNload is available via telephone dialup and Packet TCP/IP, and through
user support I hope to keep the latest and greatest ham software on-line.
Below is the information that is needed in order to access the BBS via
Telephone -or- TCP/IP, please pass it around to as many ham's as possible.

 System Name: WB3FFV
 Login: bbs
 Number: (301)-335-0858 -- 1200 & 2400 (Non-MNP)
 Number: (301)-335-1955 -- 2400 (MNP), 9600 & 19200 (PEP)
 Data Settings: 8 Bits, NO Parity, 1 Stop Bit
 Times: 24hrs/365days  (except for routine maintenance)
 Software: XBBS  (UNIX/Xenix Multiuser BBS)
 IP Address: 44.60.0.1 {wb3ffv.ampr.org}  [for FTP access on 145.550 mhz ONLY]
 Misc. Info: Machine is an 80386 computer running UNIX V.3.2 and features 300+
         meg of on-line storage. Most transfer protocols are available!!


 I attempt to keep the latest and greatest HAM software on-line, and encourage
all to upload anything new that they come up with, as it is of benefit to all.
Here is a sample of a couple pieces of software that is available for DOWNLOAD:

 KA9Q TCP/IP Software for the PC (Latest OFFICIAL release + TEST Versions)
 KA9Q TCP/IP for the Atari-ST, MAC, & Amiga
 KA9Q TCP/IP for UNIX based systems
 WA7MBL BBS for the PC (Versions 3.31, 4.31 & 5.12)
 W0RLI BBS for the PC (Versions 6.xx, 7.xx, 8.xx, 9.xx)
 Various BBS utilities and enhancements
 Several MORSE CODE Tutors
 TheNet software by NORD><LINK  (Version 1.01)
 Modifications for many HAM Rigs and Scanners
 Digital Signal Processing software (DSP)
 DX and contesting programs
 ARRL Newsletters & Gateway
 W5YI Electronic Edition

 There is much more available on the BBS, and I don't want to waste a lot of
PACKET BBS space trying to list it all, so if you are interested give it a
call and see for yourself !!!

 For anybody that desires to use UUCP for file transfer, use a login
of uucpanon and no password! Also to obtain a listing of the files that
are avalible for UUCP transfer, request a file called FILES in the
directory /usr/spool/uucppublic.


P.S. -  This system will be kept current within several days when it
    comes to the TCP/IP software, as I am trying my best to promote
    IP in the PACKET community...


-------------------------------------------------------------------------------
Internet  : [e-mail]     |       Howard D. Leadmon
UUCP      : wb3ffv!howardl              |       Fast Computer Service, Inc.
TELEX     : 152252474                   |       P. O. Box 171
Telephone : [phone]              |       Chase, MD  21027-0171

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

Date: 8 May 89 12:55:01 GMT
From: mcvax!ukc!strath-cs!glasgow!bru-cc!haley![e-mail]  (Kevin Quinlan)
Subject: TCP/IP over AX25 using a Sun (help required)

OK - maybe this is just me being stupid, or showing my ignorance.

But I have been trying to get the KA9Q software going on a Sun 2,
without much luck so far.  But in any case it seems to me that
it is not exactly what I want.

It may not be the best machine in the world, but the Sun 2 comes
with support for TCP/IP and other networking tools emulated (OK
implemented) in KA9Q net such as smtp etc etc.

Therefore I think the ideal solution for me would be an AX25
driver for the serial line that could be ifconfig'd to listen to
and talk on the 44.131 network.

Question is - has anybody done it already?

If not - does anyone have a good idea on where to start, would
it be possible for instance to alter the SLIP code to suit this
application?

Please forgive me if this is the wrong thing to ask, or if the
answer is so painfully obvious that I should have known it
already, but I am new to this game (my callsign will tell you
that), I am also keen to learn though.

Kevin Quinlan
(G7DZD)
 +---------------------------------------------------------------+
 | Kevin Quinlan, Prime Computer R & D, Amersham, HP7 0PX, UK    |
 | [e-mail]                                      |
 | [e-mail]                  [phone] x 269   |
 +---------------------------------------------------------------+

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

Date: 8 May 89 14:23:23 GMT
From: mailrus!sharkey!teemc!ka3ovk![e-mail]  (Jon Albers.)
Subject: TNC reviews - info request

In article <[e-mail]> you write:
>Dear all,
>Can anybody give me reviews of the Kantronics KAM, the AEA PK-232, and
>the MFJ MFJ-1278?  I am considering buying one of these.  I want a TNC

I have owned the MFJ-1278 for about a yesr now, and am really pleased with it.
I had also consodered the PK-232, but chose the MFJ over it for a couple of
reasons:

    First, the MFJ was about $40 cheaper at the time.  Both units have
    similar features, so this really helped.

    Also, the MFJ is much smaller than the PK-232.  In a crowded shack,
    this was a plus for me.

    For HF work, I think the MFJ has a better tuning system -- just
    center an LED and you're tuned.  The PK-232 has a 'closeure' type
    tuning system, where you must tune the radio AND adjust the audio
    level to 'close' 2 LED bar graphs.  The MFJ audio adjustment is
    almost a one-time thing.  It seems to have a good AGC.

    There was one plus to the PK-232 -- the front panel has an LED for
    almost ANY function, so at a glance, you can tell what mode the 232
    is in.

Anyhow, about the software -- any communications software, such as you would
use with a modem, will work fine for the 'pure digital' modes, but to display
FAX, SSTV, etc. on your screen, you will have to use their software on a
PC compatable. (With the MFJ, though, you can plug in any EPSON compatable
graphics printer, and print out FAX and SSTV reguardless of what computer
you have!)

                                Jon


--
| Jon Albers, IRS, Computer Services, Site Support and Installation(CS:M:S:P) |
| UUCP:      (drilex|infopro|teemc|tcsc3b2|ki4pv|wb3ffv)!ka3ovk!(root|albers) |
| ARPA: JALBERS@SIMTEL20    Have Trailblazer, will connect................... |
|     ka3ovk: Compaq 386/25 Model 300 SCO XENIX-386 Sys V ver 2.3.1           |
---
| Jon Albers, IRS, Computer Services, Site Support and Installation(CS:M:S:P) |
| UUCP:      (drilex|infopro|teemc|tcsc3b2|ki4pv|wb3ffv)!ka3ovk!(root|albers) |
| ARPA: JALBERS@SIMTEL20    Have Trailblazer, will connect................... |
|     ka3ovk: Compaq 386/25 Model 300 SCO XENIX-386 Sys V ver 2.3.1           |

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

Date: 10 May 89 14:51:41 GMT
From: philmtl!philabs!briar.philips.com![e-mail]  (Robert Casey;6282;3.57;$0201)
Subject: TNC RFI (was Re: KAM vs PK-232

My packet station has a KPC2, a modified motorola HT220 with a power amp (~7W)
mounted in a metal box, and a switching power supply.  The antenna is about 20
feet away in the attic.  I used small coax cable to connect the speaker and
mic lines.  I got things so that the radio, when unsquelched, would hear more
hiss than digital crud.  But I found some RFI on TV channel 4 and 5.  I tried
shielded RS232 cables, no good.  I had some small ferrite life-saver shaped
beeds with two sets of wire with about 13 turns.  The beeds are about 1/4'
diameter.  I put the beeds in all the lines of the RS232 including the
grounds (the RS232 required only 2 signals, pins 2 and 3).  This reduced the
rfi a lot.  The many turns of wire on the beeds was what it took to stop the
rfi (I tried a beed over a wire (one turn) but that didn't do it).  It looks
like that putting a beed in the ground was also needed, to keep the RS232
cable from acting like a long-wire radiating antenna.  I didn't use beeds on
the mic and speaker and ptt lines, guess that those grounds are better grounds
than the RS232 grounds on the TNC.  (rfi can drive one nuts! :-) )
-> (Just another thing to try when fighting RFI) ^
73 de WA2ISE

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

Date: 5 May 89 15:41:02 GMT
From: shlump.dec.com![e-mail]  (Fred Goldstein k1io)
Subject: wanted: TEXNET info

In article <[e-mail]>, [e-mail] (Greg Jones) writes...
#In article <[e-mail]> [e-mail] writes:
#>is there someone out in networld who could enlighten me about some
#>details of the TEXNET stuff? Any info would be appreciated.
#>Please e-mail direkt to c0033003 @ dbstu1.bitnet
#>tnx in advance.
#>73s de Detlef ( dk4eg @ dk0mav )
#
#Hi Detlef - you should be receiving some files concerning TexNet
#via your BITNET account, but for the rest of the folks out there
#in net land - here is what I sent.
#
#Hope the info helps --- greg

Greg,
    I too appreciate your posting the TEXnet info.  However,
it just whets the appetite (among us techies) for more dope!

    Can you (or somebody) summarize for us what TEXnet uses
for protocols?  In particular, how does it do wide-area stuff?  Is
it like X.25 PLP (CONS, like ROSE), or is it like NET/ROM, like
IP, or homegrown?

    Enquiring minds want to know.  Thanx,
      fred k1io

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

Date: 10 May 89 04:14:43 GMT
From: att!homxb!hotps!ka2qhd![e-mail]  (John Magliacane Wall Township NJ)
Subject: What kind of PSK is used on FO-12? MicroSats?

Could someone please tell me what kind of PSK modulation is used on FO-12
mode JD. What about the "MicroSats"? I understand G3RUH has a PSK modem kit
that works with FO-12 on mode JD, and "RadioKit" sells a PSK modem kit for
satellite use.

...But what do these modems consist of?? Are they similar to BELL 212??
Do they run BPSK? QPSK? What baud rates are involved??

HELP! (Please!)

73, John  KD2BD

--
 UUCP   : ucbvax!rutgers!petsd!tsdiag!ka2qhd!kd2bd
 PACKET : KD2BD @ NN2Z (John)
      ..."There is no expedient to which a man will not resort to
      avoid the real labor of thinking." ....Sir Joshua Reynolds.

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

End of PACKET-RADIO Digest
******************************
12-May-89 02:26:44-MDT,12386;000000000000
Return-Path: <[e-mail]>
Date: Fri, 12 May 89 01:30:16 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #130
To: [e-mail]

PACKET-RADIO Digest         Fri, 12 May 89       Volume 89 : Issue 130

Today's Topics:
       FCC's recognition of repeater coordinators is a disaster
                KAM vs PK-232
                   MFJ TNCs
           Need KA9Q for Convergent system
         TCP/IP over AX25 using a Sun (help required)
           TheNetRom & software innovation (2 msgs)
----------------------------------------------------------------------

Date: 11 May 89 15:15:53 GMT
From: shlump.dec.com![e-mail]  (Fred k1io)
Subject: FCC's recognition of repeater coordinators is a disaster

In article <[e-mail]>, [e-mail] writes...
..>Fred, I agree with you on most of the things you have said in previous
>messages but you have lost me on this one! I seriously don't understand
>what the problem is.

>The thoughts that I have are as follows:

>1. If you going to end up making some people irate anyway, is there a way
>to affect LESS people and cause LESS of a financial setback? If you end up
        ^ you mean FEWER, not LESS.  Sorry.  Couldn't help myself!
>trying to move an established repeater, then you are in for a battle. Not
>necessarily impossible mind you (I don't agree with Jay Maynard :-)  but
>a battle none the less. If you cause a problem to simplex users they only
>need to change to another simplex freq., (a flip of the dial) not redo a
>whole repeater.

The problem isn't more Simplex frequencies for packet, it's having ANY
REPEATER frequencies for packet.  The only thing odd-ball splits will
buy you is to let you squeeze into the usually-simplex areas (200 kHz)
in the middle of each repeater MHz.  The FCC won't let you put a
repeater on 145.71 or 144.49.

You need real repeaters in order to get CSMA or CSMA/CD operation.
CSMA requires  that you abolish "hidden transmitters" so you can hear
everyone else when you're listening.  CSMA/CD requires that PLUS
hearing everyone else when you're transmitting.  The latter means you
need either duplexers or crossband operation.  Sure, you can squeeze
a crossband operation into the area around 147.5 and again on 450
someplace.  But it's not a generalized answer.

>2. Most radios today DO support non standard splits. The ones that don't are
>the exception to the rule. You name me one that doesn't (and I know there are
>a few) and I'll name you 10 that do. :-)    And if you really just HAVE to
>use one that doesn't support it (such as an ICOM IC-2AT) then you can easily
>modify it to where it does. Am I out to lunch here?

Well, neither my FT221 nor TH21AT support odd-ball splits; both use
discrete crystals for offsets.  They'r both old, of course; brandy-new
radios can do oddball splits, but they've gotten costly.  All the
non-HT radios now have silly voice-oriented bells and whilstles.

>Lastly and as an adjunct, have you read about the proposed idea of using
>DAMA (Demand Assigned Multiple Access) instead of CSMA on packet radio?
>The idea seems to have merit and solves the problems of hidden transmitters
>in a much more elegant fashion than a duplex digi... although I agree that
>duplex systems are pretty slick.

Lots of problems there.  Polling time is too long with T/R switching
delays; else it's too inelastic of varied demand, it's messy to get
a node attached, etc.  Nice hack concept but I don't think it'll ever
work for ham radio.  Just an opinion of course.  CSMA is easier to make
work.  Cheap, too, except of course that the FM boys have a stranglehold
on the bands in many areas.
       fred k1io

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

Date: 10 May 89 15:31:29 GMT
From: ginosko!infinet!ulowell!tegra![e-mail]  (Johnathan Vail)
Subject: KAM vs PK-232

In article <[e-mail]> [e-mail] (julian macassey) writes:

   In article <[e-mail]>, [e-mail] (Rich Bono) writes:
   > I am sorry to report that the test FAILED misserably!!! (SP?) The PK-232
   > put out SO MUCH RFI (noise!) that we couln't hear any signals unless they
   > were stronger than S9 (much stronger!)...  Yes, the cables were all shielded
   > and grounds were in place.  The KAM didn't put out any detectable noise.
   > His computer (a IBM-AT) did put small amount of noise on various frequencies.

       As many readers can tell you, and many also have done. You can make any
   piece of equipment with Microprocessors in it RF quiet. Manufacturers can
   too. In fact it is easier for them. They can do it in production, cheaply,
   and easily. If they follow a few simple rules they can make quiet equipment.

       The sad truth alas is that they don't design equipment to be quiet. What
   do they care if it radiates? Not a whit until they take the pilot production
   stuff into the FCC lab and it radiates like a hooker at a sales meeting. At
   this point, panic stricken, they whip, out the ferrites and extra screws on
   the case etc. and they get it to squeak by. The shocking secret is that the
   unit that passes with all the custom kludges is not the unit that goes into
   production. The unit sold to the customers radiates as badly as the unit
   that first found its way into the FCC lab.

    [ various RFI war stories deleted --jv]

I think we all have had problems here.  I am trying to get my computer
usable while I'm doing mode B satellite operation.  Now I am piecing
together a clone dedicated to full time TCP/IP.  Maybe you, or someone
can offer some suggestions and tecniques for shielding our own
equipment.  I will offer what little I know about this "black" art.

Some things can really only come from the manufacturer and designer.
Short runs on the PCB, proper ground planes and such.  Data buses,
clocks and other signals need to be properly terminated.

Shieleding, I belives is very important, as are chassis grounds
connected to the ground planes on the PCB.  A line filter should limit
the conducted emissions.  Magic juju beads (ferrets (ferrites:->)) on
the cables exiting the machine are a band-aid but can be effectives.
Clamp on ferrites on disk drive cables in the box help also.

These are tips I have pickup up from the EMI guys but I am sure there
are other tecniques and I hope someone with more knowledge will share
it with us.  Thanks...

.         /|/|
  _______/ | |
    ( )  \ | |
      \|\|
 _____
|     | Johnathan Vail | tegra![e-mail]
|Tegra| [phone] | N1DXG@145.110-,145.270-,444.2+,448.625-
 -----

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

Date: 12 May 89 04:35:51 GMT
From: oliveb!3comvax!bridge2![e-mail]  (Chuck Kranz)
Subject: MFJ TNCs

I have both, an old 1270 which I upgraded to 32K and KISS firmware, and
a 1278. What I've found out is the need to fully align the units before
really being serious about performance. In each case I got out the scope
and freq counter and performed all of the alignment steps in the manuals.
I think, for the price difference the MFJs have filled my expectations.
So, expect to save a few bucks but also expect to do some tweaking.

            73,
            Chuck Kranz WA7OEF   [e-mail]   (h)
                         [e-mail]   (w)

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

Date: 11 May 89 21:11:23 GMT
From: oliveb!3comvax!bridge2![e-mail]  (Chuck Kranz)
Subject: Need KA9Q for Convergent system

Has anyone successfully installed NET on a Convergent MiniFrame system?
If so I would appreciate any pointers to source code. It's running
CTIX system V at 3.1. Thanks in advance for any help in my getting the
code.


            73,
            Chuck Kranz   [e-mail]   (h)
                      [e-mail]   (w)

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

Date: 11 May 89 07:04:51 GMT
From: ka9q.bellcore.com![e-mail]  (Phil Karn)
Subject: TCP/IP over AX25 using a Sun (help required)

The easiest way to put a Sun workstation (like the 3/75 I'm typing on at the
moment) up on packet radio is NOT to modify anything on the Sun.  Just get a
cheap, stripped PC/XT clone and use it as a dedicated IP gateway between a
local Ethernet and the packet radio channel. Then plug your Sun into the
Ethernet and let it talk to the world.

That's what I do here, and it works quite well. The only modifications to
the software on the Sun involved making sure I was running the latest Van
Jacobsen/Mike Karels version of TCP, so that it would behave reasonably when
operating over slow and unreliable packet radio paths. The Sun knows nothing
whatsoever about AX.25, but that doesn't keep it from communicating with
sites that do speak AX.25 (as long as they speak TCP/IP on top of it, that
is). This is what "internetworking" is all about.

Phil

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

Date: 11 May 89 04:01:00 GMT
From: ux1.cso.uiuc.edu![e-mail]
Subject: TheNetRom & software innovation

> TAPR has done that with the TNC-1 and TNC-2, and the less-successful NNC.
> On the other hand, a basic clone PC with a floppy is as cheap as
> just about any new radio/HT/mobile rig you can name.

Not as small as a Kantronics TNC is.  Also, consider the power drain of a
clone PC.  Typical TNC boxes are cheaper than clone PC's but that alone is
not enough.  Their small size and low power make them rather nice.  Now
what I want to be able to do is leave my PC at home and develop software
of my own design to run on the TNC, burn PROMS, and run them.

> But code for a repeater controller is pretty
> unlikely, since that's their bread and butter.  If you'll sign a
> non-disclosure agreement, I'll show you mine.  It's been on the
> air on four or five machines here in Boston for over a decade.
> Nice easy Z-80 assembler.  :-)

Obviously you must be selling it or anticipate the possibility of selling it.
I have ideas I'd like to see in repeater control logic.  Buying and running a
repeater would be a major investment for me, and I would not do so unless I
knew that I would have lots of control over how it worked.

Is your code running on commercially made repeater controllers?  It was very
frustrating talking to the sales people for some of the repeater makers at
Dayton because they just didn't understand the things I was talking about.
When I said "program the repeater", they kept saying things like "sure, you
can program it, you can turn any feature on or off that you want".  ARRRGH!!!
Their features were mostly uninteresting.

Perhaps if you are interested, we could talk by Email about what features and
ideas for repeater controllers.

> You are aware of the KA9Q TCP/IP effort, I assume?  Lots of us have
> contributed to that.

Yes, and I think it is great.  I would like to see innovations in other
areas as well.  Everything with a CPU in it should be programmable by anyone
interested and willing to do it.  The quality of so much market driven
program design these days is rather pathetic.  That's why I cannot work
in industry as a programmer; it would be too limiting for me.

--phil ka9wgn--

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

Date: 12 May 89 01:09:22 GMT
From: [e-mail]  (Andrew Payne)
Subject: TheNetRom & software innovation

In article <[e-mail]> [e-mail] writes:
>> TAPR has done that with the TNC-1 and TNC-2, and the less-successful NNC.
                                    ^^^
    What exactly is the "NNC" (Network Node Controller??)?  I've run
into references to the NNC here and there but have yet to find a description
of the device.  Anyone have the gory details?

--
=  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =
Andrew C. Payne, N8KEI        UUCP:  ...!cornell!batcomputer!payne
              INTERNET:  [e-mail]
PHONE: [phone]      USMAIL:  5428 Cls '26-UHall 5   Ithaca, NY  14853

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

End of PACKET-RADIO Digest
******************************
13-May-89 03:31:20-MDT,16860;000000000000
Mail-From: KPETERSEN created at 13-May-89 03:20:47
Return-Path: <[e-mail]>
Date: Sat, 13 May 89 03:20:45 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #131
To: [e-mail]

PACKET-RADIO Digest         Sat, 13 May 89       Volume 89 : Issue 131

Today's Topics:
               Gateway 4/28/89
----------------------------------------------------------------------

Date: 13 May 89 02:29:55 GMT
From: n8emr![e-mail]  (Gary Sanders)
Subject: Gateway 4/28/89

Gateway: The ARRL Packet Radio Newsletter

Stan Horzepa, WA1LOU, Editor - - Volume 5, Number 16 - - April 28, 1989

         HF PACKET-RADIO COOPERATIVE DESIGN EFFORT

On April 5, the ARRL announced the creation of a new project to develop the
next generation of modems and protocols for HF packet-radio operation.  The
project will coordinate the efforts of Amateur Radio designers whose
proposals are adopted by the ARRL.  Modest funding will be available for
reimbursement of approved direct out-of- pocket expenses related to the
development of prototypes, but not labor, overhead or other costs.  General
information concerning this project can be found in the May issue of QST,
pages 55-56.

Funding for this project is to come from two sources.  One is from the
League's Technology Fund, which welcomes individual and corporate
contributions.  Also, the League has applied to the Federal Emergency
Management Agency (FEMA) for a small grant to help underwrite this project.
FEMA has indicated keen interest in this project because they want to
retain their ability to communicate directly with ham radio operators using
packet radio and, furthermore, they need to encourage interoperability
between equipment owned by FEMA and amateurs.  In addition, they believe
that hams will develop equipment that is inexpensive enough to permit
large-quantity procurement by the Federal Government.

Serious designers interested in participating in this development project
may obtain further information from Lori Weinberg at ARRL Headquarters.

      CODELESS LICENSE WITH PACKET-RADIO PRIVILEGES PROPOSED

A special committee appointed by ARRL President Larry E. Price, W4RA, has
submitted a report recommending the creation of a class of Amateur Radio
license not requiring a knowledge of Morse code.  The report was presented
to the ARRL Executive Committee, which met on April 1; the Executive
Committee did not take a position on the substance of the report, but
referred it to the full Board of Directors for consideration during its
July 21-22, 1989, meeting.  ARRL members, other licensed radio amateurs and
others interested in Amateur Radio are invited to review the report and to
make their views known to ARRL Division Directors, whose names appear on
page 8 of QST.

The special committee stressed that its proposal, if adopted, would not
cause any licensee to lose any present privileges.  It proposed a new class
of Amateur Radio license, with a written examination somewhat more
comprehensive that the present Technician exam, but with no requirement for
a Morse code examination.  Holders would be permitted to operate on all
frequencies and with all privileges available to Technicians above 30 MHz,
except that 2-meter operation would be limited to frequencies between 144.9
and 145.1 MHz and to digital modes only.  Examinations would be given only
by accredited Volunteer Examiners and distinctive call signs would be
assigned.

The mission of the committee was "to explore the implication of a no-code
amateur license." To carry out this mission, President Price appointed a
distinguished committee consisting of members from the ARRL Board of
Directors, Amateur Radio industry and radio amateurs at large, as follows:

     ARRL Vice President George S. Wilson III, W4OYI, Chairman
     John Crovelli, W2GD, At Large
     Y.E. (Ed) Juge, W5TOO, Industry Representative
     Kenneth G. Kopp, K0PP, At Large
     C. Mike Lamb, N7ML, Industry Representative
     Rod Stafford, KB6ZV, ARRL Director, Pacific Division

In addition, the following consultants were designated:

     Thomas B. J. Atkins, VE3CDM, CRRL President
     Larry E. Price, W4RA, ARRL President
     Leland Smith, W5KL, QCWA President
     David Sumner, K1ZZ, ARRL Executive Vice President

The committee carefully reviewed a wealth of input from interested
individuals and Amateur Radio clubs, as well as information it had
requested from International Amateur Radio Union (IARU) member societies in
other countries which have a code-free class of amateur license.  A large
number of alternatives were considered by the committee in developing its
recommendations.

ARRL Executive Vice President Sumner stressed that the committee's report
does not represent League policy at this time.  The Board of Directors is
the policy-making body of the organization and, as such, will determine
whether the report, with or without modifications, will become League
policy.  He pointed out that the League is a representative democracy, with
Directors elected to represent the members of their Divisions.
Accordingly, anyone reading the report and wishing to have his or her views
considered is urged to write the Director of their Division sometime prior
to the July Board Meeting.

          TEXNET VERSION 1.4 SOURCE CODE RELEASED

The Texas Packet Radio Society has released Version 1.4 of the TexNet
system source code.  This version will assemble without editing under
Microsoft's M80 Version 3.44.  The features incorporated into the source
code of this version include all of those announced for the EPROM image of
version 1.2.  They are calling CQ, multiple Packet Message Servers,
multiple Weather Information Servers, automatic user routing to network
default service nodes and an improved node statistics display.  The code
may be downloaded from CompuServe's HamNet (data library "DL9").

from Bill Wade, WD5HJP via CompuServe's HamNet

            NEW ROSE SWITCH AND SERVER RELEASED

The Radio Amateur Telecommunications Society (RATS) has released version
330 (for March 30) of Tom Moulton's (W2VY) ROSE X.25 Packet Switch and
Brian Riley's (KA2BQE) ROSErver/PRMBS software.

The switch software runs in a TNC 2 (or clone) or a PacComm DR-200.  It
supports back-to-back TNC configuration.  The new version of the software
has several minor bug fixes and has been in operation on eight switches in
New Jersey for several weeks without problem.  The server software runs on
any MS-DOS/PC-DOS compatible computer and provides many handy user and
SYSOP functions that are unique to PBBSs.

The software may be downloaded from CompuServe's HamNet (data library
"DL9") or from The RATS BBS at 201-387-8898.  Log on as "rats" ("rats" must
be entered in lowercase) and a menu will appear listing current files
followed by a prompt for your name, etc and then the file name.  The file
transfer is available using XMODEM only.

from J. Gordon Beattie, Jr, N2DSY via CompuServe's HamNet

            ATARI ST MAILBOX AVAILABLE

Thor Andersen, LA2DAA, has written a "W0RLI mailbox" program for the Atari
ST 520 and 1040 computers.  The software has been tested with an AEA PK-232
and PacComm TNC-200 and works fine with both TNCs.  To obtain a copy of the
software, send a 350-kbyte or 720-kbyte diskette containing public domain
programs to:

Thor Andersen, LA2DAA
Riddersporen 6
N-3032 Drammen
NORWAY

from Thor Andersen, LA2DAA @ LA1G

                  CLUB CLIPPINGS

Illinois

The Central Illinois Packet Radio Users Society (CIPRUS) is working
hard to provide an intrastate East-West North-South link.  This summer
full-duplex radios with 56-kbit/s modems will be installed in the 450-
MHz band.  Achieving these goals takes a lot of time and money and
anyone willing to help the cause are invited to join.  For further
information contact:

Larry Keeran, K9ORP, RR1, Box 99B, Downs, IL 61736-9717

Japan

Oimo Club was founded in 1988 by Shigeki Matsushima, JK1RJQ, and Dai
Yokota, JK1LOT, for the enjoyment of writing software for packet radio.
The club released "oimo," which is a mailer for the user of the KA9Q TCP/IP
software package.  They are now developing a news- distribution system for
the KA9Q TCP/IP environment.  For more information concerning the club
and/or its products, contact:

Oimo Club c/o PRUG
PO Box 66
Tamagawa, Setagaya
Tokyo 158 Japan

from Shigeki Matsushima, JK1RJQ

              TCP/IP USER NEWSLETTER

The New England TCPer is a bimonthly newsletter for hams who are using
TCP/IP for packet-radio communications.  Recent issues described using SLIP
to access PC-Pursuit, reviewed plug-in packet-radio adapters for the IBM PC
and its clones and presented a tutorial on using "BM Mailer." The
newsletter is edited by Rich Vitello, WA1EQU. More information from:

The New England TCPer 8 Denfeld Dr Westboro, MA 01581

Alex M. Mendelsohn, AI2Q 48 S Longbeach Av Freeport, NY 11520

Bryan Biggers, N9GBJ 4521 Sentinel Pass Madison, WI 53711


               G8BPQ TheNode PROGRESS REPORT

It is now a year since I started writing my PC-based AX.25 switching
software.  I'll summarize its main features.

The system was originally planned to be a high performance network node. At
the time, the only way of building multiband nodes was to interlink TNC 2
(or compatible) TNCs running NET/ROM software via a multidropped
asynchronous bus running at 9600 bit/s.  This was expensive in both
hardware and software and was limited in both AX.25 channel speed and
interport bandwidth.  Furthermore, the method of interlinking the TNCs (via
a diode matrix) made nodes with more than four ports very difficult to
implement.

Things have changed somewhat over the past year (the software costs have
been reduced, a variety of TNC 2 clones have been produced and improved
interlinking techniques developed), but there is still nothing capable of
running very fast links.  Also, with the rapid expansion of the network,
the need for each port of a multiport node to have its own call sign and,
hence, entry into the nodes list, has caused the list to get rather large.
My software allows a multiport node to run with a single call sign,
supports AX.25 links up to at least 64-kbit/s (given suitable
communications hardware) and eliminates the bottleneck of the asynchronous
link between ports.

The software also allows the user or, more usefully, a PBBS, direct access
to the network.  This was originally thought to be of less importance than
the improved node performance, but the introduction of the multiport PBBSs
and the rather slow introduction of radios and modems capable of high-speed
operation [not to mention the licensing problems on 23 cm, the band
generally regarded as ideal for high-speed operation), has meant that
initial installations have been made primarily to support multi-user PBBSs.
The software will support up to 16 copies of the chief multi-user PBBSs
that run in a multitasking environment (WA7MBL and W0RLI) or up to 16 users
on the G8UFQ system (although the PBBSs themselves may not support so many
copies).  This traffic may be trunked over a single radio link (preferably
at 9600 bit/s on a dedicated link) to the nearest network node.  All PBBS
ports have the same call sign, which also appears in the nodes list of
neighboring network nodes, allowing the user to connect directly from the
local node.

                  Current Status

The software has been running at some sites since September and a "beta
test" stage commenced in mid-December.  Approximately six copies are
currently running and are supporting WA7MBL, W0RLI and G8UFQ PBBSs.  The
software seems to behave reasonably well, but a few unexplained crashes
have occurred, so there is still some way to go before it is fit for
general release.  Also no one is currently running it as a major switching
node.

                Benefits to SYSOPs

The system offers two main benefits to PBBS operators and two to PBBS
users.  It allows a multiuser WA7MBL or W0RLI system to operate with just
one radio instead of a separate TNC and transceiver (and band) for each
port.  Setting up the forwarding system is greatly simplified, as the
networking software does away with the need to define each step in the FWD
file.  The forwarding system should also be more reliable and the network
will automatically reroute around a failed link.

The user benefits from being able to call the PBBS directly from his local
node, by the SYSOP being able to support more simultaneous users and by not
having to try several different routes and call signs to find a free port.
Future Plans

Once the current beta test phase is completed, I have a bit of work to do
to make the system more like the existing networking code (eg, sorting
nodes list into alphabetical order and implementing the CQ command).  I
have found a source for a communications card which will run up to at least
256-kbit/s, so I will produce a driver for that to be ready when very fast
microwave links become available.  I am also planning a version which can
run from PROM, so that a node can be built using a PC motherboard (now
available very cheaply) without disk drives.

Further in the future is investigation into protocols suitable for building
a high speed "trunk overlay" network.  The existing NET/ROM system works
pretty well at current link speeds and relatively limited total range, but
I do not think it is really up to coping with a nationwide network.  We may
end up with regional NET/ROM-like systems, interlinked by some other
system.  Any ideas would be welcome!

(As we were going to press, news was received of the untimely death of Mr
G.J. Chester, G8UFQ, whose PBBS software is mentioned in this article. -
Ed)

by John Wiseman, G8BPQ; from Connect International,
      transcribed by Hank Greeb, N8XX (TU HANK)


                STRAY BITS

Your editor will attend the Dayton HamVention and file a report concerning
the HamVention's packet-radio activities in the next issue of the
newsletter.  There is sure to be a plethora of new hardware and software,
both commercial and noncommercial, to report to you (I hope I will be able
to keep some of my money in my pocket rather than packet).

Tom Moulton, W2VY @ KD6TH, is trying to compile a list of all ROSE X.25
Switch SYSOPs that will be used by others to help expand the connectivity
of the ROSE network.  If you are running a ROSE-colored switch, send Tom
your call sign @ home PBBS, telephone number and any known gateways to
facilities such as KA-Nodes, PBBSs, NET/ROMs, HF gateways, etc.

A number of readers have asked about the source for the Japanese 9600-
bit/s modem mentioned in Gateway, Volume 5, Number 10.  The modem comes
from PRUG.  Their address is printed under "Club Clippings" elsewhere in
this issue.

Budd Turner, N7EOJ, has released the latest version of his packet- radio
network map of the western United States.  The map covers the 6th and 7th
call districts plus 0-district state Colorado and 5th- district state New
Mexico and includes digipeaters, PBBSs, gateways, and network nodes.  The
map and an accompanying node alias-call sign cross-reference table are
available by sending an SASE to Budd at 412 N Belvedere Av, Tucson, AZ
85711.

               GATEWAY CONTRIBUTIONS

Submissions for publication in Gateway are welcome.  You may submit
material via the US mail to:

     Gateway
     Stan Horzepa, WA1LOU
     75 Kreger Drive
     Wolcott, CT 06716-2702

or electronically, via CompuServe to user ID 70645,247.  Via telephone,
your editor can be reached on evenings and weekends at 203-879-1348 and he
can switch a modem on line to receive text at 300, 1200 or 2400 bit/s.

The deadline for each issue of Gateway is the Saturday preceding the
issue date (which is typically a Friday).

             REPRODUCTION OF GATEWAY MATERIAL

Material may be excerpted from Gateway without prior permission, provided
that the original contributor is credited and Gateway is identified as the
source.

--
Gary W. Sanders (gws@n8emr or ...!osu-cis!n8emr!gws), 72277,1325
N8EMR @ W8CQK (ip addr) 44.70.0.1 [Ohio AMPR address coordinator]
HAM/SWL/SCANNER BBS (1200/2400/PEP) 614-457-4227

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

End of PACKET-RADIO Digest
******************************
13-May-89 03:58:31-MDT,21077;000000000000
Mail-From: KPETERSEN created at 13-May-89 03:25:13
Return-Path: <[e-mail]>
Date: Sat, 13 May 89 03:25:11 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #132
To: [e-mail]

PACKET-RADIO Digest         Sat, 13 May 89       Volume 89 : Issue 132

Today's Topics:
            Help me (possibly others) !!!
           KA9Q Internet Software v890421.1
           TheNetRom & software innovation (2 msgs)
        What kind of PSK is used on FO-12? MicroSats?
----------------------------------------------------------------------

Date: 13 May 89 01:37:09 GMT
From: [e-mail]  (Patty Winter)
Subject: Help me (possibly others) !!!

In response to Athula's request for packet-radio definitions, I'm
reposting a glossary that Phil Karn posted last year. (Actually,
a combination of two postings he made.)

Enjoy!


Patty

*****************************************************************
From: [e-mail] (Phil R. Karn)

ARPA Suite - the set of protocols standardized by the Advanced Research
Projects Agency of the US Department of Defense. Includes TCP and IP as
elements, but leaves the lower levels (subnetwork and down) deliberately
unspecified; the ARPA suite can be run on top of multiple subnetworks,
unifying them into a single Internet.

ASLIP - Asynchronous Serial Line (usually just called SLIP). A technique
for encoding IP datagrams so they can be sent across ordinary asynchronous
modems and communications hardware.

AX.25 - an amateur packet radio link level protocol that borrows the
link layer from X.25 (also known as "LAPB"), modifies it, and tacks
a datagram-style address/routing header on front.

CLNS - Connectionless Network Service (see connectionless, datagram).

CMU/MIT PC/IP - one of the public domain packages that implement the ARPA
protocols on the IBM PC and its clones.

connectionless - refers to a packet protocol or service that does not
have the concept of a "connection". Packets may be sent at will, without
prior arrangement or need for connection setup/teardown procedures.

connection-oriented - refers to a protocol or service that requires that
a logical or virtual "connection" first be established with a special
procedure before data can be sent. Another procedure is used to "tear
down" the connection when it is no longer needed.

CONS - Connection Oriented Network Service (see connection-oriented,
virtual circuit).

COSI - Connection-oriented Open Systems Interconnect. A project of W2VY
and N2DSY to implement for amateur packet radio use the
connection-oriented protocols published by the International Standards
Organization (ISO) and the International Consultative Committee for
Telephony and Telegraphy (CCITT). (OSI protocols include both
connection-oriented and connectionless flavors, hence the inclusion of
the qualifier "connection-oriented" in the name). The COSI software is
presently under development.  [Note: This package has been renamed ROSE.]

datagram - Information packets in a connectionless environment.
Datagrams are completely self-contained as far as the network is
concerned. The information needed to get each datagram to its
destination (including, but not limited to, full source and destination
addresses) is carried in each datagram.

DDN Protocol Suite (Defense Data Network Protocol Suite). See ARPA
Protocol Suite.

duplex digi - like a simplex digi, except that different receive and transmit
frequencies are used. Allows simultaneous reception and transmission.

Gateway - a very general term for anything that connects two networks
together. In the ARPA world, "gateway" has a much more specific meaning:
a packet switch that handles IP datagrams.

IP - Internet Protocol. The core protocol of the ARPA suite.  IP is a
simple connectionless (datagram) protocol that handles addressing,
fragmentation and type-of service routing in the heterogeneous
internetwork environment.

IS - Intermediate System. ISO's term for a packet switch.

ISO - International Standards Organization. Publishes specifications for
everything from screw threads to computer communication protocols. Also,
International Snake Oi...oops, promised to keep things neutral. :-)

KA9Q Internet - name for a C software package developed by KA9Q with
programming contributions from N3EUA, K3MC, NG6Q, WA3CVG, PA0GRI, NN2Z, WB6ECE, AJ9X, K4FUM, N9DVG, K3EZ and probably some others I've
overlooked. Implements the major elements of the ARPA protocol suite:
IP, ICMP, TCP, UDP, Telnet, FTP, SMTP and ARP. Also implements
subnetwork drivers for SLIP, KISS, AX.25, Ethernet and Appletalk.
Primary environment is the IBM PC (and clones), but has been ported to
68K-based machines like the Commodore Amiga and Apple Macintosh, also to
UNIX System 5 environments. Sources, objects and documentation are
available for anonymous ftp from flash.bellcore.com under /pub/ka9q.

KISS - Keep it Simple Stupid. An extremely simple (some might say "hack job")
interface protocol between a computer and a TNC that gives the computer
complete control over and access to the frames sent and received by the
TNC.  Used by my Internet (TCP/IP) package as a way of bypassing the
unwanted AX.25 protocol and human user interface firmware in the TNCs.

NET/ROM - A proprietary product of Software 2000, Inc (WA8DED and W6IXU).
Consists of ROM firmware for the TNC-2. Implements AX.25 at the link layer,
with ad-hoc protocols at the network and transport layer. Also provides
a command interpreter and "transport level bridge" that patches incoming
or outgoing vanilla AX.25 connections to internal transport layer
connections.  Uses datagrams at the network layer, virtual circuits at the
transport layer.  Provides automatic routing between NET/ROM nodes, the user is still responsible for "source routing" between the end NET/ROM
nodes and the ultimate source and destination.

OSI - Open Systems Interconnect. A project of the ISO to develop a set of
computer communications protocols.

PAD - Packet Assembler/Disassembler. A device that interfaces an ordinary
"dumb" terminal to an X.25 packet network. It gathers typed characters
into outgoing packets and translates incoming packets back into serial
asynchronous data streams. Also provides a simple command interpreter for
setting up and tearing down connections, controlling parameters, etc.
The amateur packet radio TNC was heavily modeled on the PAD.

PTT - Postal, Telephone and Telegraph authority. The government-owned
phone monopoly found in almost every country except the USA.

RFC - Request for Comments.  Memoranda published in electronic form by
the ARPA Network Information Center. Documents everything from informal
proposals to established standards.

Router - Yet another term for a packet switch. Used by Xerox's XNS and
Digital's DECNET, two proprietary networking protocol suites very
similar to (but incompatible with) the ARPA suite (and with each other).

simplex digi - a regenerative digital repeater that receives a packet,
verifies that it was received correctly, and (if appropriate) retransmits
it on the same frequency it was received on.

TCP - Transmission Control Protocol. A major element of the ARPA Suite.
Provides reliable, connection-oriented byte stream service on an end-to-end
basis. Runs atop IP and sits at the transport and session layers.

TCP/IP - the most important two protocols from the DARPA Internet protocol
suite. Often used somewhat inaccurately to refer to the entire Internet
suite.  The rest of the ARPA suite includes protocols for file transfer,
remote login and mail transfer. The distinguishing feature of the Internet
suite of protocols is that they are specifically designed to run on top
of an ad-hoc collection of dissimilar subnetworks, forming a virtual
"super net" known as an Internet.  Amateur packet radio is only one of the
many subnetworks now supporting the Internet protocols.

TELNET - A presentation/application protocol in the ARPA Suite used for
terminal to terminal and terminal to host communications (e.g., remote
login).

TP4 - An element of the ISO OSI suite. A transport protocol that provides
reliable, connection-oriented byte stream service on an end-to-end
basis, analogous to TCP in the ARPA suite.

VC - virtual circuit. The service provided by a connection-oriented network
(qv).  Virtual circuit data packets generally carry less header information
than datagrams, since addresses have been specified at connection setup
time.

wideband packet - Anything faster than 1200 baud. Generally refers to operation at 56kbps with modems designed by WA4DSY.

W0RLI - Hank Orelson, W0RLI, author of a very widely used packet
bulletin board.

X.25 - A CCITT standard protocol for the subscriber interface to a public
packet switched network. Consists of two layers, link (level 2) and packet
(level 3).  The amateur AX.25 protocol is a highly modified version of just
the link layer of X.25; it does not have a packet layer.

X.25 - an international standard access protocol for public data
networks.  NOT currently used on amateur radio, despite our use
of the misnomer "AX.25".


Phil

=============================================================================
Patty Winter N6BIS                        INTERNET: [e-mail]
AMPR.ORG: [44.4.0.44]                     UUCP: {decwrl,nsc,sun}!apple!winter
=============================================================================

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

Date: 10 May 89 17:57:33 GMT
From: hpfcdc!hpldola!hp-lsd!col![e-mail]  (Bdale Garbee)
Subject: KA9Q Internet Software v890421.1

==============================================================================
=  Announcing a new release of the KA9Q Internet Package, revision 890421.1  =
==============================================================================

This release constitutes an attempt to merge the best efforts of everyone
how has been working on the KA9Q package since the last official release which
was dated 871225.0.  For those who've been tracking the beta releases, this
package was built from 871225.33alpha.W9NK.4.1, with many additions.  All
users are encouraged to upgrade to this release as soon as possible.

Developers should be aware that this package likely represents the last
official release of the KA9Q package until Phil finishes his internal rewrite
to include a multi-tasking kernel, now known as the "NOS" version of NET.  All
development effort for new applications should be directed towards NOS.

Revision 890421.0 was distributed in a limited fashion on PC floppies at the
Dayton Hamvention.  For PC users, there is no appreciable difference between
.0 and .1, other than the addition of modem dialing for slip, though the
documentation has been somewhat improved.

The things that have changed since the 871225.0 release are too many to
remember, much less mention, but here are a few highlights:

    - addition of official support for the Atari ST, NEC PC-98XX, HP
      Portable Plus, and various System V Unix systems in addition to the
      PC and its clones.

    - support for the FTP, Inc., packet driver specification on the PC

    - support for IP transport over NET/ROM networks, and some NET/ROM
      user level functionality

    - prompting for username and password in the FTP client

    - a Finger application, similar to Berkeley Finger

    - an AX.25 mailbox

    - addition of support for the W2XO PBBS when running under System V
      Unix, using SysV IPC between NET and XOBBS

    - A complete rewrite (still rough, unfortunately) of the documentation

    - conversion to the Borland Turbo-C 2.0 Professional Package for
      compiler/assembler/linker on the PC.  This was done in response to
      heavy demand from the user base, and sets the stage for exclusive
      use of TC 2.0 in NOS.  The package "almost compiles" under Aztec C
      4.10d, and can probably be made to work... I just don't have time.

    - addition of support for the MIT slfp serial line framing protocol

    - modem dialing for slip and slfp

Contributions to this release came from *many* folks around the world, again
too many for me to remember or mention.  Special thanks are in order though for
Bob Hoffman N3CVL who made this release possible by sorting through the muck
and providing me with sources to the W9NK.4 version with SysV Unix merged in,
and to Ron Henderson WA7TAS who made the Turbo-C 2.0 support work, added the
HP Portable Plus support, and hopped in to do some dirty piece of work every
time I was ready to give up in disgust...


HOW TO GET THE BITS:
====================

Via FTP on the Internet:

    The machine col.hp.com contains a copy of the distribution in the
    directory ~ftp/ka9q.  Access is quite reasonable from other sites
    on the HP Internet, but *very* slow for folks outside HP.  This
    site is recommended *only* for HP employees.

    The bits may be found on tomcat.gsfc.nasa.gov in a directory somewhere
    under anonymous ftp called net-8904.  This is a good place to grab
    the bits from right now.

    The bits will make it to wsmr-simtel20.army.mil shortly.  This
    is going to be the most stable Internet access point, I believe.

    The latest alpha/beta release bits are frequently available from the
    machine louie.udel.edu, in the directory ~ftp/pub/ka9q, but users
    are warned that the code on louie is *guaranteed* to be broken in
    one way or another, so unless you're working on porting to a new
    target system or similar, *stay away* from louie.

Via UUCP or Phone BBS Download:

    I no longer operate a telephone BBS system, nor do I support uucp
    from 'winfree' for grabbing the bits... my apologies for the confusion
    this has no doubt created.

    Howard Leadmon, WB3FFV, has the bits available on his BBS, which
    also supports UUCP.

        System Name: WB3FFV
        Login: bbs
        Number: (301)-335-0858 -- 1200 & 2400 (Non-MNP)
        Number: (301)-335-1955 -- 2400 (MNP), 9600 & 19200 (PEP)
        Data Settings: 8 Bits, NO Parity, 1 Stop Bit
        Times: 24hrs/365days  (except for routine maintenance)

    Other folks also have BBS systems, if there's some other machine that
    you frequent for packet radio related software, check there first, and
    look for some indication of the version number.

Via Mail:

    The Tucson Amateur Packet Radio association (TAPR), is distributing
    copies of this release on IBM-compatible 360k 5.25" floppies.  They
    also can provide KISS firmware for the TNC-1 and TNC-2, and clones.

    TAPR can be reached at:

        TAPR
        PO Box 12925
        Tucson, AZ  85732
        USA
        [phone]

    TAPR continues to be a leader in packet radio research and development,
    working with AMSAT on the microsat packet satellite project and a
    joint DSP project.  The 'Packet Status Register' newsletter is well
    worth the membership fee.  TAPR supports us, please support TAPR!


HOW TO REACH ME:
================

    In the past, I included my mailing address and telephone number in
    these release notes.  While the list of return addresses and folks
    who have contacted me is fantastic and astounding, I find that the
    amount of time required to deal with phone calls and paper mail has
    gotten a little out of hand.  Therefore, I must request that questions
    about this release be sent by electronic mail, which is easier to cope
    with on a time-available basis.  I *do* answer my mail when a working
    return address is provided!

        Internet:       [e-mail]
        UUCP:           winfree!bdale
        Compuserve:     76430,3323
        Packet:         N3EUA @ KA0WIE

73 - Bdale Garbee, N3EUA

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

Date: 12 May 89 15:41:43 GMT
From: jupiter![e-mail]  (Phil R. Karn)
Subject: TheNetRom & software innovation

>[discussion of size, cost and power considerations for TNCs vs PCs]

I don't know of too many TNCs that are useful by themselves to end
users; in most cases people plug them into dumb terminals or PCs
programmed to operate as dumb terminals.  With PCs (generically
speaking) now having pretty much displaced dumb terminals, though, it
seems to make much more sense to move the functions now done by TNCs
into the PCs, instead of wasting the PC's capability.  Several amateur
manufacturers, including HAPN, DRSI and PACCOMM, have followed this
trend by marketing packet adaptor boards for the IBM PC. They contain
HDLC interface chips plus the modem, so all you need in addition to the
PC and interface is a radio. Because you don't need a box or power
supply, it's a pretty economical approach too (especially if you want
more than one channel).

Using PCs for packet in this way has a lot of advantages, not the least
of which is the enormously easier task of developing experimental
software.  Having in years past played the game of perpetual EPROM
burning, I find it a heck of a lot more pleasant to edit, compile and
test my packet protocol software on a PC with a hard disk, faster CPU
and far more memory than a TNC.

The TNC has served its purpose well, but it was conceived with the
technology of the middle 1970s in mind. It's time to move on.

Phil

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

Date: 12 May 89 16:11:21 GMT
From: jupiter![e-mail]  (Phil R. Karn)
Subject: TheNetRom & software innovation

>       What exactly is the "NNC" (Network Node Controller??)?  I've run
>into references to the NNC here and there but have yet to find a description
>of the device.  Anyone have the gory details?

The NNC was a TAPR project several years to design a dedicated packet switch
board intended primarily for backbone use. It was supposed to complement
the TNC, which (despite NET/ROM) was intended for end-user use.

The problem with the NNC was that the CPU technology chosen (Hitachi
64180, essentially a Z-80 clone) was obsolete even before the first
prototype was built, and the price/performance ratio couldn't compete
with the cheap Taiwanese PC clones. A few prototypes were built, but
they didn't stimulate much interest among the software writers.

A newer and much better "nnc" is the PS-186 project by SANDPAC, the San
Diego packet group. The PS-186 uses the Intel 80186 CPU, and it has the
necessary hardware to support multiple high speed (1 megabit) links. The
PS-186 design has been licensed to AEA for manufacture, but it has been
slow to start again because of a present lack of software, and because
of a perceived lack of immediate need for a high performance networking
engine (running a PS-186 with 1200 baud links is killing flies with a
battleship). This situation is changing, however, as WA4DSY modems
become more widespread and N6GN makes progress with his microwave
megabit modems. Bdale (N3EUA) is working on porting my TCP/IP code to
the board.

Phil

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

Date: 11 May 89 13:53:12 GMT
From: mitel!sce!cognos!dgbt![e-mail]  (Barry Mclarnon)
Subject: What kind of PSK is used on FO-12? MicroSats?

From article <[e-mail]>, by [e-mail] (John Magliacane  Wall Township NJ):
>
>
> Could someone please tell me what kind of PSK modulation is used on FO-12
> mode JD. What about the "MicroSats"? I understand G3RUH has a PSK modem kit
> that works with FO-12 on mode JD, and "RadioKit" sells a PSK modem kit for
> satellite use.
>
> ...But what do these modems consist of?? Are they similar to BELL 212??
> Do they run BPSK? QPSK? What baud rates are involved??
>
> HELP! (Please!)
>
> 73, John  KD2BD
>
The FO-12 downlink is 1200 bps BPSK.  The same format will be used for the
Microsats.  The RadioKit modem is in fact the G3RUH kit.  However, there is
another kit available from AMSAT and TAPR which is demonstrably superior to
the G3RUH design.  It is based on a Japanese design, with some tweaking by
some of the TAPR folks.  It also includes the Manchester encoder needed for
the 1200 bps FO-12 & Microsat uplinks.  I homebrewed a modem from the
original JA design, and was very impressed with it.  In the early days of
mode JD, before they started up the mailbox software, I worked 9 different
countries using the satellite as a digipeater (which probably makes me the
"packet satellite DX King" - any challengers? ). :-)

The PSK modem bears some resemblance to a Bell 212, but the latter is a
600 Baud QPSK modem, so they certainly aren't compatible.

73, Barry  VE3JF

--
Barry McLarnon    Communications Research Center    Ottawa, ON   Canada
UUCP: ...utzoo!bnr-vpa!bnr-rsc!dgbt!barry   INTERNET:  [e-mail]
Compu$erve: 71470,3651     Packet radio:  VE3JF @ VE3JF

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

End of PACKET-RADIO Digest
******************************
14-May-89 01:59:59-MDT,3064;000000000000
Return-Path: <[e-mail]>
Date: Sun, 14 May 89 01:30:41 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #133
To: [e-mail]

PACKET-RADIO Digest         Sun, 14 May 89       Volume 89 : Issue 133

Today's Topics:
          220 MHz Hearing in Washington D.C.
----------------------------------------------------------------------

Date: 11 May 89 20:12:51 GMT
From: mailrus!sharkey!teemc!ka3ovk![e-mail]  (Jon Albers.)
Subject: 220 MHz Hearing in Washington D.C.

Well, I got back a few hours ago from the above.  From what I saw (from the
back row), the comission that was conducting the hearing was for the most
part much in favor of hams.  There were 4 'witnesses': The ARRL, the FCC,
UPS, and DOD.  Each was allowed time for testimony, and then each member of
the comission was givin time to ask questions at the end of each witnesses
testimony.
    I didn't take notes, but here are some of the high points:

The ARRL described activity on 220, and brought along a packet station.  One
of their main points was that only on 220 is the channels for wide-band
packet, and this is now done in the portion that the FCC took.  Also they
talked about expense and trouble of re-allocating present stations (FM, packet,
EME, etc....), and related this to a game of musical chairs, with the FCC
yanking the chairs away..  There was a lot more, and I expect to hear from
Chris Imlay later this week with more info...

The FCC was up next, and was quite comical.  One of the best laughs was when
they were asked if they had tried to find other alternatives to taking away
part of 220 -- "Well............".  Also they were forces to admit that they
based their idea of the usage of the 220 band on an old copy of the repeater
handbook -- stress old.  (The ARRL explained eariler that the direcory does
not list everything, and lists NOTHING about what's below the repeater
allocations).

UPS was very frank -- they didn't care what frequencys they got, as long
as they got them, and if the FCC assinged something else, it wouldn't cost
them much to change their plans.

DOD came out in support of the amateurs -- they said the FCC had been given
comments, but had choosen to ignore them...

Those were my impressions.  I think the comission is going to ask the FCC
to reconsider, but no decisions were officially given today..

Keep your fingers crossed.....


                        Jon Albers
                        KA3OVK
                    Packet: KA3OVK@N4QQ

--
| Jon Albers, IRS, Computer Services, Site Support and Installation(CS:M:S:P) |
| UUCP:      (drilex|infopro|teemc|tcsc3b2|ki4pv|wb3ffv)!ka3ovk!(root|albers) |
| ARPA: JALBERS@SIMTEL20    Have Trailblazer, will connect................... |
|     ka3ovk: Compaq 386/25 Model 300 SCO XENIX-386 Sys V ver 2.3.1           |

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

End of PACKET-RADIO Digest
******************************
15-May-89 02:28:38-MDT,8534;000000000000
Return-Path: <[e-mail]>
Date: Mon, 15 May 89 01:30:23 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #134
To: [e-mail]

PACKET-RADIO Digest         Mon, 15 May 89       Volume 89 : Issue 134

Today's Topics:
       FCC's recognition of repeater coordinators is a disaster
               IDs for packet Repeater
          Spectrum Planning vs coordinators
----------------------------------------------------------------------

Date: 14 May 89 13:40:25 GMT
From: texbell!nuchat!splut![e-mail] (Jay "you ignorant splut!" Maynard)
Subject: FCC's recognition of repeater coordinators is a disaster

[e-mail] (Phil Karn) writes:
>>You're in the tiny minority. I do have to consider the larger ham
>>community, and they've told us that they do perceive it that way.
>The minority of what? If you only canvass the existing repeater owners
>(which dominiate every frequency coordinating body I've ever seen -- which
>is why they're usually called "repeater councils") of COURSE you will find
>that most want to preserve the status quo.

The minority of the larger ham community - at least those that have
chosen to express an opinion to us. As I've said countless times before,
we don't care if a member is a repeater trustee. You have obviously
never been to one of our meetings. (Yes, I understand that there's a bit
of a distance problem...:-)

>>Wanna use that space for repeaters? [145.5-145.8] Go talk to the FCC, not me.
>What gave you this idea? We already have plenty of space, perhaps too much
>space, on 2m that is occupied by repeaters. There needs to be room for other
>modes, e.g., FM simplex, SSB and weak signal work, packet, satellite and so
>on. The reason we still have repeater subbands on 2m even in this era of
>deregulation is recognition by the FCC that without subbands, FM repeaters
>would immediately swallow up the entire band.

Waitaminute. First you argue that packet duplex repeaters need space,
and that the FM repeaters are soaking it all up. Now you say that we
don't need repeaters, or more repeater frequencies. Huh?
What, exactly DO you want?
Do you want most of the FM repeaters to go away? Or do you want more
space for packet applications? If 145.5-145.8 isn't going to step on the
satellite users, why not use it?

>This is news to me. A check of my references shows that EVERY unmanned
>amateur satellite -- with one exception -- from Oscar-6 to the present that
>uses 2m does (or did) so in the 145.8-146.0 segment. (The one exception is
>Oscar-13, whose mode J uplink listens between 144.425 and 144.475 MHz.) Even
>the Russian RS satellites follow this convention.  The *only* space
>operation I know of on 145.55 MHz has been the US and Soviet 'ham-in-space'
>flights. Being more like DX-peditions than anything else, these are
>obviously in a special category.

This objection was raised, to the best of my recollection, in QST
several years ago. All of my QSTs older than a year got trashed :-(, so
I can't quote an exact issue. The general perception, though, is that
anyone operating between 145.5 and 146 is going to step on satellite
users, and that's a big no-no. If that's not true, then maybe you, as a
prominent member of the satellite community, should do something about
it.

>>I've said before that 220 is a special case: the FCC's grab makes it
>>obvious to repeater trustees that they will have to move. The band's
>>also not so full that there's no place for them to move to.
>Halllujah! Now we're getting somewhere. Can you please tell this to the
>local TSARC people?

As I've also said before, I speak only about Texas. I have no knowledge
of what the TSARC types are doing, or even who they are. My statement
above (>>s) is true in Texas, and represents the way things are here. I
also have never said otherwise in the case of 220.

--
Jay Maynard, EMT-P, K5ZC, PP-ASEL   | Never ascribe to malice that which can
uucp:        uunet!nuchat!   (eieio)| adequately be explained by stupidity.
    hoptoad!academ!uhnix1!splut!jay +----------------------------------------
{killer,bellcore}!texbell!          | "Less great!" "Tastes filling!"

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

Date: 12 May 89 19:38:38 GMT
From: ginosko!infinet!ulowell!tegra![e-mail]  (Johnathan Vail)
Subject: IDs for packet Repeater

How do packet repeaters id?  CW or by packet?

Right now the one (and only?) repeater in the area is a voice machine
and still uses CW to id.  When they switch to a higher baud rate and
become a real digital repeater they aren't sure what they will do.
I am looking at a perhaps working on a digital repeater and am
interested in this question now.

What do other repeaters do?

"You know, I'd rather see this on TV... tones it down" -- Laurie Anderson
 _____
|     | Johnathan Vail | tegra![e-mail]
|Tegra| [phone] | N1DXG@145.110-,145.270-,444.2+,448.625-
 -----

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

Date: 14 May 89 13:55:33 GMT
From: texbell!nuchat!splut![e-mail] (Jay "you ignorant splut!" Maynard)
Subject: Spectrum Planning vs coordinators

In article <[e-mail]> [e-mail] writes:
>There is a clear distinction between the functions of a repeater coordinating
>group, and a spectrum planning group.

This is correct. Repeater coordination is only one aspect of spectrum
planning; it's merely the most visible one. The reason that almost all
spectrum planning groups are also repeater coordinators is because the
repeater coordinators were the only groups for a long, long time that
recognized the need for spectrum planning.

>However, when a group such as Illinois Repeater
>Association is starting to do spectrum planning, and still only allows the
>owners of repeaters to have voting membership, then I something is seriously
>wrong.

This statement is correct, too, as far as it goes.
Don't throw out all the babies with the bathwater. Not all repeater
coordination/spectrum planning groups limit their memberships to
repeater trustees.

>That will still leave open the problems of repeaters being spectrum hogs by
>not making an effort to tighten up their spacings, use PL and anti-PL, and
>not consider every case of overlap as interference.

You've seen the discussion I've had here with AA5AV, who considers the
interference that his group gets from a repeater 67 miles away to be
unacceptable. He's told me in E-mail that a number of his users feel the
same way.

PL is a red herring in terms of spectrum management. You can't change
the laws of physics with a PL board. A signal strong enough to cause
interference will do so whether or not PL is installed; if it interferes
with an intended signal with PL, that signal will either be heard along
with interference, or it will go away entirely. That's not much of an
improvement.

>It still does not solve
>the problem of the repeater owners ganging together for little more than to
>protect their turf.

If you'd invested $2K and a man-year in your repeater, you'd want to
protect it too.

>I believe the FCC's decision to not recognize official
>coordinators is correct.  Anyone CAN be a coordinator.  I am still thinking
>about it.

There was a big war a couple of years ago in Southern California with
two repeater coordinators claiming to serve the same area. It led to
strife, on-the-air fights, and lawsuits. Do you really want this? The
Kowalski letter, stating that it was possible for two coordinators to be
in the same area, was an unmitigated disaster. He even said as much,
later. Your starting another coordination body will 1) be ignored by
trustees already coordinated, if you tell them to shut down or move, or
coordinate someone on top of them, and 2) do no good for ham radio at
large. Please don't. We've had to learn that lesson already. There's no
point in repeating it.

--
Jay Maynard, EMT-P, K5ZC, PP-ASEL   | Never ascribe to malice that which can
uucp:        uunet!nuchat!   (eieio)| adequately be explained by stupidity.
    hoptoad!academ!uhnix1!splut!jay +----------------------------------------
{killer,bellcore}!texbell!          | "Less great!" "Tastes filling!"

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

End of PACKET-RADIO Digest
******************************
16-May-89 02:16:15-MDT,8249;000000000000
Return-Path: <[e-mail]>
Date: Tue, 16 May 89 01:30:57 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #135
To: [e-mail]

PACKET-RADIO Digest         Tue, 16 May 89       Volume 89 : Issue 135

Today's Topics:
               IDs for packet Repeater
           Indiana Packet Traffic Newsletter 05/89
                 Packet ID's
----------------------------------------------------------------------

Date: 15 May 89 03:38:43 GMT
From: texbell!bigtex!helps!bongo![e-mail]  (julian macassey)
Subject: IDs for packet Repeater

In article <[e-mail]>, [e-mail] (Johnathan Vail) writes:
>
> How do packet repeaters id?  CW or by packet?
>
> Right now the one (and only?) repeater in the area is a voice machine
> and still uses CW to id.  When they switch to a higher baud rate and
> become a real digital repeater they aren't sure what they will do.
> I am looking at a perhaps working on a digital repeater and am
> interested in this question now.
>
> What do other repeaters do?
>
    Here in Greater Disneyland (Los Angeles), we have a packet repeater on
146.745 -600. It is known as N6GPP/R

    Every 10 minutes or so a TNC on the frequency ids as:

N6GPP/R Glendale

    There is no CW ID.

    The packet repeater is a real packet repeater, it will not pass voice.
This trick is accomplished by having a 202 modem in the audio path between
the RX output and the TX input.

    Yes, as KA9Q has stated this machine has good throughput, much better
than a digipeater and it covers from Santa Barbara to San Diego.

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

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

Date: 16 May 89 01:33:03 GMT
From: silver![e-mail]  (Keith E. Brandt)
Subject: Indiana Packet Traffic Newsletter 05/89

=============================================================================
May, 1989               Indiana Packet NTS Newsletter          Vol. 3 Issue 5
=============================================================================
       A monthly forum for ideas about packet traffic handling
             Jay Farlow, WB9MDS, Editor

AMTOR-PACKET LINKING PROGRAM TO ADD NTS FEATURES
    By Bob Foster, WB7QWG @ WB7QWG

    APlink is a bulletin board program which acts as a gateway between AMTOR
and packet radio (see IPNN 11/89).  Vic Poor, W5SMM wrote the program.  An HF
traffic handler has requested Vic install special handling for NTS traffic.
So Vic has developed a scheme to handle that request.  He has only received
input from that one individual, and is seeking other opinions.
    The following information comes from an excerpt of planned APlink
documentation.
    The purpose of APlink's NTS features would be to make selected APlink
installations a clearing point for NTS traffic being passed between active
NTS stations.  When activated, these facilities would restrict access for
certain NTS traffic to designated NTS stations and provide for automatic
confirmation of access and forwarding back to originating stations.  The
APlink SYSOP would be expected to coordinate with NTS Trans-Continental Corps
(TCC) directors, to learn what stations should be allowed NTS privileges.
    The proposed software would have specific requirements of operators who
enter NTS traffic.  If they expect the designated NTS stations to handle the
traffic it would have to be addressed to the call sign of the APlink station,
or the "@ BBS" field would have to be left blank.  For example, where WA8DRZ
is the APIINK station, any of the following commands would "capture" a
message for the NTS user:

ST WA8DRZ
ST NTS
ST WA8DRZ AT WA8DRZ
ST NTS AT WA8DRZ
ST WA8DRZ AT 94062
ST NTSTX AT WA8DRZ

    In other words, any "ST" message reaching WA8DRZ with WA8DRZ in either
the "TO" field or the "@ BBS" field or with a blank "@ BBS" field is
considered an NTS message with restricted access and to be cleared by a
participating NTS station.
    Continuing with this example, messages arriving at WA8DRZ, that are
addressed such as the following would be autoforwarded by the APLINK station
and would not be treated as restricted NTS messages:

ST 78240 AT NTSTX
ST WB7QWG AT WB7QWG
ST WA5QZI AT 78229

    ANY station would be allowed to ENTER an NTS message.  Restrictions would
only apply to message ACCESS.
    Messages intended to restricted NTS access would have to use the
following form (lower case is the APLINK system response):

ST WA8DRZ
nr 5678 nts ga msg + ?
NTS WISCONSIN

NR 45 R HXG W7ABC 8 TACOMA WASH 1254Z 23 MAY

ROSEY MAY JONES
321 GARDEN ST
GREEN BAY WISCONSIN
404-555-4321

HAPPY BIRTHDAY X SEE YOU SOON X LOVE
TONY

NNNN
nr 5678 filed ga + ?

    Note that the "title" or "subject" line is the NTS routing.  The first
non-blank line following is the standard NTS header.
    When a station with NTS privileges enters the command, "NTS," APlink
would send a list of all NTS messages that have not been accepted by an NTS
station.  If the station then reads any of the messages, APlink would send
the following prompt:

ACCEPT (YES / NO / CANCEL) + ?

    The system would not proceed until one of the three responses is given.
A response of YES means that the NTS station accepts responsibility for
further delivery and APLINK will mark it as forwarded and delete it from the
NTS message list.  A response of NO leaves the status of the message
unchanged and a response of CANCEL provides the option of removing a message
from the system that is unsuitable for amateur handling.  In all three cases
APlink would generate a confirmation message as discussed below.
    The confirmation message would be addressed to the station originating
the message into the APLINK system (not the station whose call appears in the
NTS header line).
    The confirmation will take the following form:

CNF

UR MSG NR 5678 ACCEPTED BY W2DEF 890523/1534Z
NR 45 R HXG W7ABC 8 TACOMA WASH 1245Z 23 MAY

NNNN

    The word "ACCEPTED" will alternately be "READ" or "CANCELED" depending on
the accessing station's response to the above prompt.
    APLINK would hold messages in the system for at least 24 hours after they
have been marked as forwarded.  Sometime after 24 hours has passed from
forwarding, APLINK would remove the messages from the system and archive
them.  Only the SYSOP could retrieve a message from the archive.  A message
that remains unforwarded in the system for 21 days would be removed and
archived.
    Please send comments on these proposed features to WB7QWG @ WB7QWG.  If
you wish, also send a copy to WB9MDS @ KB8NH, for possible inclusion in a
future issue of IPNN.

APRIL PBBS TRAFFIC REPORTS

    KD9QB Noblesville, IN
      10 NTS Messages       (  0.7% of messages entered)
    KA9LQM Evansville, IN
      22 NTS Messages       (  1.6% of messages entered)
    W9ZRX Westfield, Indiana
      420 NTS Messages

EDITOR INVITES COMMENTS, DUPLICATION

    WB9MDS sends this newsletter to every PBBS in Indiana, and to HamNet on
the CompuServe Information Service (C.I.S.).  Feel free to duplicate all or
any part...as long as you credit the source.  Send comments and questions to
WB9MDS @ KB8NH, or 72737,157 on C.I.S.

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

Date: Mon, 15 May 89 14:09:48 BST
From: [e-mail]
Subject: Packet ID's


In the UK, it is a condition of the Amateur licence that ALL stations use
a CW ID at most every 30 minutes. Most tnc's tend to send the MyCall callsign
out at about 15-25 wpm, so you can imagine what it sounds like with fifty
or so packet stations on the air together. (More CW than packet!)

John.   G1YYH

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

End of PACKET-RADIO Digest
******************************
17-May-89 02:31:48-MDT,9075;000000000000
Return-Path: <[e-mail]>
Date: Wed, 17 May 89 01:30:40 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #136
To: [e-mail]

PACKET-RADIO Digest         Wed, 17 May 89       Volume 89 : Issue 136

Today's Topics:
FCC's recognition of repeater coordinators (is really no longer the subject)
        KA9Q-Package for ATARI ST, Location ?
            KA9Q files at SIMTEL20
           TheNetRom & software innovation
             wanted: TEXNET info
----------------------------------------------------------------------

Date: Wed, 17 May 89 01:02:52 EDT
From: [e-mail]
Subject: FCC's recognition of repeater coordinators (is really no longer the subject)

shlump.dec.com![e-mail] (Fred k1io) writes:

>>1. If you going to end up making some people irate anyway, is there a way
>>to affect LESS people and cause LESS of a financial setback? If you end up
>           ^ you mean FEWER, not LESS.  Sorry.  Couldn't help myself!

LESS FILLING... TASTES GREAT.  (Had too many that night)

>The problem isn't more Simplex frequencies for packet, it's having ANY
>REPEATER frequencies for packet.  The only thing odd-ball splits will
>buy you is to let you squeeze into the usually-simplex areas (200 kHz)
>in the middle of each repeater MHz.  The FCC won't let you put a
>repeater on 145.71 or 144.49.
>Sure, you can squeeze a crossband operation into the area around 147.5
>and again on 450 someplace.  But it's not a generalized answer.

Hmmm, this was my original question but I still think you might not
understand what it was. If I take a TRUE FULL DUPLEX PACKET REPEATER
can I have it's input frequency on ...say 145.03 and it's output on
147.555 ??? This would give over 2 mHz of separation and would reduce
the cost of the duplexer due to FEWER cavities and LESS isolation required.
(Fewer... less...??? I think I got it right this time! :-)
The main question here is legality. If you can run simplex packet on
145.03 and also on 147.555... why not the same frequencies for digital
repeater use? Would the FCC put the kabosh on this?


>>2. Most radios today DO support non standard splits.

>Well, neither my FT221 nor TH21AT support odd-ball splits; both use
>discrete crystals for offsets.  They're both old, of course; brandy-new
>radios can do oddball splits, but they've gotten costly.

My KDK-2015 does and that predates both that you mentioned.... I see your
point though, I just don't think that it's a big thing. If you wanted to
use either of the radios that you mentioned for dedicated packet use, it
would cost you about $10 or less for a new crystal. But then it wouldn't
be too handy anymore for amateur voice repeater use.... but then....

>>Lastly and as an adjunct, have you read about the proposed idea of using
>>DAMA (Demand Assigned Multiple Access) instead of CSMA on packet radio?

>Lots of problems there.  Polling time is too long with T/R switching
>delays; else it's too inelastic of varied demand, it's messy to get
>a node attached, etc.  Nice hack concept but I don't think it'll ever
>work for ham radio.  Just an opinion of course.  CSMA is easier to make
>work.  Cheap, too, except of course that the FM boys have a stranglehold
>on the bands in many areas.

No argument... I am not qualified to comment pro or con... but if you
have some time I'd be interested if you could go into a little more
depth on the points that you brought up. I see what you are saying
when comparing it to a full dux system, but with the hidden transmitter
collision problem on a simplex "digi" system it seems to offer advantages
that offset some of the detriments that you mention.   Yes.. No ???



Mark Bitterlich
[e-mail]
wa3jpy@wb4uou

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

Date: Fri, 12 May 89 11:44:35 +0200 (Central European Summer Time)
From: [e-mail]
Subject: KA9Q-Package for ATARI ST, Location ?

<Subject: How to access the WB3FFV BBS...
<
<   Hello All,
<
< I sent out a message the other day telling people how to get the latest
<bits (KA9Q release 890421.0) from my BBS, and mentioned that anyone


    Is there a kind soul, who loads the KA9Q-Soft for ATARI-ST up
    to the SIMTEL archives ?

    thanx ---- a poor BITNET-User

Regards
Mit freundlichen Gruessen
               Stephan Leicht  - DC8ZM -

    Name : Stephan Leicht (Postmaster)
Organisation : Computer Center of Technical University Darmstadt, Germany
Organisation : Hochschulrechenzentrum der Technischen Hochsschule Darmstadt
     Telefon : [phone] ( 8.00 - 12.00 )
      Bitnet : XBR1Y055@DDATHD21

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

Date: Tue, 16 May 1989  17:49 MDT
From: Keith Petersen <[e-mail]>
Subject: KA9Q files at SIMTEL20

SIMTEL20 now has all of the recently announced KA9Q updates.

Here is the directory listing as it now stands:

   PD3:<MISC.KA9Q-TCPIP>
          Bytes(SZ)  Write

 BM_SRC.ARC.1     39420(8)   10-May-89
 DRIVERS.ARC.3    122916(8)  22-Mar-89
 EPRINT.ARC.1     21535(8)    2-Aug-88
 FINGER.ARC.1     31242(8)   30-Apr-88
 KIT.ARC.1        33565(8)   15-Feb-88
 NELSON.ARC.2     7413(8)     6-Dec-87
 NET33_ST.ARC.1   156159(8)   7-Jan-89
 NET_AMIG.ARC.2   108322(8)  21-Mar-88
 NET_BM.ARC.10    43208(8)   17-Jun-88
 NET_DES.ARC.6    29476(8)    3-Jan-89
 NET_HP.ARC.1     240480(8)  15-May-89
 NET_MAC.ARC.1    116992(8)   1-Jan-88
 NET_PC.ARC.10    171989(8)  10-May-89
 NET_SRC.ARC.14   511664(8)  10-May-89
 NET_ST.ARC.1     124213(8)  15-May-89
 NOS.ARC.1        374186(8)   3-Jan-89
 NRNET.ARC.4      212444(8)  10-Dec-88
 PXX111.ARC.1     37094(8)   30-Apr-88
 README.TXT.1     8972(7)    10-May-89
 SCREEN.ARC.1     39030(8)   11-May-89
 SERVER16.ARC.1   40448(8)    4-Aug-88
 STARTUP.NET.1    457(7)     28-Mar-89
 TNC1.HEX.1       19725(7)   30-Apr-88
 TNC_ASH.ARC.4    57076(8)    1-Jan-88
 TNC_LDR.ARC.4    15790(8)    1-Jan-88
 TNC_TNC1.ARC.5   34710(8)   15-May-89
 TNC_TNC2.ARC.4   49542(8)    1-Jan-88
 USERMAN.ARC.1    148547(8)  10-May-89
 XOBBS.ARC.1      51076(8)   10-May-89

73,

--Keith Petersen
Maintainer of SIMTEL20's CP/M, MSDOS, and MISC archives
Internet: [e-mail] [26.2.0.74]
Uucp: {ames,decwrl,harvard,rutgers,ucbvax,uunet}!wsmr-simtel20.army.mil!w8sdz

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

Date: 16 May 89 22:24:27 GMT
From: texbell!splut![e-mail]  (Jay Maynard)
Subject: TheNetRom & software innovation

In article <[e-mail]> [e-mail] (Phil R. Karn) writes:
>>[discussion of size, cost and power considerations for TNCs vs PCs]
>[...] it seems to make much more sense to move the functions now done by TNCs
>into the PCs, instead of wasting the PC's capability.

Assuming, of course, that the PC is sitting there doing nothing but
playing dumb terminal, this makes sense. However, what if the subject
computer _is_ doing something else, like the increasing population of
286- and 386-based Unix boxes? There, it makes sense to offload the
bit-stuffing to another dedicated processor.

>Using PCs for packet in this way has a lot of advantages, not the least
>of which is the enormously easier task of developing experimental
>software.

I can't argue with this one, but it's a comparatively tiny proportion of
those on packet.

>The TNC has served its purpose well, but it was conceived with the
>technology of the middle 1970s in mind. It's time to move on.

Only where it makes sense. My AT is too busy running Unix to do packet
assembly itself.

(Maybe it's too busy *crashing* Unix...^%&$%^$#^%$# Microport... :-)

--
Jay Maynard, EMT-P, K5ZC, PP-ASEL   | Never ascribe to malice that which can
uucp:        uunet!nuchat!   (eieio)| adequately be explained by stupidity.
    hoptoad!academ!uhnix1!splut!jay +----------------------------------------
{killer,bellcore}!texbell!          | "Less great!" "Tastes filling!"

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

Date: 15 May 89 16:37:05 GMT
From: convex!iex!ntvax![e-mail]  (Greg Jones)
Subject: wanted: TEXNET info

[e-mail] (Fred Goldstein k1io) writes:
>for protocols?  In particular, how does it do wide-area stuff?  Is
>it like X.25 PLP (CONS, like ROSE), or is it like NET/ROM, like
>IP, or homegrown?
>

Well yes and no - the easiest way is to point you at the 6th ARRL
Network Confernce proceedings. The TexNet paper by Tom McDermott N5EG
father of TexNet here in Texas.

I have to run to a meeting - so I will try to post here in the next
few days some points from the paper.

73 - greg

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

End of PACKET-RADIO Digest
******************************
18-May-89 02:33:21-MDT,5917;000000000000
Return-Path: <[e-mail]>
Date: Thu, 18 May 89 01:30:28 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #137
To: [e-mail]

PACKET-RADIO Digest         Thu, 18 May 89       Volume 89 : Issue 137

Today's Topics:
                  Mail List
                  Questions
           TheNetRom & software innovation
----------------------------------------------------------------------

Date: 17 May 89 12:03:24 GMT
From: bpa![e-mail]  (Bob Esposito)
Subject: Mail List

    Please remove me from the "tcp-group" mailing list.  Thank you.



--
Bob Esposito           uucp: [e-mail], {rutgers|bellcore}!bpa!espo
Bell of Pennsylvania   inet: [e-mail]
Philadelphia, PA.      phone: [phone]  packet: N3CTA @ N3CTA 44.80.0.93
===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===

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

Date: 17 May 1989 23:10-CDT
From: "410 BMW/SCX--KI Sawyer AFB MI" <[e-mail]>
Subject: Questions

I have two questions about packet.

First...I have seen several ads for commercial TNCs.  MFJ,
Pro-Comm and  others offer them.  What is the difference between
them and the amateur TNCs?

Second...Can I hook more than one TNC to a radio?  I am looking at a
mainframe system with several remote terminals and need to connect as many as
eight terminals via radio.  I have two options.  I can either have several
TNCs off a T-Mux or each TNC on a modem to a Multi-drop input to the mainframe
but do I need a seperate radio for each TNC, or can I hook them
all  to one radio?
Any comments suggestions experiences, etc would be helpful.

Please E-mail as I don't always get to read  the board all the time
at least right away.

Thanks for any help.

73,
Michael

*******************************************************************************
Michael Barnes                       *   The nice thing about policies
InterNet: [e-mail]    *   and standards, is that there
HamNet: WA7SKG                       *   are so many to choose from.
BellNet: 906-346-2578                *   If you don't find any you
DS Net: 472-2578                     *   like, simply wait for next
Snail Net: 2001CS/XP                 *   years models!
       K.I. SAWYER AFB, MI       *
*******************************************************************************
DISCLAIMER: The ideas, comments, remarks, replies, insinuations,
innuendos, flatuations, and any other conceivable or inconceivable
outputs presented here, real, imagined, or implied, simply do not
exist.  The names are real, the stories have been changed due to
simple boredom.
*******************************************************************************

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

Date: 18 May 89 00:26:32 GMT
From: jupiter![e-mail]  (Phil R. Karn)
Subject: TheNetRom & software innovation

>>[...] it seems to make much more sense to move the functions now done by TNCs
>>into the PCs, instead of wasting the PC's capability.
>
>Assuming, of course, that the PC is sitting there doing nothing but
>playing dumb terminal, this makes sense. However, what if the subject
>computer _is_ doing something else, like the increasing population of
>286- and 386-based Unix boxes? There, it makes sense to offload the
>bit-stuffing to another dedicated processor.

It is worth pointing out that a typical PC consumes much more processing
time just handling the data from a TNC as it comes in on a serial port
than the TNC spends on protocol processing. Even a complete protocol
stack like TCP/IP/AX.25 takes comparatively few cycles. So it makes very
little sense to offload the protocol processing when it represents such
a small fraction of the job.

But I fully agree that the low-level processing of packets (below the
link layer protocol) should be done by dedicated hardware, as long as it
is done in a way that truly improves performance. The unit of
communication between the host computer and the interface should be the
complete packet, as in most Ethernet interfaces. A lot of PCs and larger
computers can easily run UNIX and handle true networking protocols like
TCP/IP at the same time, despite the fact that they communicate at
speeds far higher than the toy 1200 baud rates now used in most of
amateur packet radio

The main problem with the present generation of packet radio adaptors
like the DRSI PCPA, PACCOMM PC-100 and HAPN card is that the host
computer is still forced to handle each byte individually as it comes
in. What's really needed is a "smart card" like K3MC's design that can
operate on complete frames. But even without his card, I still think
you're better off moving the protocol software into the host computer.

>>Using PCs for packet in this way has a lot of advantages, not the least
>>of which is the enormously easier task of developing experimental
>>software.
>
>I can't argue with this one, but it's a comparatively tiny proportion of
>those on packet.

Perhaps it would be a larger proportion if it was made easier. I would
guess that there are already more people experimenting with their own
protocol software on PCs than there are working directly on the TNC-2,
and the availability of plug-in cards plus the KISS TNC mode is directly
responsible for this.

>>The TNC has served its purpose well, but it was conceived with the
>>technology of the middle 1970s in mind. It's time to move on.
>
>Only where it makes sense. My AT is too busy running Unix to do packet
>assembly itself.

Not at all.

Phil

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

End of PACKET-RADIO Digest
******************************
19-May-89 09:48:12-MDT,17563;000000000000
Mail-From: KPETERSEN created at 19-May-89 09:36:19
Return-Path: <[e-mail]>
Date: Fri, 19 May 89 09:36:17 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #138
To: [e-mail]

PACKET-RADIO Digest         Fri, 19 May 89       Volume 89 : Issue 138

Today's Topics:
         FCC's recognition of repeater coord
FCC's recognition of repeater coordinators (is really no longer the subject)
              Questions (2 msgs)
           TheNetRom & software innovation (2 msgs)
              TNCs and Terminals
              Various questions
    Xenix, Merit, KA9Q, 80286, getting them all to work together?
----------------------------------------------------------------------

Date: 18 May 89 18:40:00 GMT
From: ux1.cso.uiuc.edu![e-mail]
Subject: FCC's recognition of repeater coord

> Hmmm, this was my original question but I still think you might not
> understand what it was. If I take a TRUE FULL DUPLEX PACKET REPEATER
> can I have it's input frequency on ...say 145.03 and it's output on
> 147.555 ??? This would give over 2 mHz of separation and would reduce
> the cost of the duplexer due to FEWER cavities and LESS isolation required.
> (Fewer... less...??? I think I got it right this time! :-)
> The main question here is legality. If you can run simplex packet on
> 145.03 and also on 147.555... why not the same frequencies for digital
> repeater use? Would the FCC put the kabosh on this?

Since the frequencies in 2 meters that repeaters are allowed on are
    144.5 - 145.5 Mhz  and
    146.0 - 148.0 Mhz
that should be legal to do.

Why not suggest a plan for such a scheme.  Maybe the simpler scheme of
    144.91 -> 147.41    145.01 -> 147.51
    144.93 -> 147.43    145.03 -> 147.53
    144.95 -> 147.45    145.05 -> 147.55
    144.97 -> 147.47    145.07 -> 147.57
    144.99 -> 147.49    145.09 -> 147.59
at least then the offset will be consistent and the frequencies will be easy
to remember.  I don't know if hams will go for that, though.

Have you considered cross-band repeats?  That would REALLY simplify the
duplexer, like in almost none.
    223.40 -> 445.50
    223.42 -> 445.525
    223.44 -> 445.55
    223.46 -> 445.575
    223.48 -> 445.60

--phil ka9wgn--

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

Date: 17 May 89 18:45:00 GMT
From: apollo!ulowell!tegra![e-mail]  (Johnathan Vail)
Subject: FCC's recognition of repeater coordinators (is really no longer the subject)

In article <[e-mail]> [e-mail] writes:

   shlump.dec.com![e-mail] (Fred k1io) writes:

   >The problem isn't more Simplex frequencies for packet, it's having ANY
   >REPEATER frequencies for packet.  The only thing odd-ball splits will
   >buy you is to let you squeeze into the usually-simplex areas (200 kHz)
   >in the middle of each repeater MHz.  The FCC won't let you put a
   >repeater on 145.71 or 144.49.
   >Sure, you can squeeze a crossband operation into the area around 147.5
   >and again on 450 someplace.  But it's not a generalized answer.

   Hmmm, this was my original question but I still think you might not
   understand what it was. If I take a TRUE FULL DUPLEX PACKET REPEATER
   can I have it's input frequency on ...say 145.03 and it's output on
   147.555 ??? This would give over 2 mHz of separation and would reduce
   the cost of the duplexer due to FEWER cavities and LESS isolation required.
   (Fewer... less...??? I think I got it right this time! :-)
   The main question here is legality. If you can run simplex packet on
   145.03 and also on 147.555... why not the same frequencies for digital
   repeater use? Would the FCC put the kabosh on this?

Technically you can do this.  You are still running a repeater on
simplex frequencies which is not the right thing to do.  I am trying
to remember now if that is actually illegal or just against band plan.

My belief is that the repeaters on 2m and 440 for packet use are a
short term benefit.  Eventually when enough people (computers) are
filling up the digital repeaters then higher frequencies will be more
attractive.  This will help fill up 900 MHZ and 1.2G and above.
Remember that this is primarily a point-to-point use with fixed
antennas.  Connectivity is through digital switches to other networks.


"Frisbeetarianism is the belief that when you die, your soul goes up on
the roof and gets stuck." -- button
 _____
|     | Johnathan Vail | tegra![e-mail]
|Tegra| [phone] | N1DXG@145.110-,145.270-,444.2+,448.625-
 -----

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

Date: 19 May 1989 04:07-PDT
From: [e-mail]
Subject: Questions

In reply to Ron's response (ron<at>hardees.rutgers.edu), I didn't intend to
post this, but I apparently can't e-mail directly to Ron:

Thanks for your input, however what I don't believe you realized by my
request was the terminals are in various locations, mostly mobile.
That would preclude muxing the terminals into one TNC.  I know you
could have numerous connects on one TNC, as in a rounstable type
discussion, but would that work in this application?  I guess
it would be like having a multi-user BBS, but the users would not
see each other.

Thanks again and 73,
Michael

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

Date: 18 May 89 17:12:57 GMT
From: elbereth.rutgers.edu!ron.rutgers.edu![e-mail]  (Ron Natalie)
Subject: Questions

Many of the commercial TNC's are identical, to the PC board layout to
the TAPR TNC-2.  The major advantage is that you can by them off the
shelf and don't have to put them together or do much alignment in the
general case.  Some of the TNC's have other advantages, either
enhanced sofware, smaller packaging, or addition of an HF modem for HF
Packet, AMTOR, and RTTY.  Of course, some of the commercial products
cut corners and leave out very important parts of the TNC-2 design
such as the watchdog timer.

If you are really develloping a multiuser appliation you probably
don't want to use multiple TNC's on the same radio.  You probably
don't want to use multiple TNC's on multiple radios if they end up in
close proximity to each other (besides the additional expense).  What
you ought to look into is multiplexing the terminals onto the single
TNC on the host, using either HOST or KISS mode in the TNC depending
on how complex you want to get.  This is how the multiuser bbs's
accompish the task, it also gives you better control than scanning for
*** CONNECTED in your input stream.

-Ron


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

Date: 19 May 89 05:45:31 GMT
From: nuchat!splut![e-mail]  (Jay "you ignorant splut!" Maynard)
Subject: TheNetRom & software innovation

In article <[e-mail]> [e-mail] (Phil R. Karn) writes:
>It is worth pointing out that a typical PC consumes much more processing
>time just handling the data from a TNC as it comes in on a serial port
>than the TNC spends on protocol processing. Even a complete protocol
>stack like TCP/IP/AX.25 takes comparatively few cycles. So it makes very
>little sense to offload the protocol processing when it represents such
>a small fraction of the job.

How come my AT running Unix slows down whenever I fire up the TCP/IP
package? If I get any activity on the channel, the response time for
other tasks goes through the roof. Microport's serial handler is
notoriously buggy, but it's not all that slow; I don't get such a
noticeable slowdown when running uucp to another machine. Your statement
about serial processing versus protocol processing is comparing apples
and oranges. I'd much rather have my processor spend time on the compile
it's working on than on doing protocol-izing; having a 6809 out there do
it and hand me the results is much better. Anything I can offload, I
will.

>But I fully agree that the low-level processing of packets (below the
>link layer protocol) should be done by dedicated hardware, as long as it
>is done in a way that truly improves performance. The unit of
>communication between the host computer and the interface should be the
>complete packet, as in most Ethernet interfaces.

...and, strangely enough, like a KISS-based TNC. I'd love to have a TNC
on a board, but I'll run an external TNC before I'll run a
byte-at-a-time packet adapter.

>What's really needed is a "smart card" like K3MC's design that can
>operate on complete frames. But even without his card, I still think
>you're better off moving the protocol software into the host computer.

I'll agree with the first part; that's a TNC on a board. Without the TNC
doing the bit-stuffing, though, the host computer is wasting time on
nonproductive low-level work instead of what it's supposed to be doing.
I don't have a machine I can dedicate to packet; that's part of why I'm
running Unix.

>Perhaps it would be a larger proportion if it was made easier. I would
>guess that there are already more people experimenting with their own
>protocol software on PCs than there are working directly on the TNC-2,
>and the availability of plug-in cards plus the KISS TNC mode is directly
>responsible for this.

You've been hanging around the techies too long. (Well, maybe not too
long in general, but it appears to have distorted your outlook... :-)
Out here in the real world, where people use packet to communicate, they
don't give a fuzzy rat's posterior about software experimentation; they
just want to send packets back and forth. I would tend to believe that
the ratio of software experimenters to users is more like 1:10 or 15.

>>My AT is too busy running Unix to do packet assembly itself.
>Not at all.

Have you run a load study on my system? I'll say it again: My AT is too
busy. It slows down noticeably when asked to run the NET package. That
seems to me to be empirical evidence. I see no way that forcing it to do
even more work can make it less busy.

--
Jay Maynard, EMT-P, K5ZC, PP-ASEL   | Never ascribe to malice that which can
uucp:        uunet!nuchat!   (eieio)| adequately be explained by stupidity.
    hoptoad!academ!uhnix1!splut!jay +----------------------------------------
{killer,bellcore}!texbell!          | "Less great!" "Tastes filling!"

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

Date: 18 May 89 18:28:00 GMT
From: ux1.cso.uiuc.edu![e-mail]
Subject: TheNetRom & software innovation

The same argument I would use in support of a TNC-like box (but running more
advanced protocols) is the argument used to justify the existance of boxes
like ethernet repeaters and terminal servers.  Sure, a PC can do what they
do.  But a box built just for that purpose can do the job even better in
terms of total cost.  Just as Net/ROM is a protocol improvement, I want to
do similar things.  I just want a box with a decent processor, a decent
amount of memory, and a decent ROM space.  I'll use my PC to develop the
software and burn it into ROMS.  Today, they use processors like the 8085.
As the world moves up to 68040 and 80860 technology, TNC-like devices can
move on up to 68000, 80286, and T800 technology for sophisticated, yet
still physically small, automated operations.

The existance of TNC's means their existance was justified.  All I ask for
is that they be "open systems".  In the ham radio field, this should be more
the case.

--phil ka9wgn--

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

Date: 19 May 1989 04:26-PDT
From: "410 BMW/SCX--KI Sawyer AFB MI" <[e-mail]>
Subject: TNCs and Terminals

We all know that a TNC has all the brains needed to run packet, so
when will someone come out with a decent and cheap portable terminal
to use with packet.  I mean something we can use, not a 20 dollar
VIC-20 or similar where you have to use a TV set, external disk to
load the terminal program etc.  For crying loud, you can buy a spell
checker thing that has 64k or so of memory and everything, a nice lcd
display rechargeable batteries and fits into a ladies purse for under
50 bucks.  Surely a similar device with a simple terminal program in
ROM and an RS-232 port should be available for 100-150 bucks.  Add a
battery printer like is in a calculator for another 50 bucks or so and
the portable packet folks would jump on it.

TAPR are you listening?  Henry radio is on the right track with their new
mobile TNC/printer combo even if it is a bit pricey.

If we are going to be forced into multi-kilobuck laptops, how about
internal TNCs that would go where the internal telephone modem goes?
I think something similar to the DRSI TNC would be nice in a laptop
version, but is the DRSI a complete standalone TNC? Never have
figured out that one yet.


BTW folks, can we get back to real issues on packet/ham radio like
product reviews, operating practices, hardware, new stuff, etc.
These endless 1000 word essays (I think the latest is on repeater
coordination) are getting ridiculus.  Please, the few particpants
in these just email to each other so the majority of us can read
the boards with minimal time.


Thanks for listening.

73,
Michael

*******************************************************************************
Michael Barnes                       *   The nice thing about policies
InterNet: [e-mail]    *   and standards, is that there
HamNet: WA7SKG                       *   are so many to choose from.
BellNet: 906-346-2578                *   If you don't find any you
DS Net: 472-2578                     *   like, simply wait for next
Snail Net: 2001CS/XP                 *   years models!
       K.I. SAWYER AFB, MI       *
*******************************************************************************
[LONG SIGNATURES ARE A BORE. FOUR LINES MAXIMUM, PLEASE!!!]
*******************************************************************************

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

Date: 18 May 89 12:12:00 MST
From: "USERVX::EICHERT" <[e-mail]>
Subject: Various questions

    I've got a couple of questions:

    I was in the /atari area on tomcat.gsfc.nasa.gov and there was a file
something like "drivers.scc" which explained about an interface and driver
s/w for the ST that used a Zilog 5350?.  There was mention of a schematic
also plus the driver s/w.  However all there was in the /atari area about
it was that particular teaser info-file.

    Does anyone have anymore info about it than that.  I would really appreciate
the full scoop on this.

    Okay on to another question:

    How does one invoke the Western Digital packet driver using the attach
command for the latest version of net.  I don't quite understand quite
the idea of the "packet-interupt number".  Hate to sound ignorant but
I am on this subject.  I've been using the beta WD version off louie and
I would really like to continue using the WD card with the latest version
of net.

                thanks,
                    diana eichert


[e-mail]

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

Date: 18 May 89 17:38:21 GMT
From: mailrus!sharkey!wyn386![e-mail]  (Daniel Wynalda)
Subject: Xenix, Merit, KA9Q, 80286, getting them all to work together?

I recently downloaded a copy of KA9Q's Net utility.  It is a version of
TCP/IP designed to work with ham radio and apparently is being used in
other places on the network.

I am running SCO Xenix 386 2.2.3, as well as SCO Xenix 286 2.2.1.

I would like to see if I can get this utility up and running in some
way on one of my machines.  (Preferably the 286).  I hacked the
makefile using a Xenix diff file from "conexch" in southern California
(A good Xenix public access system).

All of the routines compile using the makefile designed for Unix with the
appropriate patches, however I get an error with a few unresolved externals
in the final link.  These include procedures from slfp.c, pc.c, and maybe
a few other modules in the package.  It appears that the makefile doesn't
include these at all as they use non-unix structures etc?  I am not really
sure.

At this point has anyone used this package with (1. Xenix, 2. Merit/Telenet,
3. an 80286 machine)?

If anyone could give me any help, it would be appreciated.  -- Here is a
little background on why I'd like to get it working.

1.  My ham ticket is probably in the mail this very minute (Passed the tech
liscense in early April).
2.  I currently get my newsfeed from sharkey (University of Michigan) via
the merit network (X.25 protocol packet switched network that supports TELNET)


I noticed that in the slfp.c file, the Merit network is mentioned specifically.
Since I use it regularly, I'd like to find a better/more reliable way to
get information if I could.

Any help is appreciated.

            Daniel Wynalda

--
Daniel Wynalda          | Telephone: [phone] X22
Wynalda Litho Inc.      | Network: [e-mail] ..sharkey!wyn386!danielw
8221 Graphic Ind Pk.    | I do not own the company, nor speak for this company
Rockford, MI  49341     | in this text.  Please do not take it as such.

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

End of PACKET-RADIO Digest
******************************
22-May-89 18:12:51-MDT,12594;000000000000
Mail-From: KPETERSEN created at 22-May-89 17:46:16
Return-Path: <[e-mail]>
Date: Mon, 22 May 89 17:46:15 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #139
To: [e-mail]

PACKET-RADIO Digest         Mon, 22 May 89       Volume 89 : Issue 139

Today's Topics:
              Gateway 12-May-89 P 1 of 4
----------------------------------------------------------------------

Date: 22 May 89 00:33:09 GMT
From: n8emr![e-mail]  (Gary Sanders)
Subject: Gateway 12-May-89 P 1 of 4

==============================================================
|               Relayed from packet radio via                |
| N8EMR's Ham BBS, 614-457-4227 (1200/2400/19.2 telebit,8N1) |
==============================================================

Gateway: The ARRL Packet Radio Newsletter - Stan Horzepa, WA1LOU, Editor

Volume 5, Number 17      -      May 12, 1989       -         Part 1 of 4

            TAPR UNVEILS packetRADIO AT DAYTON

The Tucson Amateur Packet Radio (TAPR) booth at the Dayton HamVention was
buzzing with the unveiling of a number of new packet-radio products
including prototypes of the TAPR "packetRADIO," a low-cost (approximately
$250) two-stage VHF transceiver designed exclusively for packet-radio
applications.  TAPR's packetRADIO features 9600-baud FSK and 1200-baud AFSK
2-meter operation with 25 watts output, five crystal-controlled channels
and a transmit-receive turnaround time of less than one millisecond (ms).

The working prototypes displayed at the HamVention were the result of a
six-week crash project by TAPR.  Beta-testing will begin soon with the
radios expected to be available to the general public in approximately six
months.  [TAPR is looking for beta testers. If you are interested, send an
SASE to TAPR (PO Box 12925, Tucson, AZ 85732) for a beta-test
questionnaire.] For more information concerning the packetRADIO, see the
accompanying story entitled "packetRADIO - The Missing Link."

In addition to the unveiling of the packetRADIO, the "TNC 1 to TNC 2
upgrade" kit was sold at the TAPR booth for the first time.  The kit
consists of a printed-circuit board that is piggybacked on a TNC 1, which
results in a TNC with all of the capabilities of a TNC 2 and a TNC 1.  See
Gateway, Volume 5, Number 10, for the complete description of the upgrade
kit.

Also available at the TAPR booth were the "DCD mod" kits that are intended
to improve the operation of Data Carrier Detect (DCD) in a TNC.  (DCD is
used to determine whether a channel is clear in order that a TNC may send
packets without interference.  If DCD is on, the TNC remains in the receive
mode.  If DCD is off, the TNC may transmit after all its timing
requirements are met.) Most TNCs base DCD on the presence of "some sort of
signal or noise." When the TAPR DCD modification is installed in a TNC, DCD
is based on the presence of "coherent information." As a result, a channel
may be used more efficiently because the TNC is not falsely prevented from
transmitting by a signal or noise that is not a legitimate packet-radio
signal.

The DCD mod kits are available in two flavors.  The "2211 DCD upgrade" kit
is intended for TNCs using the XR2211 modem receiver IC such as the TAPR
TNC 1 and TNC 2 and their clones.  The "state machine DCD upgrade" kit is
intended for TNCs using other types of modems such as the Kantronics and
AEA PK-series TNCs.

Besides new hardware, new software was also available at the TAPR booth as
new versions of the KA9Q TCP/IP code for IBM PC and compatible computers
(Version 890421.0) and Apple Macintosh computers (Version 871225.33a4) were
distributed at the TAPR booth during the HamVention.  For more information
concerning the Macintosh release, see the accompanying story entitled "New
Version of Macintosh KA9Q TCP/IP Code Released."



              packetRADIO - THE MISSING LINK

Something has been missing from packet radio... a radio designed
specifically for the average amateur.

Why 9600 bit/s?

Most VHF amateur packet-radio operations use 1200-baud modems with radios
designed for voice use.  With few frequencies available for packet-radio
use, today's channels are becoming extremely crowded.  Packet radio is
almost unusable in some metropolitan areas during evening hours.

Sending data faster allows more users to operate on a given channel.  And
9600-baud packets can be easily encoded using FSK techniques and fit within
a normal 2-meter FM channel.  But, a faster modem running with a voice
radio is a compromise at best.

Why a Special Radio for Packet Radio?

The typical VHF packet-radio station uses an FM transceiver designed for
voice use.  There are four major drawbacks to using such radios.

1) Timing.  Voice radios have receive-to-transmit and transmit-to-receive
   turnaround times of about 150 to 400 ms.  This dramatically reduces the
   amount of data that can be sent and increases the chance that two or
   more stations will interfere with one another.

   At 9600 bauds, a radio that switches in 1 ms can transfer files about
   20% faster than one which switches in 200 ms.  Similarly, a channel can
   accommodate four times as many users if the radios switch in 1 ms
   instead of 200 ms.  At data rates faster than 9600 bauds, the
   differences are even more dramatic.

2) Interfacing.  The modem-to-radio interface depends on audio response,
   filters and audio levels intended for microphones and speakers.  More
   often than not, this leads to incorrect deviation of the transmitted
   signal, noise and hum on the audio, and so forth.  Splatter filters and
   deviation limiters distort frequency response and further reduce the
   performance of the packet-radio system.  Higher-speed operation (such as
   9600 bit/s) involves surgery on the radio--there is no proper interface.

   The TAPR packetRADIO has built-in 1200-baud and 9600-baud modems.  It
   plugs directly into a standard TAPR TNC modem disconnect.  Its filters
   are optimized for data operation, not voice.

3) Complexity.  The typical VHF radio manufactured today is competing in
   the voice market and includes many additional features which are simply
   not necessary in a data radio.  These include telephone tone pads,
   scanners, digital readouts, squelch, voice synthesizers and
   miniaturization.  In fact, these additional features often detract from
   the performance of the radio in data applications.

4) Price.  The usual VHF FM transceiver sells for $400 or more in today's
   market.  A dedicated digital transceiver can be made to significantly
   outperform existing voice-grade radios for data use and at a
   substantially lower price.  It makes good economic sense to free up a
   multifeatured radio for voice operation and use a simple, inexpensive
   data radio for digital applications.

TAPR's packetRADIO has the following features that are designed for
experimentation.

o  Design is easily adaptable for higher frequencies.

o  Each major subsection of the radio is on a separate printed circuit
   board for optimum performance.  This results in the ability to upgrade
   to other frequency bands.

o  The modems are modular.  Higher-speed operation to 56 kbauds and beyond
   is possible.

o  The basic RF deck may be used for modem experimentation.

o  May be used with a transverter for higher frequencies and higher baud
   rates.
              . . . Continued next page

===========================================================================
NOTE: PART 3 was missing from packet distribution.......
===========================================================================




        NEW VERSION OF MACINTOSH KA9Q TCP/IP CODE RELEASED

The new version of the KA9Q TCP/IP code for Apple Macintosh computers
(Version 871225.33a4) was released at the Dayton HamVention.  This
release features the following changes.

o  Separate windows for the Console, Trace and Log functions.

o  Fully MultiFinder friendly.

o  MacBinary file transfers within FTP.

o  Support for NET/ROM.

o  Support for AppleTalk.

o  Addition of finger command.

o  Command key mapped as the Control key for non-ADB keyboards.

o  Extensive help files built into MacNet and MacBM.

o  Mailbox facility for AX.25 commands.

o  MHeard facility for AX.25 commands.

o  Alias file support in MacNet and MacBM.

o  Full path name support including foreign volumes.

For more information contact:

    Douglas Thom, N6OYU
    1405 Graywood Dr
    San Jose, CA 95129-4778

   from Douglas Thom, N6OYU

                   DAYTON NOTES

In the last ten years, I have attended the Dayton HamVention seven times
and my 1989 attendance was the best one yet.  The HamVention opened with a
bang Friday morning as a spectacular thunderstorm engulfed the HamVention
area.  It was the first time I have witnessed such a storm while sitting in
a car and the lightning strokes were the most spectacular I have ever seen
especially the jagged horizontal strike that looked like an oscilloscope
display.  Despite the storm, some HamVentioners were working their way
through the flea market checking out the goodies of the few booths that
dared to open during the storm.  There were other storms during the
weekend, but none interfered with my attendance at the convention.  My only
worry was whether my rental car would get stuck in the mud quagmire that
also served as a parking lot.

It was a pleasure meeting some folks for the first time after dealing with
them over the air, landline or mail and it was nice to reaquaint myself
with folks I have eyeballed in the past.  Sorry if I missed anyone.

The most fascinating new stuff at the HamVention for me were TAPR's
packetRADIO and ICOM's IC-3SAT (I, like many others would have bought one
of each on the spot if they were for sale).  The packetRADIO you can read
about elsewhere in this issue, the ICOM IC-3SAT you can read about here.
It is a miniature 220-MHz handheld (1.9 X 4.0 X 1.4 inches) that is not
much bigger than a pack of cigarettes and includes memory storage for 49
operating channels and 15 telephone numbers, 5 watts output when run on an
external supply, a scanner and a clock that can be programmed to turn the
transceiver on and/or off.  It is supposed to be available in June.

Since I could not buy a packetRADIO or IC-3SAT, what did I buy?  Besides
the odds and ends that I obtained (tie wraps, books, battery packs, etc.),
my major purchases were a Kenwood TM-621A and a TNC 1 to TNC 2 upgrade kit.
The 621 will free up the 220-MHz radio I use in my car which I plan to hook
up inside for 220-MHz packet-radio operations.

I enjoyed the packet-radio forum, however, next time I will bring a tape
recorder along to record the festivities instead of trying to take notes
that, less than a week later, are somewhat inscrutable.  I also enjoyed the
various hospitality rooms in Stouffers.  Although, it seemed that every
floor of the hotel had a hospitality room on both Friday and Saturday
nights, I never got off the fifth floor where my room was located.

It was a fun weekend!  I hope for more of the same in 1990!

               GATEWAY CONTRIBUTIONS

Submissions for publication in Gateway are welcome.  You may submit
material via the US mail to:

   Gateway
   Stan Horzepa, WA1LOU
   75 Kreger Drive
   Wolcott, CT 06716-2702

or electronically, via CompuServe to user ID 70645,247.  Via telephone,
your editor can be reached on evenings and weekends at 203- 879-1348 and he
can switch a modem on line to receive text at 300, 1200 or 2400 bit/s.

The deadline for each issue of Gateway is the Saturday preceding the issue
date (which is typically a Friday).

             REPRODUCTION OF GATEWAY MATERIAL

Material may be excerpted from Gateway without prior permission, provided
that the original contributor is credited and Gateway is identified as the
source.


--
Gary W. Sanders (gws@n8emr or ...!osu-cis!n8emr!gws), 72277,1325
N8EMR @ W8CQK (ip addr) 44.70.0.1 [Ohio AMPR address coordinator]
HAM/SWL/SCANNER BBS (1200/2400/PEP) 614-457-4227

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

End of PACKET-RADIO Digest
******************************
23-May-89 02:31:22-MDT,9177;000000000000
Return-Path: <[e-mail]>
Date: Tue, 23 May 89 01:30:43 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #140
To: [e-mail]

PACKET-RADIO Digest         Tue, 23 May 89       Volume 89 : Issue 140

Today's Topics:
FCC's recognition of repeater coordinators (is really no longer the subject)
              Gateway 12-May-89 P 1 of 4
               NEW Bits on WB3FFV BBS..
          New Ham, looking for HT, interesting call
           Pittsburgh, PA area packet BBS's
           TheNetRom & software innovation
----------------------------------------------------------------------

Date: 23 May 89 02:51:18 GMT
From: shlump.dec.com!delni.dec.com![e-mail]
Subject: FCC's recognition of repeater coordinators (is really no longer the subject)

In article <[e-mail]>, [e-mail] writes...
>
..was my original question but I still think you might not
>understand what it was. If I take a TRUE FULL DUPLEX PACKET REPEATER
>can I have it's input frequency on ...say 145.03 and it's output on
>147.555 ??? This would give over 2 mHz of separation and would reduce
>the cost of the duplexer due to FEWER cavities and LESS isolation required.
>(Fewer... less...??? I think I got it right this time! :-)
>The main question here is legality. If you can run simplex packet on
>145.03 and also on 147.555... why not the same frequencies for digital
>repeater use? Would the FCC put the kabosh on this?

Those two frequencies are within the reepeater subbands, so they
don't violate FCC regs.  145.55 is not.  The middle of each of the
three 2m repeater subbands is traditionally simplex because of
the 600 kHz split.  So an odd-ball repeater just runs into the
possibility of simplex interference.
   fred
d

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

Date: 22 May 89 21:45:30 GMT
From: tektronix!orca!ka7axd.WV.TEK.COM![e-mail]  (Michael T. Horne)
Subject: Gateway 12-May-89 P 1 of 4

> Most TNCs base DCD on the presence of "some sort of signal or noise." When
> the TAPR DCD modification is installed in a TNC, DCD is based on the presence
> of "coherent information."

Could someone please describe the changes to the circuit?  How did
they improve the detection process?  Are they using some sort of
scheme that uses an amplitude/duration threshold to determine data
from noise?

Detecting `coherent information' implies knowing something about the
incoming data stream.  It seems to me that the output from a detector
being fed with noise is very dependent upon the input noise level and
the detection threshold.  Given the wide range of input noise levels
possible, it seems difficult to distinguish input noise and a real
signal, short of using heuristics (e.g. NRZI guarantees input
transitions through bit-stuffing).

The only other thing I can think of off-hand is that we know something
about the spectrum of a Bell 202 signal, and we know something about
the spectrum of noise (or should I say, a band-limited noise source).
Using this information, we should be able to detect the difference
between noise and a known signal by comparing the spectrums (hence
detection).  Are they doing some sort of `noise detection' and using
this as a threshold for detecting (gating) a real signal?

Mike

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

Date: 10 May 89 21:10:07 GMT
From: peregrine!ccicpg!felix!tgate!irsx01!wb3ffv![e-mail]  ( WB3FFV)
Subject: NEW Bits on WB3FFV BBS..

   Hello All,

 As of this message I have just placed the NEW release of the KA9Q TCP/IP
software (the new POST Dayton release) on my BBS. This is release 890421.1,
and it replaces the 890421.0 release that was made avalible at Dayton. From
what I hear from Bdale, this release contains some enhanced features, and
improved documentation. Anyone that is interested in the software is
welcome to download it from my BBS, or use anonymous UUCP...

-------------------------------------------------------------------------------
Internet  : [e-mail]     |       Howard D. Leadmon
UUCP      : wb3ffv!howardl              |       Fast Computer Service, Inc.
TELEX     : 152252474                   |       P. O. Box 171
Telephone : [phone]              |       Chase, MD  21027-0171

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

Date: 22 May 89 13:19:01 GMT
From: mailrus!sharkey!wyn386![e-mail]  (Daniel Wynalda)
Subject: New Ham, looking for HT, interesting call

I am a new user to Ham Radio.  I received my license Saturday in the mail and
have yet to make my first contact via the airwaves.  Since I don't own any
equipment at this point, I'd like to purchase some.  I am a Technician class
at this time as I am really getting into Ham for the Packet radio aspect
of the hobby (yes, I'll upgrade soon).

First, I have seen many 2m HT's on the market.  Also several dual banders.
Would someone please recommend what they have and let me know if buying
a dual bander HT (2m/440) is worth the little bit extra money?  I'd like
something that I can put mod's on if possible.   Our company runs it's
trucks at 463.712Mhz, and I can legally transmit and recieve there because
of this fact (not on my ham licence).  Anyway, if I could get a 2m/440
HT that would expand up to the 460+ Mhz range it would be very desirable.
Also if it could recieve about 148Mhz in the 2m band, it would be nice
(all local police are there and it could double as a scanner).

Second, I see a few ALL MODE packet radio devices on the market.  Could
someone please recommend their packet system to me?  I want to run KA9Q's
package on a 286 or 386 box running under SCO Xenix.  I have seen AEA's
PK-232, and the Kantronics All Mode in magazines, however have seen no one
with personal experience on the boxes.  Obviously I'd like something
that can run KISS because I want to run KA9Q (unless I am missing something).

Third, here is my new callsign!  I feel like I got really lucky on this one.
ID = N8KUD (naked!).  As I figure it, there could only be 4 nakeds in the
world.  Those with KED, KUD, CED, CUD.  And it's EASY to remember for people
that way!

Thanks to anyone who wants to help out a new ham.  I have been into usenet
for several years, and I'd like to try to promote the local packet people
into the world of TCP/IP!  I haven't got any experience with it at this
point, I've just been running Usenet via UUCP.  If you could describe
similarities and differences between receiving UUCP news and TCP news
(or maybe operating procedures for KA9Q?) I would be most indebted.

            Thanks for any help you can be in advance.
            Daniel Wynalda

--
Daniel Wynalda          | Telephone: [phone] X22
Wynalda Litho Inc.      | Network: [e-mail] ..sharkey!wyn386!danielw
8221 Graphic Ind Pk.    | I do not own the company, nor speak for this company
Rockford, MI  49341     | in this text.  Please do not take it as such.

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

Date: 19 May 89 20:25:41 GMT
From: encore!cloud9!jjmhome![e-mail]  (Dave Pascoe KM3T)
Subject: Pittsburgh, PA area packet BBS's

I need the callsigns of major packet BBS's in the Pittsburgh, PA area.  I know
that W2XO used to be the major BBS there but rumor has it that 'XO has been
running a new multi-tasking system that has bugs.

Please reply via e-mail.
--
              Internet: [e-mail]
Dave Pascoe KM3T/1    UUCP: ..!harvard!ulowell!cloud9!jjmhome!km3t
              Packet: KM3T @ K1UGM

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

Date: 20 May 89 13:20:12 GMT
From: w3vh![e-mail]  (Rolfe Tessem)
Subject: TheNetRom & software innovation

In article <[e-mail]> [e-mail] (Jay "you ignorant splut!" Maynard) writes:
>
>How come my AT running Unix slows down whenever I fire up the TCP/IP
>package? If I get any activity on the channel, the response time for
>other tasks goes through the roof. Microport's serial handler is
>notoriously buggy, but it's not all that slow; I don't get such a
>noticeable slowdown when running uucp to another machine.

If this is happening when just running on a 1200 baud radio channel, I'd
say you have something else wrong.  I'm running Phil's code under System
V/AT, and am only using the stock built-in serial ports.  I run a
Trailblazer off one port, and have a TNC hung on the other.  Even during
UUCP activity at 9600 baud, activity on the radio port doesn't have an
effect on serial throughput.  If I try a SLIP link at 9600 baud at the
same time as 9600 baud UUCP activity, there is some degradation -- but
even then it isn't severe.


--
UUCP:         uunet!w3vh!rolfe                  | Rolfe Tessem
INTERNET:     [e-mail]                 | P.O. Box 793
AMPRNET:      [e-mail] [44.44.0.2]| Great Barrington, MA 01230
PACKET RADIO: w3vh@wa2pvv                       | [phone]

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

End of PACKET-RADIO Digest
******************************
23-May-89 15:58:32-MDT,18811;000000000000
Mail-From: KPETERSEN created at 23-May-89 15:44:18
Return-Path: <[e-mail]>
Date: Tue, 23 May 89 15:44:17 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #141
To: [e-mail]

PACKET-RADIO Digest         Tue, 23 May 89       Volume 89 : Issue 141

Today's Topics:
            DUAL-BAND HT FEEDBACK
         FCC's recognition of repeater coord
          New Ham, looking for HT, interesting call
----------------------------------------------------------------------

Date: Tue, 23 May 89 13:04:03 CDT
From: [e-mail] (Martin Mullican)
Subject: DUAL-BAND HT FEEDBACK

(forwarding comment)
--------------------------

Howard Leadman, N8KUD and the readers of "PACKET-RADIO"

RE: 2-M, 70-CM HT Selection

Howard, I too went through the same process you are with respect to
looking into HTs, especially the new dual-banders.

Attached is the same question I asked the "INFO-HAMS" net and a few
of the responses I received.

Good Luck!

73,

Marty, KB5JDQ


 --------------------------
 (original message follows)


 RE: DUAL-BAND HT FEEDBACK

Earlier this month, I asked the INFO-HAMS "world" a question
pertaining to dual-band HTs.  I got such a good response to my
inquiry, I thought I'd share a few of my my "answers" back with the
INFO-HAMS group.  Hopefully, this feedback will be of benefit to
someone.




My initial inquiry went as follows:




ATTN: DUAL-BAND HT OWNERS!

I'm in the market for a dual-band HT and want to know if any of
y'all have had any experience, good or bad, that I may profit from?

I'm leaning toward the YAESU FT-470 because of its price, size, memory
management features and autopatch auto-dialer.  Also looking at ICOM's
IC-32AT and the new KENWOOD TH-75A.  The FT-470 is the least expensive
of the three (I found a source that quoted me $479).  I've always been
an ICOM-man in the past, but I have an open mind.

Candid owner/operator comments are what I'm looking for.  If you had
it to do all over again...which rig (if any at all) would you go with?
Any regrets in going dual-band on a HT platform?  Etc., etc., etc.

With the price of these rig's being what they are, I need to do it
right the first time!

THANKS!

Martin Mullican, KB5JDQ





Here are some of the responses I got from you, the INFO-HAMS folks.





Martin,

I purchased the Icom IC-32AT at Dayton Hamfest.  I had looked at and
talked to the owners of all the dual band talkies.  When I started
looking I had a strong bias towards the Icom because of the
accessories that I already had.  At Dayton I saw the Yaesu 470 and
several hams that I know bought them outright. After playing with one
for a while I almost went inside and bought one but then I stopped and
talked to the fellow that is at most of the major hamfests who does
all the mods to the radios. When I found out all the things that he
could make the 32AT do I decided to go ahead and get one and also
protect my investment in Icom accessories.  One of the mods that he
makes converts the 32AT into a cross band repeater without any
external hardware.  I bought it from Universal Amateur Radio in
Reynoldsberg Ohio for $499. I did buy the Yaesu 4700 mobile dual band
radio though.

Randy Jarrett  WA4MEI





Martin:

I have owned a Yaesu FT-727R for about a year now and love it.  However,
it is nothing compared to the new 470.

The dual band HT is great and I don't think I would sacrifice it for
anything else.  Even though you lose some of the convenience of a
small package that is available in some of the mini-HT single band
rigs, the performance that most dual bands offer is much superior.

I am trying to sell my 727 so that I can move up to the 470 quite
soon.  One of my close friends bought the 470 in Dayton and he loves
it.  It has more features on it that all of his other equipment
combined!  Five or six of the other guys in my repeater group have
ordered or are planning on ordering one within the next few months.

On the other hand, one of our group bought the Icom 32AT and is very
happy with it, although it doesn't have as many bells and whistles.

Getting off the subject, would you know of any of the crews from your
base coming up to the London International Airshow on June 3 & 4.  We
are setting up a special events station and would like to get this out
to a few of the crews to see if we can get some good contacts.  Any
help would be appreciated!

Hope this info is of some help.

73 de VE3ZDC...Dave Colvin
Univ. Western Ontario, London, Ont., Canada





Martin:

I own a ICOM 32AT .. and could not be happier with it. This HT has given
me no trouble at and has EVERY feature you could possibly want. This
bulletin board has had some horror stories lately about the Yaesu HT, and
has for the brand new Kenwood HT .. I would wait a year before buying it.
I know that the 32AT is a little pricy ... but believe me ... it is well
worth it.

Fred J. Stellabotte - N2JCD





Martin,

If you've "always been an Icom man", you'll find the IC-32AT
satisfying, and will continually wonder upon hearing all the
HT-of-the-week weenies talking about the more-memory, more-features
Yaesu and Kenwood handhelds whether you've done the right thing after
all.  Until you start dropping the set off tables, onto driveways, and
the like.  Now, I'm told that the small-format Kenwoods withstand
similar abuse well in their own right, although those I've seen that
have been the unplanned objects of such "testing" do end up a bit more
scarred from the experience than the Icoms (an ABS vs. Icom's
polycarbonate case would seem to be the reason).  As an Icom man, you
already have a complement of accessories, all of which will work with
the '32 (obviously excluding the DC adaptor for the older 10.8v
models); get another manufacturer's HT, and welcome to the land of
extras all over again (and if you thought Icom accessory prices were a
bitch, add another five or ten percent and you've got Kenwood prices).

I got my '32 in February and as you can guess, am pleased with it.  I
have noticed that the receiver appears to be a tad less sensitive than
the '02 on 2m and my Yaesu FT-708R's on 70cm, and (corroborating
someone's recent posting on rec.ham-radio) the s-meter is stupidly
over-scaled ("s9" readings with the squelch not set high but still
closed are irksomely common).  The dual-band antenna (like all
dual-band HT antennae I've ever seen) is the weak link in the
tumbling-drop scenario, and with any dual-band HT, should probably be
considered a consumable item, hi.  The available soft case isn't quite
as nice as the older soft cases with their fabric seam-reinforcements,
both in terms of looks and utility (I ceased dicking with the top flap
that's a separate piece on the new case and which opens rearward, in
fact must be opened to get to the keypad; I have thrown it into the
junk box after finding that even after mods with an x-acto knife, it
still is a nuisance).  Icom decided to use up their inventory of belt
clips left over from the micro-nAT line by incorporating them into the
'32's design, and these are a minor liability in that under the wrong
circumstances, they can bend open if the rig snags on something while
still mounted on your belt (and the snag-likelihood is enhanced by the
clip's design's causing the radio to ride 1/4" to 1/2" lower on your
hip).  I've noticed that if you are feeding DC station power to the
rig into the top jack, if that power is interrupted (e.g., by jiggling
the plug), the set is prone to lose information that you've stored in
memory (not a problem if you are careful never to insert/remove the
plug unless the set is switched off first, and I've not yet had any
problems from mobile vibration with the power plug; I encountered the
memory-loss-from-power-glitch phenomenon when heavy-handing the plug
in the shack only).

Not being constrained by a choice of obsolete microprocessor
technology in the design (as the later '02AT et al were), Icom has
been able to update the control software while maintaining the good
parts of its old look-and-feel.  You'll find operation of the set will
come to you quite naturally if you've been using '0n series sets.  The
three jacks on the top panel are now mounted in a rubber block that
provides a nice extra cushion against physical shock (the mic jack on
my '02 worked loose and now keying through it is intermittent; I don't
anticipate ever having this kind of problem occur with the '32).  The
rubber caps for the jacks are now captive instead of eminently
loseable; only the BNC cap is detachable, and the BNC is now recessed
into the top plate, so this one is less likely to go flying away when
you detach from things in a rushed situation.  Battery consumption
seems to be on a par with my '02AT (I use BP-8 or CM-8 packs almost
exclusively).  One odd observation is that when the battery is low, it
will die on 2m transmissions (and the display will flash when the
transmitter is keyed) but will continue to transmit on 70cm for a good
while longer (on 70cm, when the transmitter is keyed, the "TX" led
will light and immediately go out instead of staying lit, and full
power seems to be developed anyway, until the battery really is down).
The '32 receive audio is louder than the '0n's, which is a mixed
blessing in light of the dirty squelch tail (no dirtier than the older
Icoms, just more obtrusive now when making use of the capability to
turn it up louder).

I hope this top-of-the-head user report proves useful to you.  Let's hear
what you ultimately decide to get.  Good luck!

73 de KB6OWB!
Harris





Martin,

     I have been the somewhat satisfied owner of a Yaesu FT-470 for
3 weeks now.  Their are a few things wrong with the rig that I flat
out believe are due to dumb engineering.  The radio *IS* a pretty
nifty rig on the whole, however.

     First off, the few things mentioned on INFO-HAMS have been checked
out by me, KB7Z, and N7CTM.  We all possess 470's.  My rig and KB7Z'z
are consecutive serial numbers 90243 and 90244.  Having a rig out of
the first thousand can have it's drawbacks.

      The problem about the 17.3 MHz IF is indeed true.  Our local
NOAA weather station is on 162.475.  I took my FT-23 and dialed up
145.175 (in the band plan allocated to linear translator outputs, none
in this area) and sure enough when I keyed the transmitter, NOAA popped
out on the FT-470.  It could be a big problem for people in Cincinnati...
Better engineering could have prevented that problem.

      The second OH FU I have found is annoying because it's a goof
that I feel only a novice or an engineer with a deadline would make.
If the radio is *NOT* receiving a signal on *EITHER* band, the speaker
is totally silent.  No problem.  Just what you'd expect.  If you are
monitoring both bands with one band inactive and the other band receiving
a nearly full-quieting to full-quiet signal, you can hear the unsquelched
inactive band audio about 20 to 30 db down under the audio from the
active receiver.  I think any sane engineer would have designed the radio
such that an inactive receiver would have it's audio completely muted
going into the audio mixer.  If you are outside or in a car, it isn't
really noticeable unless you are listening explicitly for it.  Indoors
in a reasonably quiet room, you can't really avoid hearing it.  Some people
think the received signal isn't full quieting.  I haven't been out to the
shop yet, but one of these days when I am, I'm going to hook it up to the
communications monitor and measure the level of the squelch noise and write
YAESU a nasty-gram.  Actually, I'm told that Yaesu knows about some of
problems and is going to do some corrective engineering.  It wouldn't hurt
to call them (1-213-404-2700 or I think 1-800-999-2070) and mention the
problems and see what you can find out.  Maybe they'll get enough abuse
that they *WILL* fix them.

      On the other hand, the features designed into this rig make it very
desireable.  Since we don't have local repeater outputs screwing around
with local WX stations in the receiver front ends, the first problem *isn't*.
I live with the squelch mute problem by baising the balance control toward
the primary band which helps.  The new Kenwood HT has only two channels on
each band that carry "odd" splits.  All others have to conform to band
plan.  :-(=  It only has 20 memories per band, as I recall.  The Yaesu has
21 memories/band *ALL* of which can be programmed for any split.  The
"standard" split selected is changeable.  The offset is also changeable.
It will store ten 15-digit phone numbers in the autodial memories.  The
frequency increment in VFO mode is programable as well.

      Where I work, we hold a license in the Experimental Radio Service
for about a dozen frequencies between 152.0 and 159. MHz.  The license
limits us to a power level of which I can't recall (25 watts?) and has
a waiver on the type acceptance requirements.  The only requirement is
that its up to *US* to correct any interference problems that we cause.
We build and use a lot of little 1 watt transmitters to remotely acquire
data in the field for our research.  Hence, I am awaiting the Technical
Manual (supposed to be available in June) to see if (1) it can be modified
for out-of-band transmission and (2) it will cross-band repeat.

      In closing, I must say I really have no regrets that I purchased the
FT-470.  I have already found it very convenient vs packing around either
my FTH-2005, FT-23R, or FT-73R.  KB7Z has a Kenwood UHF handheld (I can't
recall the model.  He preferred it to the FT-73R, but now carries his FT-470
around.  He also has and likes his Kenwood 721 Dual Band rig, so he isn't
really biased one way or the other unlike me.  I'm an old Icom man, too
(IC-230, IC-22A, IC-2AT).

Since I'm starting to ramble I'll close this out.  Hope you find this
of some use.
                         73,
                         Reid






Martin,

I have the ICOM, and would do it again.  The Yaesu and Kenwoods aren't
up to the Icom in quality.  The Yaesu is very attractive, I'll admit.
I've never owned any other units, so this isn't worth a lot.






Martin:

I too have just went through the dual-band HT study. I was
serious about the YAESU FT-470, but after talking to several
people who are strong YAESU fans, I had second thoughts.

They always seem to have one problem after another. You will
also notice a lot of notes bandwidth concerning image problems
that this new model has.

Many of the local ARES and CAP groups use ICOM and swear by it.
I was convinced,  and bought the ICOM 32AT and LOVE IT!!

Jeff, WO0J





In closing, let me say THANKS for all your help folks!

73,

Martin Mullican, KB5JDQ
Kelly AFB MARS
San Antonio, TX


P.S.  I bought the ICOM!

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

Date: 22 May 89 20:27:43 GMT
From: ginosko!infinet!ulowell!tegra![e-mail]  (Johnathan Vail)
Subject: FCC's recognition of repeater coord

In article <[e-mail]> [e-mail] writes:

   > Hmmm, this was my original question but I still think you might not
   > understand what it was. If I take a TRUE FULL DUPLEX PACKET REPEATER
   > can I have it's input frequency on ...say 145.03 and it's output on

   > The main question here is legality. If you can run simplex packet on
   > 145.03 and also on 147.555... why not the same frequencies for digital
   > repeater use? Would the FCC put the kabosh on this?

   Since the frequencies in 2 meters that repeaters are allowed on are
       144.5 - 145.5 Mhz  and
       146.0 - 148.0 Mhz
   that should be legal to do.

To me it seems like these are simplex frequencies being used for
repeater operation.  Of course another way of looking at it is packet
channels being used for packet....

   Have you considered cross-band repeats?  That would REALLY simplify the
   duplexer, like in almost none.

And the really great part is everyone would need 2 radios (or one dual
band) to dedicate to packet... :-)

``Bunnies believe in deeds, not words.''
 _____
|     | Johnathan Vail | tegra![e-mail]
|Tegra| [phone] | N1DXG@145.110-,145.270-,444.2+,448.625-
 -----

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

Date: Tue, 23 May 89 11:03:54 EDT
From: Dan Cerys <[e-mail]>
Subject: New Ham, looking for HT, interesting call

   something that I can put mod's on if possible.   Our company runs it's
   trucks at 463.712Mhz, and I can legally transmit and recieve there because
   of this fact (not on my ham licence).  Anyway, if I could get a 2m/440
   HT that would expand up to the 460+ Mhz range it would be very desirable.

Sure, you can transmit on your commercial frequency, but only with
something that is FCC type accepted for that use.  Most ham rigs aren't, so
you probably won't be able to legally use your ham HT to talk to your
trucks.  This is a common mistake.

   Second, I see a few ALL MODE packet radio devices on the market.  Could
   someone please recommend their packet system to me?  I want to run KA9Q's
   package on a 286 or 386 box running under SCO Xenix.  I have seen AEA's
   PK-232, and the Kantronics All Mode in magazines, however have seen no one
   with personal experience on the boxes.  Obviously I'd like something
   that can run KISS because I want to run KA9Q (unless I am missing something).

I'll reiterate the advice that Phil Karn gave me about a year ago: If all you
are interested in is running the KA9Q TCP/IP software, don't bother
spending the big bucks on an all-mode TNC.  You can pick up a TNC2-clone
for <$100 at a flea mkt, and a new one for not much more.  Buying an
all-mode TNC would be a waste of features (and money) if all you're doing
is running NET.  If you ever need those other modes, you can get a KAM/AEA
at that timee.  But odds are, if you do, you'll probably have a full-time
packet station with a dedicated TNC (ie, the simple one you orginally
bought).

Good luck!
Dan, N1FMK

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

End of PACKET-RADIO Digest
******************************
24-May-89 02:17:27-MDT,11980;000000000000
Return-Path: <[e-mail]>
Date: Wed, 24 May 89 01:30:30 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #142
To: [e-mail]

PACKET-RADIO Digest         Wed, 24 May 89       Volume 89 : Issue 142

Today's Topics:
                 Programming
----------------------------------------------------------------------

Date: 23 May 1989 09:41-CDT
From: [e-mail]
Subject: Programming

Although not directly related to packet radio, I know most
packeteers are some variety of programmers, too.

Hope you enjoy this, even if it is a bit long.

Begin forwarded message
Received: SAC.2001CS-SCTC created at 16-May-89 09:56:25
Date: 16 May 1989 09:56-CDT
From: "KI Sawyer Small Computer Center" <[e-mail]>
To: [e-mail], [e-mail], [e-mail],
    [e-mail], [e-mail],
    [e-mail], [e-mail]
Cc: [e-mail]
Subject: Programming
Message-ID: <[E.ISI.EDU]16-May-89 09:56:10.SAC.2001CS-SCTC>
Sender: [e-mail]


           Real Programmers Don't Write Specs

  Real Programmers don't write specs -- users should consider
  themselves lucky to get any programs at all and take what they
  get.

  Real Programmers don't comment their code.  If it was hard to
  write, it should be hard to understand.

  Real Programmers don't write application programs; they program
  right down on the bare metal.  Application programming is for
  feebs who can't do systems programming.

  Real Programmers don't eat quiche.  In fact, real programmers
  don't know how to SPELL quiche.  They eat Twinkies, and
  Szechwan food.

  Real Programmers don't write in COBOL.  COBOL is for wimpy
  applications programmers.

  Real Programmers' programs never work right the first time.
  But if you throw them on the machine they can be patched into
  working  in "only a few" 30-hour debugging sessions.

  Real Programmers don't write in FORTRAN.  FORTRAN is for pipe
  stress freaks and crystallography weenies.

  Real Programmers never work 9 to 5.  If any real programmers
  are around at 9 AM, it's because they were up all night.

  Real Programmers don't write in BASIC.  Actually, no
  programmers write in BASIC, after the age of 12.

  Real Programmers don't write in PL/I.  PL/I is for programmers
  who can't decide whether to write in COBOL or FORTRAN.

  Real Programmers don't play tennis, or any other sport that
  requires you to change clothes.  Mountain climbing is OK, and
  real programmers  wear their climbing boots to work in case a
  mountain should suddenly  spring up in the middle of the
  machine room.

  Real Programmers don't document.  Documentation is for simps
  who can't read the listings or the object deck.

  Real Programmers don't write in PASCAL, or BLISS, or ADA, or
  any of those pinko computer science languages.  Strong typing
  is for people with weak memories.

  Real programmers never make up schedules.  Only planners make
  up schedules. Only managers read them.

  Real programmers never deliver programs on schedule.  Either
  the program is "done" in two days or it is never finished.  In
  any case, it is never delivered when it was scheduled.

  Real programmers never eat at restaurants. If the vending
  machine sells it they eat it.  If it doesn't, they don't.
  Recently real programmers discovered that popcorn was being
  sold in vending machines.  Common coders discovered that it
  could be popped in the microwave oven in the vending- machine
  room but real programmers use the heat escaping from the top of
  the CPU.

  Real programmers never deliver programs on Wednesdays.  Real
  programmers never deliver programs on the first day of any
  month.

  Real programmers know that good human factors design requires
  only the application of common sense.  Besides, no one cares
  about users. The program's written for aesthetic beauty.

  Real programmers know every nuance of every instruction and
  they use them all in every program.

  Real programmers do not clear registers twice before using
  them.  In fact, if you annoy a real programmer, he/she won't
  clear the registers at all.  And that goes for your memory too!

  Real programmers do not wonder where the bits went following a
  shift operation. They do not care.

  Real programmers are not in it for the money.  Most of them are
  secret millionaires.


        REAL SOFTWARE ENGINEERS DON'T READ DUMPS

  Real software engineers don't read dumps.  They never generate
  them, and on the rare occasions that they come across them,
  they are vaguely amused.

  Real software engineers don't comment their code.  The
  identifiers are so mnemonic they don't have to.

  Real software engineers don't write applications programs, they
  implement algorithms. If someone has an application that the
  algorithm might help with, that's nice.  Don't ask them to
  write the user interface, though.

  Real software engineers eat quiche.

  If it doesn't have recursive function calls, real software
  engineers don't program in it. Real software engineers don't
  program in assembler.  They become queasy at the very thought.

  Real software engineers don't debug programs, they verify
  correctness.  This process doesn't necessarily involve
  executing anything on a computer, except perhaps a Correctness
  Verification Aid package.

  Real software engineers like C's structured constructs, but
  they are suspicious of it because they have heard that it lets
  you get "close
  to the machine."

  Real software engineers play tennis.  In general, they don't
  like any sport that involves getting hot and sweaty and gross
  when out of range of a shower.  (Thus mountain climbing is
  Right Out.)  They will occasionally wear their tennis togs to
  work, but only on very sunny days.

  Real software engineers admire PASCAL for its discipline and
  Spartan purity, but they find it difficult to actually program
  in.  They don't tell this to their friends, because they are
  afraid it means that they are somehow Unworthy.

  Real software engineers work from 9 to 5, because that is the
  way the job is described in the formal spec.  Working late
  would feel like using an undocumented external procedure.

  Real software engineers write in languages that have not
  actually been implemented for any machine, and for which only
  the formal spec (in BNF) is available.  This keeps them from
  having to take any machine dependencies into account.  Machine
  dependencies make real software engineers very uneasy.

  Real software engineers don't write in ADA, because the
  standards bodies have not quite decided on a formal spec yet.

  Real software engineers like writing their own compilers,
  preferably in PROLOG (they also like writing them in
  unimplemented languages, but it turns out to be difficult to
  actually RUN these).

  Real software engineers regret the existence of COBOL, FORTRAN
  and BASIC.  PL/1 is getting there, but it is not nearly
  disciplined enough; far too much built in function.

  Real software engineers aren't too happy about the existence of
  users, either.  Users always seem to have the wrong idea about
  what the implementation and verification of algorithms is all
  about.

  Real software engineers don't like the idea of some
  inexplicable and greasy hardware several aisles away that may
  stop working at any moment.  They have a great distrust of
  hardware people, and wish that systems could be virtual at ALL
  levels.  They would like personal computers (you know no one's
  going to trip over something and kill your DFA in mid-transit),
  except that they need 8 megabytes to run their Correctness
  Verification Aid packages.

  Real software engineers think better while playing WFF 'N'
  PROOF.


           Real Computer Scientists Don't Write Code

  Real computer scientists don't write code.  They occasionally
  tinker with 'programming systems', but those are so high level
  that they hardly count (and rarely count accurately; precision
  is for
  applications.)

  Real computer scientists don't comment their code.  The
  identifiers are so long they can't afford the disk space.

  Real computer scientists don't write the user interfaces, they
  merely argue over what they should look like.

  Real computer scientists don't eat quiche.  They shun Schezuan
  food since the hackers discovered it.  Many real computer
  scientists consider eating an implementation detail.  (Others
  break down and eat with the hackers, but only if they can have
  ice cream for dessert.)

  If it doesn't have a programming environment complete with
  interactive debugger, structure editor and extensive cross
  module test checking, real computer scientists won't be seen
  tinkering with it.  They may have to use it to balance their
  checkbooks, as their own systems can't.

  Real computer scientists don't `write` in anything less
  portable than a number two pencil.

  Real computer scientists don't debug programs, they dynamically
  modify them.  This is safer, since no one has invented a way to
  do anything dynamic to FORTRAN, COBOL or BASIC.

  Real computer scientists like C's structured constructs, but
  they are suspicious of it because its compiled.  (Only Batch
  freaks and efficiency weirdos bother with compilers, they're
  soooo un-dynamic.)

  Real computer scientists play go.  They have nothing against
  the concept of mountain climbing, but the actual climbing is an
  implementation detail best left to programmers.

  Real computer scientists admire ADA for its overwhelming
  aesthetic value, but they find it difficult to actually program
  in, as it is much too large to implement.  Most Computer
  scientists don't notice this because they are still arguing
  over what else to add to  ADA.

  Real computer scientists work from 5 pm to 9 am because that's
  the only time they can get the 8 megabytes of main memory they
  need to edit specs.  (Real work starts around 2 am when enough
  MIPS are free for their dynamic systems.)  Real computer
  scientists find it hard to share 3081s when they are doing
  'REAL' work.

  Real computer scientists only write specs for languages that
  might run on future hardware.  Nobody trusts them to write
  specs for anything homo sapiens will ever be able to fit on a
  single planet.

  Real computer scientists like planning their own environments
  to use bit mapped graphics.  Bit mapped graphics is great
  because no one can afford it, so their systems can be
  experimental.

  Real computer scientists regret the existence of PL/I, PASCAL
  and LISP.  ADA is getting there, but it is still allows people
  to make mistakes.

  Real computer scientists love the concept of users.  Users are
  always real impressed by the stuff computer scientists are
  talking about;  it sure sounds better than the stuff they are
  being forced to use now.

  Real computer scientists despise the idea of actual hardware.
  Hardware has limitations, software doesn't.  It's a real shame
  that Turing machines are so poor at I/O.

  Real computer scientists love conventions.  No one is expected
  to lug a 3081 attached to a bit map screen to a convention, so
  no one will ever know how slow their systems run.




Lee Coin



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

End forwarded message


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

End of PACKET-RADIO Digest
******************************
25-May-89 02:53:25-MDT,9507;000000000000
Return-Path: <[e-mail]>
Date: Thu, 25 May 89 01:30:44 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #143
To: [e-mail]

PACKET-RADIO Digest         Thu, 25 May 89       Volume 89 : Issue 143

Today's Topics:
               HF Packet Radio
         KA9Q TCP/IP Configuration Question (2 msgs)
           TheNetRom & software innovation
             TNCs and Terminals (2 msgs)
----------------------------------------------------------------------

Date: 23 May 89 18:25:15 GMT
From: ncrlnk!ncratl![e-mail]  (Gordon Edwards)
Subject: HF Packet Radio

I have started to get interested in working packet on the HF bands...
What frequency ranges are the most active?

Also, how much HF packet is present on HF?  Is RTTY better or more
popular?

--
Gordon Edwards  << N4VPH >>                         NCR Corporation
[e-mail]                      5555 Oakbrook Parkway
uunet!ncrlnk!ncratl!edwards                         Suite 140
                            Norcross, GA  30093

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

Date: 23 May 89 22:32:53 GMT
From: fluke![e-mail]  (Paul Lutt)
Subject: KA9Q TCP/IP Configuration Question

I need some help configuring the KA9Q TCP/IP package.  I've used the
package with great success on packet radio.

I now want to try it on an ethernet using a WD8003E ethernet interface
card.  I don't have any documentation describing how to use the new
packet driver software.

Here is what I think is required:

1) Install the wd8003e driver:

    wd8003e packet_int_no hdw_int_no io_addr mem_base

2) Setup a proper autoexec.net file:

    attach packet packet_int_no interface_label max_#_packets mtu

3) Start net.exe

My problem seems to be in selecting a proper "packet_int_no".  I am
guessing that this is actually the software interrupt vector to be used
to access the packet driver.  I know very little about MS-DOS, so I'm
not sure what a reasonable value might be.  The rest of the arguments
seem pretty obvious, except for "interface_label".  I'm not sure what
that should be.

I'm running the 871225.31 version of "net.exe".  I hope someone out
there in netland can help me out.  I have the packet driver
documentation from FTP Software, Inc., but it doesn't seem to answer
these particular questions.

73,

Paul   KE7XT
--
    Paul Lutt
Domain: [e-mail]
 Voice: [phone]
  UUCP: {uw-beaver,microsof,sun}!fluke!pwl
 Snail: John Fluke Mfg. Co. / P.O. Box C9090 / Everett WA  98206

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

Date: 24 May 89 06:07:24 GMT
From: ka9q.bellcore.com![e-mail]  (Phil Karn)
Subject: KA9Q TCP/IP Configuration Question

>My problem seems to be in selecting a proper "packet_int_no".  I am
>guessing that this is actually the software interrupt vector to be used
>to access the packet driver.

Paul,

You guess correct. These vectors should range from 0x60 to 0x80; my
personal favorite is 0x7e.

Regarding the interface label: this can be any name you wish. It is needed
so that you can refer to the interface in "route add" and "trace" commands.
My favorites are "com#" for asynch SLIP/KISS ports, and "ethernet" for
an Ethernet controller.

Phil

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

Date: 24 May 89 06:22:55 GMT
From: ka9q.bellcore.com![e-mail]  (Phil Karn)
Subject: TheNetRom & software innovation

Jay Splut asks:

>>How come my AT running Unix slows down whenever I fire up the TCP/IP
>>package?

The reason is that the KA9Q NET implementation for System V is a hack job;
it runs as an application in user space. Because NET has to deal with
several I/O streams, and because System V lacks an equivalent to the
Berkeley select() system call, it has no choice but to poll each device
continuously in "no delay" mode. This soaks up all available CPU time and
steals time from other processes, even when nothing is happening on the
network.

The proper way to implement TCP/IP in a UNIX system is the way Berkeley did
it: in the kernel, under a decent interprocess communication mechanism,
e.g., sockets. Unfortunately, sources are generally not available for System
V so this is not something you can do very easily. But when it's done right,
it works quite well; the TCP/IP protocol processing overhead is minimal
compared with the overhead of handling an 8250-style character-at-a-time
serial channel.

If you don't believe me, try testing the throughput of my TCP code under
MS-DOS in software loopback mode. (Be sure to comment out the disk accesses,
though; I've found that hard disk I/O speed is the main limitation on the
speed of a file transfer.) Then scale the resulting throughput figure down
to 1200 baud (or whatever speed packet channel you're using) and figure
what percentage of the CPU that represents.

(On my own system, a 10 MHz AT clone, I get speeds of about 120 Kbytes/sec.
This isn't the fastest TCP available for the PC, but I do think it's
sufficient for amateur packet radio.)

Phil

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

Date: 23 May 89 18:07:51 GMT
From: cs.utexas.edu!milano!bigtex!helps!bongo![e-mail]  (julian macassey)
Subject: TNCs and Terminals

In article <[E.ISI.EDU]19-May-89.04:26:45.SAC.2001CS-XP>, [e-mail] ("410 BMW/SCX--KI Sawyer AFB MI") writes:
>
> We all know that a TNC has all the brains needed to run packet, so
> when will someone come out with a decent and cheap portable terminal
>  to use with packet.  I mean something we can use, not a 20 dollar VIC-20
> or similar where you have to use a TV set, external disk to load the
> terminal program etc.
> For crying  loud, you can buy a spell checker thing that has
> 64k or so of memory and everything, a nice lcd display rechargeable batteries
> and fits into a ladies purse for under 50 bucks.  Surely a similar device
> with a simple terminal program in ROM and an RS-232 port should be available for
> 100-150 bucks.  Add a battery printer like is in  a calculator for another
> 50 bucks or so and the portable packet folks would jump on it.
>
> TAPR are you listening?  Henry radio is on the right track with their new
> mobile TNC/printer combo even if it is a bit pricey.
>
> If we are going to be forced into multi-kilobuck laptops, how about
> internal TNCs that would go where the internal telephone modem goes?
> I think something similar to the DRSI TNC would be nice in a laptop
> version, but is the DRSI a complete standalone TNC? Never have
> figured out that one yet.

    So, exactly what you want may or not be out there. You want a $100.00
dollar portable packet terminal? Have you looked at a used TRS-100 laptop?
Olivetti and NEC used to sell the same thing under different model names.
These devices will do what you want. I use a laptop (Toshiba T1100P) for my
portable packet which is probably overkill. But for about $300 you could
find a used T1000 which is a single drive unit that can give you Wordstar
for off line editing, plus Procomm, YAPP or your favourite comm prog and
editor.

    You may find though that using a small simple laptop like the TRS-100 is
a real pain. Reading a 40 col 3 row display is pretty tricky, expecially
when stuff is scrolling by at a fair clip. The word processor and comm
programs are a bit tricky and limited. I find the spelling thesaurus
machines limited too.

    Also if you get a real laptop running real MS-DOS, you can use it for
other things too. WOW! you can even call into the big Unix machine at home
and do mail news and use vi. Dont try that from a 40 col tiny laptop like a
TRS-100. I have never regretted getting an MS-DOS laptop. I use it all the
time and even schlep it to clients to do work at their site and also to
upload/download software to computers and even PBXs. You will find more uses
for an MS-DOS laptop than a full set of Ginsu knives.
>

Yours


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

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

Date: 24 May 89 06:03:29 GMT
From: ka9q.bellcore.com![e-mail]  (Phil Karn)
Subject: TNCs and Terminals

>We all know that a TNC has all the brains needed to run packet, so
>when will someone come out with a decent and cheap portable terminal
> to use with packet.

I hope you are being facetious. Your typical TNC has a Z-80 for a brain.
Z-80s are now about 13 years old and hopelessly out of date.  It seems
quite clear that we need to get rid of the TNC as a separate box and
move its functions into general purpose computers. Laptops are now entirely
capable of running a true computer networking protocol suite such as TCP/IP.

>TAPR are you listening?

I do not believe that the limited time and resources of the amateur
community are well spent on developing computer hardware that can be bought
off the shelf (terminals, computers, etc). We need to concentrate on
building that which cannot be bought off the shelf (for reasonable prices,
anyway).

Phil

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

End of PACKET-RADIO Digest
******************************
26-May-89 02:39:50-MDT,21133;000000000000
Return-Path: <[e-mail]>
Date: Fri, 26 May 89 01:31:11 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #144
To: [e-mail]

PACKET-RADIO Digest         Fri, 26 May 89       Volume 89 : Issue 144

Today's Topics:
                A Plea
           ARRL Natl Conv. Packet Programs
         FCC's recognition of repeater coord
           G8BPQ PC/Node - (legal) NET/ROM
       NEW! SWL bitnet mailing list, Subscription info:
           TheNetRom & software innovation (2 msgs)
----------------------------------------------------------------------

Date: 25 May 89 23:40:33 GMT
From: jupiter.bellcore.com![e-mail]  (Phil Karn)
Subject: A Plea

Lately I've been receiving an increasing number of messages asking
questions about the UNIX ports of my code, particularly Xenix and AT&T
Unix System V (e.g., Microport).

I need to point out a few things:

1. I did not do these ports. In fact, all of my TCP/IP development work
is done on an AT clone running MS-DOS 3.3. That is the ONLY version of
NET about which I can answer questions.

2. As a matter of personal principle, I avoid all AT&T-based UNIX
systems.  All of the UNIX systems I use run Berkeley or Berkeley-derived
code (e.g., SunOS, Ultrix). Since all BSD-based UNIX systems already
have full TCP/IP support, there is little reason to run my code on those
systems.

3. Bob Hoffman, [e-mail], has graciously agreed to
act as coordinator of those working with UNIX ports of my code. Please
direct any questions about these versions to him, not to me.

Thanks!

Phil Karn, KA9Q

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

Date: 25 May 89 03:08:23 GMT
From: n8emr![e-mail]  (Gary Sanders)
Subject: ARRL Natl Conv. Packet Programs

==============================================================
|               Relayed from packet radio via                |
| N8EMR's Ham BBS, 614-457-4227 (1200/2400/19.2 telebit,8N1) |
==============================================================


#: 98725 S9/Packet Radio
    22-May-89  02:06:08
Sb: #Nationals Packet Forum
Fm: Greg Jones / WD5IVD 72047,3455
To: all

HamCom '89  ARRL Nationals June 2-4th, 1989 Packet Forum Schedule
Sponsored by  : Texas Packet Radio Society

Saturday - June 3rd
  9:00am -  9:55am     Packet Radio for Beginners      Greg Jones - WD5IVD
                               Mike Maner - WI5H

 10:00am - 10:25am     HF Packet : Hints and Kinks     Bob Goodman - AA5FR

 10:30am - 10:55am     Packet Mailboxes and the NTS    David Cheek - WA5MWD

 11:00am - 11:55am      PANEL Discussion
               "The Future Directions of Packet Radio"
                  ARRL -  Jon Bloom, KE3Z
                  TPRS - Tom McDermott, N5EG
                  AMSAT -  Doug Loughmiller, KO5I
                  AEA - John Downing, N7GMF
                  DRSI - Andy Dimartini, KC2FF

 12noon - 12:25pm      DX and Packet Radio :           Bob Goodman - AA5FR
               What a Marriage                 Trey  - WN4KKN

 12:30pm - 12:55pm    .01 : Operations in Texas        Carl Finke - WB5DDP

  1:00pm -  1:55pm     TexNet - The Saga Continues     Tom McDermott - N5EG

  5:00pm -  6:00pm     TPRS Annual Business Meeting

  5:00pm  ***** TPRS/AMSAT/TAPR Hospitality Suite at the Sherton *****



Sunday - June 4th.  (30min recaps for those who missed Saturday)
  9:00am -  9:30am     Packet for Beginners             Mike Maner - WI5H

  9:30am - 10:00am     HF Packet : Hints and Kinks      Bob Goodman - AA5FR

 10:00am - 10:30am     DX and Packet Radio :            Trey  - WN4KKN
               What a Marriage                  Bob Goodman - AA5FR

 10:30am - 11:00am     .01 Operations in Texas          Carl Finke - WB5DDP

 11:00am -  1:00pm     TPRS State-Wide Working Groups

If you attend the Nationals,please stop booth #16 and say HI. Also - the
hospitality suite should be GREAT !

73 - Greg Jones WD5IVD
     TPRS / Packet Radio Forum Coordinator



W8CQK BBS (1)>
Date: 23 May 89 02:14
Message-ID: <8219@KC8TW>
From: N8XX@KC8TW
To: ALL@OKIPN
Subject: ARRL Natl Conv Packet Synopsis
Path:       AD8I!N8ACV!WB8ICL!N8GTC!KC8TW


#: 98726 S9/Packet Radio
    22-May-89  02:08:24
Sb: #98725-Nationals Packet Forum
Fm: Greg Jones / WD5IVD 72047,3455
To: Greg Jones / WD5IVD 72047,3455 (X)

HamCom '89  ARRL Nationals June 2-4th, 1989 Packet Forum Descriptions
Sponsored by  : Texas Packet Radio Society

Packet Radio for Beginners
     Greg Jones - WD5IVD
     Mike Maner - WI5H The presentation will cover what packet radio
is, how you get on the air, and how you use it once you are on.

HF Packet : Hints and Kinks
     Bob Goodman - AA5FR The presentation will cover operating packet
     on the HF bands. Are you ready to move beyond two meter digipeating to
     world wide communicating over HF packet.  Learn Bobs secrets on
     working packet on the HF bands. Bob was recently published in the June
     issue of QST.

Packet Mailboxes and the NTS
     David Cheek - WA5MWD The presentation will cover aspects of how
     NTS works over packet and how to best use packet for handling NTS
     traffic.

"The Future Directions of Packet Radio"  - PANEL Discussion The Panel
will be made up from : TPRS, AMSAT, TAPR, ARRL, AEA, and DRSI. This
should be an excellent opportunity to hear what the experts think the
future of packet radio is and what directions it will be taking.

DX and Packet Radio - What a Marriage
     Bob Goodman - AA5FR
     Trey - WN4KKN This presentation will discuss the use of packet
     spotting networks and how they can increase DXing enjoyment on the
     bands.  If you chase DX donUt miss this talk.

01 Operations in Texas
     Carl Finke - WB5DDP The presentation will talk about what is, how
     to use, and the future of the .01 network in Texas.

TexNet - The Saga Continues
     Tom McDermott, N5EG This presentation will concern how TexNet is
     used, works, and what the current developments on the network are.  A
     live network demostration will be held.  If you are a user or
     interested in TexNet, you shouldnUt miss this one.

73 - until June 2-4th in Dallas/Ft Worth ! Greg Jones - WD5IVD


--
Gary W. Sanders (gws@n8emr or ...!osu-cis!n8emr!gws), 72277,1325
N8EMR @ W8CQK (ip addr) 44.70.0.1 [Ohio AMPR address coordinator]
HAM/SWL/SCANNER BBS (1200/2400/PEP) 614-457-4227

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

Date: 25 May 89 15:27:00 GMT
From: ux1.cso.uiuc.edu![e-mail]
Subject: FCC's recognition of repeater coord

> To me it seems like these are simplex frequencies being used for
> repeater operation.  Of course another way of looking at it is packet
> channels being used for packet....

What's legal, and what the band plan is, are two different things.
If you violate the band plan but do not cause interference (or violate any
other rules) then you are LEGAL, a LID maybe, but LEGAL.

>    Have you considered cross-band repeats?  That would REALLY simplify the
>    duplexer, like in almost none.
>
> And the really great part is everyone would need 2 radios (or one dual
> band) to dedicate to packet... :-)

Or, you could only talk to people on the Other band if the repeater is
reversable.

What if all the repeaters talked to everyone on 145.01 and talked to each
other on 223.40?  As long as you could reach TWO machines, you are in.  Of
course that also requires the repeaters be addressable, which I have not yet
seen an implementation that can do this and repeat live (something I have been
wanting to do).

--Phil howard--  <[e-mail]>

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

Date: 25 May 89 03:09:58 GMT
From: n8emr![e-mail]  (Gary Sanders)
Subject: G8BPQ PC/Node - (legal) NET/ROM

==============================================================
|               Relayed from packet radio via                |
| N8EMR's Ham BBS, 614-457-4227 (1200/2400/19.2 telebit,8N1) |
==============================================================


#: 98663 S9/Packet Radio
    21-May-89  14:21:25
Sb: #G8BPQ Network Software
Fm: Andy Demartini KC2FF 76011,1554
To: All

Ladies & Gentlemen-

       I see that news of John Wiseman's implementation of NET/ROM for the
pc environment has started to find its way into this country. This unique
piece of software has some real benefits for BBS sysops and deserves a
close look by everyone.

       John G8BPQ has called his program TheNode, and that is how it is
known in the UK. It is bundled together with every DRSI PC*Packet Adapter
we deliver, renamed as PC/Node to avoid any association with NORDLINK or
TheNet.

       For anyone considering this as an alternative to NET/ROM, please
take note and spread around that G8BPQ's implementation is a completely
independent implementation of NET/ROM. John worked from the published
Software 2000 specification, worked with a different compiler and has
produced a new program which is compatible, but with new and valuable
features. DRSI has provided Ron Raikes WA8DED with copies of G8BPQ's code
for his examination. Ron has said that it appears to be a totally
independent creation. Both Ron and John have separately told me that they
have never met or spoken with each other. Anyone can use this code with the
best assurances that it is exactly what is presented- a compatible
alternative to NET/ROM.

       PC/Node works this way - It provides both a NET/ROM-compatible
driver and a BBS-support interface in the form of a Terminate-and-Stay-
Resident program. When used with the PC*Packet Adapter, PC/Node turns the
adapter into a dual-port node. It will broadcast its identity into the
surrounding network and will accept other nodes into its own tables. It
looks just like a NET/ROM node.

       PC/NODE also has support for both the W0RLI and WA7MBL bulletin
boards. The same TSR presents a "virtual COM: port" within standard DOS.
The sysop declares a set of these com: ports in the configuration file. For
example, he might declare COM10:,COM11: and COM12:. These three ports do
not exist in hardware, but any MBBIOS-compatible application can open them
and "talk" to the node. John has provided a subset of the standard commands
at this interface, enough to be able to run either BBS. If the host system
has enough memory, several copies of these BBS's can be run in separate
windows. We see no reason why both W0RLI and WA7MBL could not be run
simultaneously in the same system.

       Roy Engehausen AA4RE is working with G8BPQ to assist John in adding
the WA8DED Host Mode interface to PC/Node. This will permit Roy's multi-
connect bbs to run with PC/Node.

       To the user, PC/Node looks just like a NET/ROM node which happens to
have a BBS located on-site. He connects to the node, then types either a
connect command to the BBS with its callsign (i.e. "C W4BBS") or simply
types "C BBS". Either command causes the node to immediately connect the
user to any available "virtual COM: port". He is immediately on the board.
If he is a true local, the user can skip connecting to the node, and can
connect directly to the BBS by using its callsign.

       The sysop can configure PC/Node to provide either the NET/ROM
service, the BBS service or both. All configuration is done through a text
file.

OTHER POSSIBILITIES ===================

       Much has been said about the limitations of NET/ROM running in the
32K memory space of a TNC-2. There just isn't any room for additional code
to do any meaningful work. PC/Node provides a way for programmers and
hackers to add new, interesting and valuable functions to their systems.

       While the COM: port has been presented as BBS facility, it can be
also used to interface to any program which talks to an MBBIOS port.  This
immediately opens the door for everyone who wants additional functionality.
Simply write a "server" to perform any function your imagination can
conjure up.

       The professional PC magazines are filled with the "new" client-
server programming model which is being promoted in the Local Area Network
world. This programming approach divides an application into two parts, one
running on the user's system and the other running on the database server.

       If you want additional functionality, write a program which opens
and waits for a ***CONNECTED on the com: ports. With all the A/D, D/A,
control and sense boards on the market, a simple program can control
lights, power, accessories, antennas, security, make coffee, ....  It's
limited only by your imagination.

DEMONSTRATION at the NATIONAL CONVENTION
========================================

       DRSI will be demontrating PC/Node on the air at Ham-Com 89, coming
up on the first weekend in June at the Arlington Convention Center,
Arlington, Texas. Our booth are numbers 11 and 12, and will be right across
from the Texas Packet Radio Society. (TPRS will be demonstrating TEXNET,
another fine alternative network package.) PC/Node diskettes will be
available, for those who want to use this program with KISS-equipped TNC's.

73, Andy KC2FF

     Edited very slightly for packet distribution by Hank Greeb, N8XX

--
Gary W. Sanders (gws@n8emr or ...!osu-cis!n8emr!gws), 72277,1325
N8EMR @ W8CQK (ip addr) 44.70.0.1 [Ohio AMPR address coordinator]
HAM/SWL/SCANNER BBS (1200/2400/PEP) 614-457-4227

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

Date: 25 May 89 20:39:35 GMT
From: cunixc![e-mail]  (John Kingdon)
Subject: NEW! SWL bitnet mailing list, Subscription info:

             ALL ARE INVITED TO JOIN A
    >>>>>NEW SHORT WAVE LISTENERS ELECTRONIC MAILING LIST<<<<<

WHAT IS SWL-L?
--------------
Now there is a medium which SWLers can use to trade information on:

    o Frequency lists (for all modes, all frequencies)
    o Projects (homebrew, from simple to complex)
    o Ask questions about:
        o Monitoring
        o Radios
        o Antennas
        o Listening conditions
        o RFI
        o etc.
    o Learning!

    I have been reading rec.ham-radio(.packet/INFO-HAMS) for 3 years.
While I have learned a great deal from reading this list, I feel it is
important to the SWLing community to have its "own place."  There have been
some SWL related articles, which are welcomed by these Ham forums, yet I
have not found a dedicated SWL related information base.

    Now, there exists such a medium here. There is a new listener's
group set up via LISTSERV here at Columbia University

    Now SWLers can subscribe to a list which will be mailed to them
which will contain items of interest including, but not limited to the above
topic areas.  You can receive frequencies FAST.  How would you like to find
out the utility frequencies for an emergency situation within hours (not
days like it takes some Usenet messages to be sent and replied to via the
net, or MONTHS for magazines!).  How about talking about projects you are
working on, antennas or radio problems?  Many, many issues can be discussed.
I hope you will subscribe to the list, and if you do PLEASE POST!

HOW DO I GET ON THE LIST?
-------------------------
    Just like any Bitnet listserver list you may subscribe to the SWL-L
list here at Columbia University.

INSTRUCTIONS:
    1) if you're sending from a BITNET node, you can say:
    (CMS)   tell listserv at cuvmb subscribe swl-l your name here
    (VMS)   send listserv@cuvmb subscribe swl-l your name here

    2) if you're sending from an internet site, or a UUCP site, do the
following:
         a) send a letter to [e-mail] -or-
            rutgers!columbia!cuvmb.cc.columbia.edu!listserv
         b) the first line of the body of the letter should read:
            subscribe swl-l your names here.

    3) You will receive a letter of confirmation.  In this letter you
will find out more information about listservers and bitnet file servers.

    4) To post to the list send mail to SWL-L@cuvmb with your subject
and letter.  This letter will be echoed to all members of the List.

    5) There is also a file server availiable.  You may get a listing of
the files in the file server (currently there are none) by sending a command
to listserv (addressed in the same manner as you used to sign on the list).
The command will be the body of the letter.  The command for a directory
listing is:
        get swl-l filelist
You may request a specific file by sending a command (to listserv) which
says:
        get filename filetype
as listed in the filelist.

REMEMBER!
--------
    send COMMANDS to Listserv@cuvmb
    send LETTERS  to SWL-L@cuvmb

Sign up and have fun!

John Kingdon
-------------------------------------------------------------------------------
 John Kingdon  (212)-678-1689             |  CompuServe 71471, 1062
 UUCP ...!rutgers!columbia!cunixc!kingdon |  ARPA [e-mail]
 BITNET [e-mail]             |  or [e-mail]

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

Date: 25 May 89 04:36:54 GMT
From: n3dmc![e-mail]  (John Limpert)
Subject: TheNetRom & software innovation

In article <[e-mail]> [e-mail] (Phil Karn) writes:
>Jay Splut asks:
>
>>>How come my AT running Unix slows down whenever I fire up the TCP/IP
>>>package?
>
>The reason is that the KA9Q NET implementation for System V is a hack job;
>it runs as an application in user space. Because NET has to deal with
>several I/O streams, and because System V lacks an equivalent to the
>Berkeley select() system call, it has no choice but to poll each device
>continuously in "no delay" mode. This soaks up all available CPU time and
>steals time from other processes, even when nothing is happening on the
>network.

The System V version of net may be a "hack job" but I can't afford
a "real machine" that has TCP/IP in the kernel.

There is a simple modification that eliminates most of the wasted CPU
time.  The trick is to change the terminal driver configuration options
for the console tty as follows:

    1. Comment out the fcntl() that sets NDELAY mode.

    2. Set VMIN to 0 and VTIME to 1.

This causes the program to block for 1/10 second every time it cycles
through the polling loop.  The modified program uses far less CPU time
than the original version.  Here is the replacement for ioinit() in
sys5_io.c:

/* Called at startup time to set up console I/O, memory heap */
ioinit()
{
    struct termio ttybuf;
    extern int iostop();

    (void) signal(SIGHUP, iostop);
    (void) signal(SIGINT, iostop);
    (void) signal(SIGQUIT, iostop);
    (void) signal(SIGTERM, iostop);

    ioctl(0, TCGETA, &ttybuf);
    savecon = ttybuf;

    ttybuf.c_iflag &= ~IXON;
    ttybuf.c_lflag &= ~(ICANON|ISIG|ECHO);
    ttybuf.c_cc[VTIME] = 1;
    ttybuf.c_cc[VMIN] = 0;
    if ((savettyfl = fcntl(0, F_GETFL, 0)) == -1) {
        perror("Could not read console flags");
        return -1;
    }
#ifdef  NOT_DEFINED
    fcntl(0, F_SETFL, savettyfl | O_NDELAY);
#endif

    ioctl(0, TCSETAW, &ttybuf);
}

--
John A. Limpert                 I'm the NRA!
Internet: [e-mail]    UUCP: uunet!n3dmc!johnl

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

Date: 24 May 89 23:39:16 GMT
From: tank!shamash!com50!quest![e-mail]  (Scott S. Bertilson)
Subject: TheNetRom & software innovation

In article <[e-mail]> [e-mail] (Jay "you ignorant splut!" Maynard) writes:
> How come my AT running Unix slows down whenever I fire up the TCP/IP
> package? If I get any activity on the channel, the response time for
> other tasks goes through the roof. Microport's serial handler is

 I experienced similar problems trying NET on a 3B1 connected to
a Sun at 9600 baud (complete incapacity to do anything else).  It
turns out that the original version of the "sys5_io" routine didn't
do any buffering.  As a result, NET was making single character
read calls to the kernel.  I hacked the version I had at the
time (871225.1) to buffer up to 512 bytes and saw a LARGE
improvement in efficiency.  I am pretty sure this is the
largest single difference between NET and "uucico".  The
version of NET just released (890421.1) includes a buffering
mechanism which seems to work very well.  I have been testing it
at 19200 to a Sun and find that I can actually get other things
done even with an incoming transfer in progress.  (I have
also played games with the output queue high water mark and
the input queue flush mark (NTTYHOG).)
--

Scott S. Bertilson   ...uunet!rosevax!rose3!quest!sheldon
            [e-mail]

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

End of PACKET-RADIO Digest
******************************
27-May-89 02:19:12-MDT,5368;000000000000
Return-Path: <[e-mail]>
Date: Sat, 27 May 89 01:30:39 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #145
To: [e-mail]

PACKET-RADIO Digest         Sat, 27 May 89       Volume 89 : Issue 145

Today's Topics:
                  Callbooks
             TNCs and Terminals (2 msgs)
----------------------------------------------------------------------

Date: 26 May 89 23:50:06 GMT
From: [e-mail]  (Patty Winter)
Subject: Callbooks

In article <[e-mail]> [e-mail] (Rusty) writes:
>Also, I'm surprised that nobody has posted info about their callsign
>servers.

I thought I had mentioned the one on 2m packet radio here in the Bay
Area, but maybe not. I'm giving this followup a nationwide distribution
in the hopes that people in other areas will get interested in offering
the same sort of service.

Doug Thom, N6OYU, has a TCP/IP and AX.25 callsign server operating on
145.75 MHz. On TCP, use the command "finger %callsign@n6oyu". On AX.25,
connect to N6OYU, wait for the prompt line, then type "i callsign".
(The "i" is for "Inquire".)

The request hops over to an AppleShare file server (via an AppleTalk
network), then returns the info to the Macintosh that's running the
packet system, which transmits it to the requestor. Spiffy!


Patty


p.s.  Since I've shifted this topic to include packet radio, I
cross-posted this to .packet in case there's anyone who reads
that newsgroup but not the main one. Is there? I've been wondering.

=============================================================================
Patty Winter N6BIS                        INTERNET: [e-mail]
AMPR.ORG: [44.4.0.44]                     UUCP: {decwrl,nsc,sun}!apple!winter
=============================================================================

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

Date: 26 May 89 01:59:42 GMT
From: [e-mail]  (Jon Edelson)
Subject: TNCs and Terminals

In article <[e-mail]>, [e-mail] (Phil Karn) writes:

>>We all know that a TNC has all the brains needed to run packet, so
>>when will someone come out with a decent and cheap portable terminal
>> to use with packet.
>
>I hope you are being facetious. Your typical TNC has a Z-80 for a brain.
>Z-80s are now about 13 years old and hopelessly out of date.  It seems
>quite clear that we need to get rid of the TNC as a separate box and
I tend to think the opposite.

While a TNC operating at 1200 baud could be run as software in a general
purpose computer, the faster you go the more expensive such a machine would
have to be.  A TNC is a specialized device, and could very well use a
specialized if less powerful processor that would be cheaper.  Why do
that stuff that an HDLC chip would do in software?

The updating should be in the speed and error correcting abilities of the
TNCs, so that they can be used by the general purpose computer for things
such as NFS and the like.  Or by a terminal so as to be able to use a
remote host.

BTW A number of years ago, tandy had a portable terminal.  It was a keyboard,
a modem, and some sort of display or printer.  If packet hits industry, we
will see laptop packet terminals.
>Phil
                       -Jonathan Edelson
[e-mail]
      @pucc.bitnet
      @pucc.princeton.edu
      @phoenix.princeton.edu
" Where am I going?  I don't quite know.
  Down to the stream where the king-cups grow-
  Up on the hill where the pine-trees blow-       When We Were Very Young
  Anywhere, anywhere.  *I* don't know. "              by   A. A. Milne

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

Date: 27 May 89 00:16:34 GMT
From: jupiter![e-mail]  (Phil R. Karn)
Subject: TNCs and Terminals

>While a TNC operating at 1200 baud could be run as software in a general
>purpose computer, the faster you go the more expensive such a machine would
>have to be.  A TNC is a specialized device, and could very well use a
>specialized if less powerful processor that would be cheaper.  Why do
>that stuff that an HDLC chip would do in software?

I don't know if I understand what you are trying to say.  I never said
that HDLC framing should be done in software. What I was trying to say
is that some thought needs to go into the proper division of
responsibilities between general purpose host computer and the "slave"
I/O hardware, keeping in mind the overhead of communicating across the
connection between the two. It is clearly pointless to "offload" a
function to an I/O device if it costs just as much (or more) for the
host CPU to talk to that device, but such is the case right now with
external TNCs connected to hosts by serial lines.

My experience (in amateur packet radio and elsewhere) says that
low-level functions (framing, CRC calculation, raw packet buffering) are
properly done by dedicated hardware, while all higher level functions
(from the link layer protocol on up) are best done by software on the
host computer system.

Phil

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

End of PACKET-RADIO Digest V89 Issue #145
*****************************************
28-May-89 01:52:12-MDT,1896;000000000000
Return-Path: <[e-mail]>
Date: Sun, 28 May 89 01:31:12 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #146
To: [e-mail]

PACKET-RADIO Digest         Sun, 28 May 89       Volume 89 : Issue 146

Today's Topics:
                A Plea
----------------------------------------------------------------------

Date: 27 May 89 16:57:20 GMT
From: nuchat!splut![e-mail]  (Jay "you ignorant splut!" Maynard)
Subject: A Plea

In article <[e-mail]> [e-mail] (Phil Karn) writes:
>2. As a matter of personal principle, I avoid all AT&T-based UNIX
>systems.  All of the UNIX systems I use run Berkeley or Berkeley-derived
>code (e.g., SunOS, Ultrix). Since all BSD-based UNIX systems already
>have full TCP/IP support, there is little reason to run my code on those
>systems.

This explains your recent tirade about running your code on Microport.

Unfortunately, those of us in the real world who don't have access to
BSD (and, to quote Eric Raymond, the "multi-tentacled *thing*" that is
its TTY driver) have to try to get the stuff to run on System V.

A plea:
Please confine your BSD bigotry to one source file, so that those of us
who have to make your code work in the real world won't have to rewrite
the entire package. Please?

--
Jay Maynard, EMT-P, K5ZC, PP-ASEL   | Never ascribe to malice that which can
uucp:        uunet!nuchat!   (eieio)| adequately be explained by stupidity.
{killer,bellcore}!texbell!splut!jay +----------------------------------------
internet: [e-mail]    | "Less great!" "Tastes filling!"

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

End of PACKET-RADIO Digest V89 Issue #146
*****************************************
29-May-89 02:33:18-MDT,2610;000000000000
Return-Path: <[e-mail]>
Date: Mon, 29 May 89 01:30:14 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #147
To: [e-mail]

PACKET-RADIO Digest         Mon, 29 May 89       Volume 89 : Issue 147

Today's Topics:
               A plea (PLEASE!)
----------------------------------------------------------------------

Date: Sun, 28 May 89 13:30:09 EDT
From: [e-mail]
Subject: A plea (PLEASE!)

In answer to <[e-mail]> [e-mail]
(Phil Karn).. Jay Maynard replies.

Phil Karn:
>In article <[e-mail]> [e-mail] (Phil Karn) writes:
>>2. As a matter of personal principle, I avoid all AT&T-based UNIX
>>systems.  All of the UNIX systems I use run Berkeley or Berkeley-derived
>>code (e.g., SunOS, Ultrix). Since all BSD-based UNIX systems already
>>have full TCP/IP support, there is little reason to run my code on those
>>systems.

Jay Maynard:
>This explains your recent tirade about running your code on Microport.

>Unfortunately, those of us in the real world who don't have access to
>BSD (and, to quote Eric Raymond, the "multi-tentacled *thing*" that is
>its TTY driver) have to try to get the stuff to run on System V.

>Please confine your BSD bigotry to one source file, so that those of us
>who have to make your code work in the real world won't have to rewrite
>the entire package.


Mr. Jay Maynard, please give me a break. Try to figure out how to send
email directly, it really isn't all that hard.

(note: This is the condensed version. The original was 2 pages long)

Mark Bitterlich
[e-mail]
wa3jpy@wb4uou

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

Date: (null)
From: (null)

HELP !!! COULD ANYBODY HELP ME WITH A MODIFICATION ON THE PK-80H TNC.

THE PK-80H IS PRETTY OLD AND IS ONLY CAPABLE OF HF OPERATION. IT CAN
ALSO GO ON VHF BUT WITH SOME MODIFICATION. HOWEVER, IT DOES NOT ALLOW
US TO GO BACK TO HF EASILY. THIS IS POSSIBLE ONLY THRU THE CHANGE OF
COMPONENTS AND ALIGNMENT AGAIN.

AS SUCH, I NEED THE HELP OF SOMEONE WHO HAS PERHAPS MADE AN EXTRA
BOARD OR SOMETHING ADDED TO THE TNC, SO THAT WE COULD SWITCH BETWEEN
HF AND VHF EASILY.

THANK YOU VERY MUCH !!!          IAN HENG 9V1XA
                 [e-mail]







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

End of PACKET-RADIO Digest V89 Issue #147
*****************************************
30-May-89 03:10:27-MDT,2869;000000000000
Return-Path: <[e-mail]>
Date: Tue, 30 May 89 01:30:19 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #148
To: [e-mail]

PACKET-RADIO Digest         Tue, 30 May 89       Volume 89 : Issue 148

Today's Topics:
               Connecting the PK-88 TNC
          New Ham, looking for HT, interesting call
             Question on callbook server
----------------------------------------------------------------------

Date: Sun, 28 May 89 07:21 PDT
From: <[e-mail]>
Subject: Connecting the PK-88 TNC

    I recently boughtan AEA PK-88 TNC for my packet station. I have
had tremendous difficulties in making the TNC trigger the transmitter
(YAESU FT-209RH). Can anyone enlighten me as to the proper connection between
the TNC and my HT? I have tried several combinations, but to no avail. Is the
TNC faulty? Receiver connection works perfectly.

Robert L. Morales, WP4BQV
[e-mail]


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

Date: 26 May 89 17:17:46 GMT
From: pitt![e-mail]  (Bob Hoffman)
Subject: New Ham, looking for HT, interesting call

In article <[e-mail]> [e-mail] (Daniel Wynalda) writes:
>... Our company runs it's
>trucks at 463.712Mhz, and I can legally transmit and recieve there because
>of this fact (not on my ham licence).

As others have pointed out, you cannot legally operate a modified ham
HT on non-ham frequencies.

I recommend that you do what I did:  buy an Icom U-16 commercial UHF
HT.  With it, I can work my GMRS repeater on 462.575 and the ham
repeaters on 440 MHz and do it all legally.  It has a scanning mode
that is more like conventional scanners than scanning ham HTs (it has
individual channel lockouts).

A new Icom 04AT costs almost $400 now, I believe. I've seen used U-16s
in the Ham Trader Yellow Sheets for $425.

    ---Bob.

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

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

Date: 29 May 89 20:25:32 GMT
From: vega.ucdavis.edu![e-mail]  (0040;0000001127;0;340;141;)
Subject: Question on callbook server

Recently, I saw a reference to a callbook server on marvin.cs.buffalo.edu.
Could someone give me the info. on accessing it?  Please email, because my
account $$ is dwindiling, and email is less costly than RN access (in terms
of computer-account-funny-money, that is).

Thanks, and 73 de Steve

[e-mail]        n6qgg @ wa6nwe-1

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

End of PACKET-RADIO Digest V89 Issue #148
*****************************************
31-May-89 03:41:48-MDT,5846;000000000000
Return-Path: <[e-mail]>
Date: Wed, 31 May 89 01:30:44 MDT
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #149
To: [e-mail]

PACKET-RADIO Digest         Wed, 31 May 89       Volume 89 : Issue 149

Today's Topics:
              beginners question
                 mfj1278 rom
            NET routing via SLIP (2 msgs)
----------------------------------------------------------------------

Date: 30 May 89 18:05:56 GMT
From: [e-mail]  (Ted Medin)
Subject: beginners question

 Thought i might bdcst some code practice on the hf band(s), i have
a pc that puts out code on the serial port. What do i need to plug into
the key port on my hf rig? Thanks in advance
       Ted
       n6trf

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

Date: 30 May 89 13:45:56 GMT
From: philmtl!philabs!briar.philips.com![e-mail]  (Robert Casey;6282;3.57;$0201)
Subject: mfj1278 rom

copied from packet:
    Subj: MFJ 1278 ROM

     The release that has been tested with NetRom and TheNet by K1LTJ
     and KA1RLX is as follows:

 AX.25 Level 2 Version 2.0 Release 2.3  12/22/88 Checksum $F6

  The listing above is exactly as seen upon boot-up of the 1278. This
  version does have the mailbox but DOES NOT have the <B>ye and <H>elp
  commands within the mailbox. I am assuming that those commands were
  added in a later release of 2.3.

  I have recieved many replies on this and there does seem to be a lot
  of confusion on the different rom versions and release dates of those
  versions.  I hope this helps to clear some of that up.
       73, de KA1RLX @ K1LTJ
                   0302z, 362 msgs, #29413 last
                   @KD6TH-4 MailBox>

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

Date: 30 May 89 16:39:00 GMT
From: cs.utexas.edu!swrinde!dpmizar!dptudg![e-mail]  (Lee Ziegenhals)
Subject: NET routing via SLIP

In article <[e-mail]> [e-mail] (R A Lingelbach) writes:
>I have a desktop computer running KA9Q's NET (v.  890421.1) on packet
>radio, and have a laptop connected to that computer via SLIP.  I have a
>separate IP address for the laptop, and am successful in ftp'ing between
>the two machines.  Is it possible to use IP between the laptop and the
>packet world, going through the desktop computer?

I have been doing just what you describe for quite a while now, and it
works great.  I have my AT running KA9Q full-time with a tnc on 446.1.  I
also have a Macintosh running KA9Q occasionally, and I use a SLIP
connection between the two.  With this setup, I can access all nodes on
the network from either the AT or the Mac.

There are two things that are necessary to make this work.  First, you
must configure your local nodes correctly.  For the desktop (which I believe
you said was the one connected to the tnc), all you need is to include
a route command to send datagrams for the laptop to the SLIP port.  For
the laptop, all you need is a single route command that sends *everything*
over the SLIP port; something like:

    "route add default sl0 [desktop IP address]"

The other thing you need to do is get all of the nodes that talk to you
to configure your laptop in with a route command such as:

    "route add [laptop] <int> [desktop]"

This will cause all datagrams for [laptop] to be routed over interface
<int> to [desktop].  <int> is, of course, the same interface that the
node uses to talk to [desktop].

That's it!  Note that the other nodes do not need to include an additional
ARP entry for the laptop, because they do not talk direct to it.  However,
you might want to include an ARP entry on the desktop machine for the
laptop, so that nodes that have not added you to their route tables might
still be able to find you if they have a "default" port.  Something like:

    "arp publish [laptop] <desktop callsign>"

This tells any ARP requestors to send datagrams for [laptop] to the
callsign of your desktop.

Good luck!

-Lee, n5lyt

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

Date: 30 May 89 03:01:19 GMT
From: portal!cup.portal.com![e-mail]  (R A Lingelbach)
Subject: NET routing via SLIP

I have a desktop computer running KA9Q's NET (v.  890421.1) on packet
radio, and have a laptop connected to that computer via SLIP.  I have a
separate IP address for the laptop, and am successful in ftp'ing between
the two machines.  Is it possible to use IP between the laptop and the
packet world, going through the desktop computer?  I have a "route add
[<laptop IPaddress>] sl0" (sl0 being the slip interface) command in the
desktop's autoexec.net.  I want to send mail from the laptop to IP'ers
on packet, sort of using the desktop as a gateway.  Do I use
"route add....<gateway hostid>" for each address I want to reach?  The
examples in USERMAN.DOC don't seem to help me figure this out.
In case I wanted to run two on-the-air packet stations for IP, I made
the laptop's IP address map to KB6CUN-5 (the desktop is KB6CUN-3) in the
local HOSTS files; I have a feeling this messes up the whole picture
for incoming mail, if I want it to hit the laptop on the SLIP line,
because packets are sent to KB6CUN-5 by other machines, and -3 won't
recognize them to route them via SLIP.
Can anyone give me some clues?  Thanks.

UUCP:         sun!portal!cup.portal.com!roblingelbach
INTERNET:     [e-mail]
AMPRNET:      [e-mail]
PACKET RADIO: kb6cun@k6iyk
-------
Rob Lingelbach
2641 Rinconia Dr
Los Angeles, CA 90068  [phone]

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

End of PACKET-RADIO Digest V89 Issue #149
*****************************************