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

Text File | 1993-12-31 | 199.5 KB | 4,956 lines

1-Mar-89 01:53:35-MST,7090;000000000000
Return-Path: <[e-mail]>
Date: Wed,  1 Mar 89 01:31:22 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #55
To: [e-mail]

PACKET-RADIO Digest         Wed,  1 Mar 89       Volume 89 : Issue  55

Today's Topics:
            AMPRNET population statistics
              Faking a TNC with a modem
            My problems with KA9Q
                 TCP/IP Code
----------------------------------------------------------------------

Date: 28 Feb 89 14:40:30 GMT
From: [e-mail]  (Brian Kantor)
Subject: AMPRNET population statistics

As of Tuesday, Feb 28, 1989, and with a number of regional coordinators
not yet heard from, there are

    2309 hosts
     994 USA hosts
    1315 hosts in 26 other countries
       2 registered space (satellite)

addresses registered in the AMPRNET ( 44.x.y.z ) hosts table and
nameservers.

This is clearly too large a file to distribute on any mailing list or
newsgroup.  Those masochists among you may grab a copy of the nameserver
database by anonymous FTP from host UCSD.EDU in file
    hamradio/AMPR.ORG.890228

It is 2327 lines and 55K long.

    - Brian, WB6CYT (amprnet numbers czar)

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

Date: Tue, 28 Feb 89 23:44:25 EST
From: [e-mail]
Subject: Faking a TNC with a modem

Robert Casey ([e-mail]) writes [...]

>that it is not a reasonable thing to expect to be able to use a modem as
>a substitute for a TNC, even if you just wanted to listen only (I once

And Ben Thornton (uucp:...!cs.utexas.edu!oakhill!val!ben) responds [...]

[  This is simply untrue since one of the building block of a TNC IS a modem.
[In fact, my PK232 has a connector which allows the use of an EXTERNAL modem.
[In ham radio there are no real rules regarding the type of modem usable for
[packet radio other than the limitations imposed on bandwidth.  In fact, packet
[could and SHOULD be a viable medium for experimentation with NEW modem
[technology.  Unfortunately, the proliferation of ready-made TNC's has sort
[of dampened the spirit of hardware innovation in the areas of modems. <sigh>

Aw, come on Ben! The poor guy was just asking if he could take a straight
phone modem and use it to copy packet radio DIRECTLY! Your analogy of a
TNC having a modem is like saying a telephone has a microphone. Yes it does,
but it doesn't work too well hooked to a dipole! As far as packet radio being
a viable medium for experimentation and ready made TNC's dampening innovation
in the area of modems.... well let's see... HAPN has a 4800 baud modem out,
TAPR and K9NG have 9600 baud modems out, and Dale Heatherington has developed
a 56 kbs radio modem. I would call that innovation. I could also point out
the MASSIVE work that is being done to improve speed through better software
by so many different people it would be hard to name them all!

Sorry Ben, I just had to voice my opinion here. Packet radio is growing and
changing so fast it's hard to keep track of it all. And while the "ready made
TNCs" may make it easier to get started for a lot of new people, isn't it
possible that one of them will someday come up with an even bigger break-
through? I don't have time to <sigh>, I'm too excited!  :-)

Mark Bitterlich         packet WA3JPY@WB4UOU
               DDN [e-mail]

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

Date: 1 Mar 89 01:27:02 GMT
From: mailrus!eecae!netnews.upenn.edu!linc.cis.upenn.edu![e-mail]  (Daniel Williams)
Subject: My problems with KA9Q

Dear KA9Q types,

    I'm trying to bring up KA9Q (my first time) on a IBM-PC clone using
a Western Digital WD8003E.  Put as briefly as possible, it appears that
the system can receive IP packets, can send ARP replies but when trying
to send IP packets they are not making it down to the card-level driver.

Here is the version that I am trying to use :

    KA9Q Internet Protocol Package, v871225.25.EW DS = 39cb
    Copyright 1988 by Phil Karn, KA9Q

Here is my autoexec.net :

    attach wd8003e 0x280 7 arpa ec0 5 1500 0xd400
    ip address [192.0.0.4]
    start telnet
    start ftp
    start smtp
    start echo
    start discard

Here is my hosts.net :

    192.0.0.3   iris03
    192.0.0.5   compaq

Here's what happens :

    net> ping iris03 1
    net> ip s
    IP: total 6 runt 0 len err 0 vers err 0 chksum err 0 badproto 0
    ICMP: chksum err 0 no space 0 icmp 6 bdcsts 0
    type  rcvd  sent
    3     0     6       Unreachable
    8     0     6       Echo Request
    net> etherstat
    Controller 0, Ethernet address 00:00:c0:6f:5c:13
    recv      bad       overf     drop      nomem     intrpt
    0         0         0         0         0         0
    xmit      timeout   jam       jam16
    0         0         0         0

See!  The IP level thinks it's sending packets but the driver thinks
differently.  I can RECEIVE packets though :

    net> etherstat
    Controller 0, Ethernet address 00:00:c0:6f:5c:13
    recv      bad       overf     drop      nomem     intrpt
    26        0         0         0         0         26
    xmit      timeout   jam       jam16
    0         0         0         0
    net> ip s
    IP: total 58 runt 0 len err 0 vers err 0 chksum err 0 badproto 0
    ICMP: chksum err 0 no space 0 icmp 28 bdcsts 0
    type  rcvd  sent
    0     0     28      Echo Reply
    3     1     29      Unreachable
    8     28    0       Echo Request
    net> trace ec0 111
    ec0: input output (ASCII dump)
    net>
    ec0 recv:
    Ether: len 98 08:00:14:11:29:61->00:00:c0:6f:5c:13 type IP
    IP: len 84 192.0.0.3->192.0.0.4 ihl 20 ttl 255 prot ICMP
    ICMP: Echo Request id 185 seq 167
    0000  $............................... !"#$%&'()*+,-./01234567

Can someone make any sense of this?  Remember, the system was able to
generate an ARP reply and send that one packet down through the driver.
Please mail to me and I'll summarize if things get fixed in an interesting
way.

Thanks,
Daniel Williams
[e-mail]
rutgers!pracp2!rinc!precis!dan

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

Date: 28 Feb 89 21:11:26 GMT
From: att!whuts!homxb!hotps!ka2qhd![e-mail]  (Dave Pascoe KM3T)
Subject: TCP/IP Code

In would like to get in touch with anyone who knows where I can obtain a copy
of the current TCP/IP code for use on packet.  I would like to get a station se
set up to run TCP/IP.  Please e-mail all replies directly, not on the NET.

Thanks,

Dave Pascoe KM3T/1
csnet:  [e-mail]
uucp:  {harvard,ihnp4}!bunny!vax2.gte.com!pascoe
packet: km3t @ k1ugm
--
DAVE/KM3T   UUCP:rutgers!harvard!bunny!vax2.gte.com!pascoe    PACKET: KM3T@K1UGM

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

End of PACKET-RADIO Digest
******************************
 2-Mar-89 01:50:49-MST,2478;000000000000
Return-Path: <[e-mail]>
Date: Thu,  2 Mar 89 01:30:32 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #56
To: [e-mail]

PACKET-RADIO Digest         Thu,  2 Mar 89       Volume 89 : Issue  56

Today's Topics:
            Amtor > packet gateway
----------------------------------------------------------------------

Date: 28 Feb 89 20:36:28 GMT
From: oliveb!pyramid!prls!philabs!briar.philips.com![e-mail]  (Robert Casey;6282;3.57;$0201)
Subject: Amtor > packet gateway

copied from packet:
 Msg# TSP  Size Read To     @ BBS  From    Date/Time
 25095 BN   2997    2 AMTOR         SM6GXQ 8902/0435
 Subject: Packet-Gateway from AMTOR
       From: SM6GXQ@SM6GXQ ARQ mailbox

       The SK7CS/SM6GXQ mailbox systems has a gateway that works from
       AMTOR to PACKET, but NOT the other way around.

  C+    Connect the "default" node, ie the local NET/ROM.  C
  (hiscall)+      Connect a specific call directly.  C (call) via
  (call)+   Connect using digipeaters.  the <WRU> sign         will
  exit the packet gateway mode. You can also disconnect directly by
 cutting the link...

 The box works a bit differently in the gateway mode. The plus (+) sign
 is no longer valid as changeover:

 - To make a change over to a node (NET/ROM or KA-NODE), use CR-LF at
 the end of the command. Do NOT add any +  or  +? ! The same goes for
 BBS systems!

 - To make a change over to another station you are chatting with, use
 the +? or whatever you see fit. But you should use SOMETHING to tell
the other station that you're finished. (We actually have some problems
here, since the PACKET network is DUPLEX, but the AMTOR one is only
SIMPLEX.)

- Tell the other station you are talking to, to switch over to you,
using +?  or >> , unless you don't want to turn the link around with a
break-in every time... (But the important thing is that you know when
he's done!

freqs:

 3582 3583 3589 7036 14072 14073 14076 21082 21083 28082
 ----------------------------------------------------------------

 SK7CS - SKCS                     SM6GXQ - SGXQ

To comment, please use command: SB AMTOR @ EU   $  on packet
Or directly to SM6GXQ: SP AMTOR @SM6GXQ (with "SM6GXQ" as subject)

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

End of PACKET-RADIO Digest
******************************
 3-Mar-89 01:59:28-MST,1370;000000000000
Return-Path: <[e-mail]>
Date: Fri,  3 Mar 89 01:30:39 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #57
To: [e-mail]

PACKET-RADIO Digest         Fri,  3 Mar 89       Volume 89 : Issue  57

Today's Topics:
             TAPR phone number or person
----------------------------------------------------------------------

Date: 27 Feb 89 16:01:49 GMT
From: mitel!sce!cognos!dgbt![e-mail]  (Barry Mclarnon)
Subject: TAPR phone number or person

From article <[e-mail]>, by [e-mail] (Joe Holman):
>
>       can someone give me a contact (person and phone number)
>       for TAPR, please ?
The number for TAPR is 602-323-1710 (regular office hours).  The office is
manned, oops, personned, by a YL named Cris (actually, I think the "office"
is at her home).  If you have a technical-type question, she'll probably
have to refer you to someone else.

Barry

--
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
******************************
 5-Mar-89 01:53:26-MST,1822;000000000000
Return-Path: <[e-mail]>
Date: Sun,  5 Mar 89 01:30:29 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #58
To: [e-mail]

PACKET-RADIO Digest         Sun,  5 Mar 89       Volume 89 : Issue  58

Today's Topics:
                ham radio BBS
----------------------------------------------------------------------

Date: 5 Mar 89 04:39:51 GMT
From: osu-cis!n8emr![e-mail]  (Gary Sanders)
Subject: ham radio BBS

        HAM BBS online in central Ohio.
        -------------------------------

    HBBS (Ham Bulletin board system), is online at
614-457-4227 (457-HBBS). The system is running on a AT&T 3B1,
under the unix operating system with XBBS bbs software. The system
is online 24hrs a day and will accept 1200/2400 and 19.2k baud,
8 bits no parity, 1 stop bit. High-speed mode is from a telebit
modem and is not HST compatable

    System will be used to support topics of interest to Ham
Radio Operators, Short Wave Listners, scanner listners, tvro users.
Currently there are message and file upload/dowload sections for
general ham radio, packet radio, ka9q tcp software, SWL and scanner.

    There is also readonly access to Unix USENET and to
the FIDO network radio related newsgroups

Gary W. Sanders (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
--
Gary W. Sanders (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
******************************
 6-Mar-89 01:56:44-MST,1269;000000000000
Return-Path: <[e-mail]>
Date: Mon,  6 Mar 89 01:30:36 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #59
To: [e-mail]

PACKET-RADIO Digest         Mon,  6 Mar 89       Volume 89 : Issue  59

Today's Topics:
             KA9Q TCP/IP + Amiga
----------------------------------------------------------------------

Date: 5 Mar 89 07:01:28 GMT
From: mailrus!jarvis.csri.toronto.edu!utgpu!watmath!maytag!watvlsi!watale![e-mail]  (joejobber process)
Subject: KA9Q TCP/IP + Amiga

Does any documentation exist that explains how to configure the Amiga
version of KA9Q TCP/IP?  In particular, I am having great difficulty
trying to figure out what address, and interrupt to specify for the
"attach asy" command.  And I suspect that I will have other problems
as well, since this version is not quite the same as the IBM PC version
for which I do have documentation.

I would be grateful for any pointers.

Thanks,
Barry Kahl ([e-mail], watmath!surya!guest)

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

End of PACKET-RADIO Digest
******************************
 7-Mar-89 02:00:50-MST,1042;000000000000
Return-Path: <[e-mail]>
Date: Tue,  7 Mar 89 01:31:14 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #60
To: [e-mail]

PACKET-RADIO Digest         Tue,  7 Mar 89       Volume 89 : Issue  60

Today's Topics:
            TNC/modem construction
----------------------------------------------------------------------

Date: 6 Mar 89 18:57:03 GMT
From: [e-mail]  (Jeff Bellsey)
Subject: TNC/modem construction

hi!

I am new to this newsgroup, so if this has been discussed recently,
I apologize.

Anyway --- has anyone out there put together a do-it-yerself modem
or TNC (preferably a modem) for a Macintosh?  Or know where to find
plans/schematix for one?  Any help would be appreciated.

Thanks a lot...

Jeff Bellsey

[e-mail]

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

End of PACKET-RADIO Digest
******************************
 8-Mar-89 01:47:36-MST,4161;000000000000
Return-Path: <[e-mail]>
Date: Wed,  8 Mar 89 01:30:24 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #61
To: [e-mail]

PACKET-RADIO Digest         Wed,  8 Mar 89       Volume 89 : Issue  61

Today's Topics:
            KAM vs. PK232 (3 msgs)
            Reference on Various Networks
                  Thank you!
----------------------------------------------------------------------

Date: 7 Mar 89 07:10:00 EST
From: "NJITX::HXN8477" <[e-mail]>
Subject: KAM vs. PK232

Does anybody out there know the difference in capabilities
between the two TNCs: KAM (from Kantronics) and PK232 (from AEA).
I would appreciate it very much hearing about the pros and cons
of each.

    Thanks in Advance

+---------------------------+------------------------------------------------+
|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: 7 Mar 89 15:22:01 GMT
From: elbereth.rutgers.edu!ron.rutgers.edu![e-mail]  (Ron Natalie)
Subject: KAM vs. PK232

The PK-232 TNC part is pretty much just a straight TNC-2 as near as I can
tell.  It is a little more than that because it also includes a
HF Packet, RTTY, AMTOR, FAX, and MORSE send and receive terminal as well.
I've got one.  It's a bit expensive for just a VHF TNC, but is great if
you are going to do HF work.  It has a Radio 1/ Radio 2 switch although
I'll probably buy some cheap TNC for VHF work so I can use both at the
same time.

The PC Pakratt software that runs on an IBM computer is pretty brain
dead (you don't need any software other than a terminal emulator, it's
just a user friendly front end), but I guess it's better than nothing.

-Ron

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

Date: 7 Mar 89 22:51:20 GMT
From: oliveb!amdahl!pacbell!pbhyf![e-mail]  (D. E. Jacobson)
Subject: KAM vs. PK232

One of the big differences between the KAM and the PK232 is that
the newer PK232 units support TCP/IP which the older versions of
PK232 and (as far as I can tell) Kantronics don't.  Thats the
reason I'm leaning toward the PK232.  But I will be reading
with interest, any other responses to this question.

dennis

pacbell!pbhyf!dejac
.

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

Date: 7 Mar 89 17:26:49 GMT
From: [e-mail]  (Kurt A. Geisel)
Subject: Reference on Various Networks

Wanted:

A reference (or references) which explains both the technical
differences between the various networks-over-packet out there
(KA9Q, NET/ROM, TexNet, etc.) and TELLS WHAT THE EXPECTED
USAGE IS IN VARIOUS AREAS.

Book or magazine article.

Any help would be greatly appreciate,

Thanks,

- Kurt

Kurt Geisel                       SNAIL :
Carnegie Mellon University            65 Lambeth Dr.
ARPA : [e-mail]           Pittsburgh, PA 15241
UUCP : uunet!nfsun!kgeisel  "I will not be pushed, filed, indexed, stamped,
BIX  : kgeisel               briefed, debriefed, or numbered!" - The Prisoner

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

Date: Tue, 07 Mar 89 13:38:44 -0500
From: daedalus![e-mail]
Subject: Thank you!

  I'd just like to thank everyone who responded to my request for information
about the Mac and packet radio. I think I'm well connected now, at least
with people, and should be well on my way to joining in actively. I was
very pleased to discover how friendly the people involved with packet
radio are.

-David Kovar

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

End of PACKET-RADIO Digest
******************************
 9-Mar-89 02:24:47-MST,10284;000000000000
Return-Path: <[e-mail]>
Date: Thu,  9 Mar 89 01:30:33 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #62
To: [e-mail]

PACKET-RADIO Digest         Thu,  9 Mar 89       Volume 89 : Issue  62

Today's Topics:
  CBBS v6.0 Packet Radio bulletin board system uploaded to SIMTEL20
                 K4NGC LLBBS
    KA9Q (871225) on Compact or Small Model UNIX (2 msgs)
             KA9Q package on Mac
            KAM vs. PK232 (2 msgs)
----------------------------------------------------------------------

Date: 1 Mar 89 13:49:00 EST
From: "COX ROBERT G" <[e-mail]>
Subject: CBBS v6.0 Packet Radio bulletin board system uploaded to SIMTEL20

The following files have been uploaded to the PD1:<MSDOS.PACKET>
directory at SIMTEL20:

CBBS60EX.ARC    Executables for CBBS Mailbox 6.0 from K3RLI
CBBS60SO.ARC    Source code for CBBS Mailbox 6.0 from K3RLI
CBBS60MA.ARC    Manual for CBBS Mailbox 6.0 from K3RLI

The following is a longer description of the files.

CBBS60EX.ARC, CBBS60SO.ARC, and CBBS60MA.ARC are the executable code,
source code, and manual for Version 6.0 of the CBBS Mailbox, a packet
radio bulletin board system.  (These files are also known as
RUN60.ARC, SRC60.ARC, and MANUAL.ARC in other locations.)  Version 6.0
is an updated version from version 5.2 and corrects a few bugs as well
as adding hierarchical forwarding.  It also includes improved mail
file recovery over version 4.6.  This code is the work of a group of
packet programmers that wish source code to be available for mailbox
code.  Also requires MBBIOS (see MBBIOS32.ARC), RBBIOS, or COMBIOS
(see IO41.ARC and IO41SRC.ARC or later versions, although IO41 may be
outdated) which provide extended COM port support.

The files are all packed with the -oc option from PKPAK.

- Bob Cox ([e-mail])

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

Date: Wed, 8 Mar 89 8:08:35 EST
From: D H Bennett AMCRM-FTM  <[e-mail]>
Subject: K4NGC LLBBS

           K4NGC Land Line Bulletin Board (Packet Radio)
            Network Address: 1:109/211
           Data Telephone Number 1-703-680-5970
             300/1200/2400 Baud Data Transfer

The K4NGC Land Line Bulletin Board (Packet Radio) is proud to announce that
it  now  has an OPUS Network NODE address.  In addition it support standard
OPUS Network Mail and File Requests.  All you have to do is  check  into  a
Network  BBS Node in your own area and request the BBS SYSOP to send a file
request message to this BBS during low telephone calling times and it  will
do  so.  You  will  have  the  file requested the next day.  This is a good
method for obtaining copies of the World Wide Packet Radio Listing for your
area  or  International.  Warning,  you must check with your local SYSOP so
that he does not have to pay for the phone bills.  In addition if you  have
any  changes to Digipeater and Packet Bulletin Boards in your area, and you
want the information added to the World Wide Listing you can  send  Network
Mail  (MATRIX)  to this BBS using your local OPUS BBS.  It also can be sent
during low telephone calling times.  Lastly, two new mail areas  have  been
added  to  the  BBS for Echo Mail.  These are Internation OPUS mail dealing
with subjects of interest.  The two Echo Mail areas added  are  HAMNET  and
PACKET  (Packet Radio).  Any and all Echo Mail world wide entering the OPUS
system will be added to these areas.  And finally, a new download area will
be  added  and  will  be  dedicated  to  OPUS  BBS  Software  and OPUS User
information.

Don Bennett (K4NGC)
15016 Carlsbad Road
Woodbridge, Va 22193
(Home Voice) 703-670-4773
(Work Voice) 703-274-9355/56
(Opus Node)  109/211
(Opus Phone) 1-703-680-5970
(Arpanet) dbennett@amc-hq
(Packet)  K4NGC @ K4NGC
(CompuServe) 72310,263

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

Date: 9 Mar 89 03:44:54 GMT
From: ka9q.bellcore.com![e-mail]  (Phil Karn)
Subject: KA9Q (871225) on Compact or Small Model UNIX

Mark,

I'm surprised to see anybody still working with PDP-11/23s! Well, I don't
know about chopping up the code to fit in 64K of text space, but you might
go through what's there and remove whatever you don't consider absolutely
essential.

You know that PC/XT motherboards are now readily available for less than
$100, don't you? :-)

Phil

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

Date: 7 Mar 89 20:38:30 GMT
From: att!alberta!ncc!adec23![e-mail]  (Mark Salyzyn)
Subject: KA9Q (871225) on Compact or Small Model UNIX

Has anyone managed to get the KA9Q net software to run on `tiny' machines.
My machine is a PDP 11/23 with a split I/D emulator that gives me
64K Code and 48K data space. The problem is the modules alone compile
to a total of 66K Code, that doesn't even include the library support.

I was about to start separating up the code so that when an ftp needs to
run (for example) it exec's the code. But it occured to me, before I
start fingerring out the code, I would like to see if I'm re-inventing the
wheel. Has anyone got any ideas on how I can fit the code into the space,
without loosing too much (wrt features). Phil, if your out there :-),
is it worth the trouble, or is there going to be a major update soon?

I will give the net about 2 weeks to respond before I start cutting things up.

73's de VE6MGS
Cioa,
-- Mark Gregory Salyzyn @ alberta!(edm,ncc,uofaee)!adec23!mark
                or dragos!adec23!mark

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

Date: Wed, 08 Mar 89 15:38:52
From: <[e-mail]>
Subject: KA9Q package on Mac

I have downloaded the files from the SIMTEL server, but cannot get the Mac
version to run; all I get is a window with a partially scrambled prompt line
and the program only responds to CTRL-J (linefeed), not to <CR>. Also, no
command is recognized, all I get after a CTRL-J is a new net> prompt.
This happens both on a Mac II and a Mac Plus. The program also bombs sometimes,
wasn't able to find reproducible conditions. All of the above happens under
Finder and Multifinder. I AM CONFUSED.

Questions: Do any Mac installation guidelines exist?
       What C dialect has this stuff been written in (I guess Lightspeed,
       but I'd prefer MPW)?
       Is the version I downloaded from the RED distribution on Bitnet
       (TRICKLE) one month ago the latest one?
       Can anyone who runs this package on a Mac give my some hints?

Thanks in advance
Joerg

Joerg Langowski, F/DK5LJ, EMBL, F-38042 Grenoble Cedex, France
[e-mail]
GEnie: J.Langowski
Applelink: via D0435 (MacTutor)

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

Date: 8 Mar 89 07:49:09 GMT
From: ka9q.bellcore.com![e-mail]  (Phil Karn)
Subject: KAM vs. PK232

Kantronics claims "TCP/IP" (i.e., KISS TNC) compatibility on all their
TNCs. I have not personally verified this, however.

It is interesting to note that Kantronics was the first manufacturer to
advertise this fact, and AEA quickly followed. Ah, competition... :-)

Phil

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

Date: 8 Mar 89 19:25:16 GMT
From: zodiac![e-mail]  (Andy Cromarty)
Subject: KAM vs. PK232


    Kantronics claims "TCP/IP" (i.e., KISS TNC) compatibility on all their
    TNCs. I have not personally verified this, however.

    It is interesting to note that Kantronics was the first manufacturer to
    advertise this fact, and AEA quickly followed. Ah, competition... :-)

    Phil [KA9Q]


Phil actually saw one running a few days ago in my shack and didn't notice.
I've been running a multiported IP switch for over a year, with a KAM on
one port and a PK-232 on the other.  The PK-232 was considerably less
reliable in this setup.  (I understand that the PK-232's flakiness was
due to a recently corrected firmware bug, however, and that patched ROMs
now are available.  The misbehavior included generating bogus packets
after long periods of unattended operation, which of course is death
for an IP switch and which makes you very unpopular on a congested channel.)
Also, it is possible to set up the KAM so it comes up in KISS mode if
you wish, which is a useful feature if your station is at risk of
encountering occasional power failures while running in unattended mode.

The KAM also is quite a bit more compact than the PK-232, by at least a factor
of two.  My weak impression is that PK-232's are both more widely used and
more heavily discounted. I have used the PK-232 briefly on HF, but not the
KAM, so I'm afraid I can't offer a complete comparison.

Having said that, let me offer an alternative to those of you seeking
a TNC, especially for use with a PC (e.g. in TCP/IP service ).
(Remember, of course, that if you're running Phil's NET program on the PC,
you can use  that hardware and software configuration without modification to
run the AX.25 protocols, e.g. to check into a local BBS to read QSTs if your
locale doesn't support some more rational way of obtaining amateur packet
radio data services.)  The alternative is the plug-in board sold by DRSI
(I believe they're located in Clearwater FL---check any recent ham
magazine for their ad).  Especially if you plan to run two TNCs
simultaneously, this is the hands-down price/performance winner---two
TNCs on a plug-in board for about $80 per TNC!  (N.B. They come two to a
board.)  I've taken my PK-232 out of service and am running a DRSI board
on the PC that serves as the PaloAlto TCP/IP switch, and it's been running
24 hrs/day for a couple weeks now with no problems (except that DoubleDOS
offers less than full performance on the PC because the CPU is busy with
the DRSI board in the current software configuration when it's handling
packets.  I understand this will be fixed soon.)

I'll offer a more detailed review of the DRSI board sometime in the
near future.

    73,                     Andy N6JLJ  <[e-mail]>

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

End of PACKET-RADIO Digest
******************************
10-Mar-89 00:28:45-MST,16725;000000000000
Mail-From: KPETERSEN created at 10-Mar-89 00:25:12
Return-Path: <[e-mail]>
Date: Fri, 10 Mar 89 00:25:11 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #63
To: [e-mail]

PACKET-RADIO Digest         Fri, 10 Mar 89       Volume 89 : Issue  63

Today's Topics:
            KAM vs. PK232 (5 msgs)
           KISS TNC Construction Project. (2 msgs)
               tcp/ip addresses
              vk2sg rtty report
----------------------------------------------------------------------

Date: 9 Mar 89 01:24:56 GMT
From: hpda!hpcupt1![e-mail]  (Brian M. Perkin)
Subject: KAM vs. PK232

Having just bought a PK-232 with intention of receiving RTTY
among other things, it apppears that the KAM is more flexible
and more programmable than the PK-232 for running non-standard
RTTY mark and space frequency splits. I think I bought
the wrong one!
Brian Perkin
hpda!bmp

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

Date: 9 Mar 89 13:36:59 GMT
From: [e-mail]  (Ken Mitchum)
Subject: KAM vs. PK232

>radio data services.)  The alternative is the plug-in board sold by DRSI
>(I believe they're located in Clearwater FL---check any recent ham
>magazine for their ad).  Especially if you plan to run two TNCs
>simultaneously, this is the hands-down price/performance winner---two
>TNCs on a plug-in board for about $80 per TNC!

The Pac-Comm PC100 board is also an option. It is very similar to the DRSI
board - I have used it with a slightly modified "eagle" driver with Phil's
software, and it should also work with a modified "hs" driver and high
speed modem. Pac-Comm does not appear to be advertising this board any
more, probably because it does not come with the TNC software that the DRSI
comes with. It is still available, however, in a variety of configurations,
from bare board on up, and is a real bargain, especiallly if you configure
it without the onboard modems. I have been using one with an external HF
modem (actually an XTU-XT in dumb modem mode) with very good results.

 Ken Mitchum KY3B
 Univ of Pgh
 Decision Systems Labs
 [e-mail]

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

Date: 9 Mar 89 13:58:32 GMT
From: [e-mail]  (Ken Mitchum)
Subject: KAM vs. PK232

>radio data services.)  The alternative is the plug-in board sold by DRSI
>(I believe they're located in Clearwater FL---check any recent ham
>magazine for their ad).  Especially if you plan to run two TNCs
>simultaneously, this is the hands-down price/performance winner---two
>TNCs on a plug-in board for about $80 per TNC!

The Pac-Comm PC100 board is also an option. It is very similar to the DRSI
board - I have used it with a slightly modified "eagle" driver with Phil's
software, and it should also work with a modified "hs" driver and high
speed modem. Pac-Comm does not appear to be advertising this board any
more, probably because it does not come with the TNC software that the DRSI
comes with. It is still available, however, in a variety of configurations,
from bare board on up, and is a real bargain, especiallly if you configure
it without the onboard modems. I have been using one with an external HF
modem (actually an XTU-XT in dumb modem mode) with very good results.

 Ken Mitchum KY3B
 Univ of Pgh
 Decision Systems Labs
 [e-mail]

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

Date: Thu, 9 Mar 89 14:21:20 EST
From: [e-mail]
Subject: KAM vs. PK232

I have read with interest some of the comments being made between the
KAM and PK-232. Without making reference to all the previous comments
(which I know I should... but I'm lazy) I thought that I would add
some of my own.

The KAM does support TCP/IP (KISS MODE) and works very well as previously
reported. However, when this mode is entered most of all the other features
of the KAM are abandoned, so it is rather an expensive way to run full
time TCP/IP.

The KAM has a built in Personal Packet Mail system, that can receive
autoforwarding from "normal" MBL/RLI systems. However if you plan on
using this feature, be sure you get either the RAM backup battery or
the plug in "clock" option (which also keeps the RAM powered up).
Otherwise if you lose power to the KAM, your messages go bye-bye!
It will NOT forward mail to any other BBS's.

The KAM has two SEPARATE modems, one for VHF and one for HF. The HF
modem has been optimized for a maximum bandwidth of 300 baud and uses
switched capacitor filtering for other baud rates. This is superior
to systems that use the same modem for both HF and VHF due to better
bandpass characteristics and increased noise immunity.

Having two separate modems allows the KAM to operate simultaneously
on both HF and VHF. You can leave both rigs hooked up to it at the
same time and monitor packets from both. Only one of the HF modes
can be operated at a time (Morse, ASCII, RTTY, AMTOR, Packet).
If the HF port is in packet mode, the KAM can gateway between VHF
and HF by using both modems.

The KAM has a function called KANODE, that although not a "true"
level 3 emulator such as TheNet or NET/ROM (many more excluded)
does allow a "store and forward" type of operation. I.E. The KAM
receives a packet on either port, and then sends a level-2 ACK
back to the sender. It can then be "commanded" to connect with
someone else, either on the same port (band) or through the other
port (cross band). This is much better than simply "digipeating"
through a cross band setup. Other features in this mode allow you
to call up "nodes heard" (by the KAM) or "stations heard" by the
KAM (it sends the user the MH list)

The HF modem's AFSK tones and demodulator frequencies can be
programmed across a whole range, and this also reprograms the
demodulator tones. This allows for the setting of non-generic
shifts and is a powerful option for a number of other reasons
(SSB filter bandwidth limitations using AFSK keying).

While having a maximum bandwidth of 300 baud allows you to design
a demodulator with better characteristics than one that also works
at 1200 baud, it does present a problem if you want to receive HF
WEFAX. Kantronics got around this problem by using the VHF port for
the reception of HF WEFAX. However now you have to either build a
switchbox or keep switching cables. This mode also does not support
monochrome displays on an IBM clone (using Kantronics software).
All in all, the PK-232 has the KAM beat here (in my mind) since it
also supports different WEFAX modes, and can also TRANSMIT FAX!

The PK-232 also has some nifty RTTY features that allow automatic
shift and baud rate detection along with some bit inversion detection
and correction. (Pretty slick for those that scan the commercial bands)
It also has a LOT of LED's! You can see what is going on a LOT better
with a PK-232 than a KAM. Especially in the AMTOR mode, where it is
handy to know when the units are "phasing", etc. The KAM has LED's but
they are massively multi-purpose on the HF side, and you have to have
a great memory to remember what they mean for each particular mode.

There is a lot more I could cover on both units, but I hope this
at least covers the highlights.

In summation I think the strong points are:

KAM -
2 modems = cross band capable
programmable modem tones
small footprint
continuing upgrades to software on a regular basis (good & bad :-)

PK-232

Superior RTTY modes
Superior LED displays
GREAT manual (BIG!!!)
Large footprint
Superior FAX modes

I own the KAM, and have used the PK-232.   I like Kantronics product
support (they sent me a loaner when I sent my KAM back for warranty
repair!!!!) Both are good units and are better in different areas.
(I am glad we have a choice)

Mark Bitterlich
WA3JPY@WB4UOU
[e-mail]

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

Date: 9 Mar 89 20:53:19 GMT
From: encore!necis![e-mail]  (Rich Bono)
Subject: KAM vs. PK232

In article <[e-mail]>, [e-mail] (D. E. Jacobson) writes:
> One of the big differences between the KAM and the PK232 is that
> the newer PK232 units support TCP/IP which the older versions of
> PK232 and (as far as I can tell) Kantronics don't.  Thats the
> reason I'm leaning toward the PK232.  But I will be reading
> with interest, any other responses to this question.


    Kantronix supports KISS on ALL thier TNC's...

    I own both a KPC-2 and a KAM... they both support KISS,
and allow one to enter/exit KISS simply, without changing jumpers, or ROM's.

    I have been VERY happy with the TNC's... they work.. have many
useful features.. are compatible with software... and DON'T look like they
were thrown together in someones garage/basement workshop!  Plus, Kantronix
is very responsive to users as far as improving their software, and adding
many features.. which they "give" to the users for a little over the cost
of the ROMs themselves..  (ie: ROM update for KAM 27C512, $15)

                Rich, NM1D

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

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

Date: 9 Mar 89 19:20:40 GMT
From: jupiter![e-mail]  (Phil R. Karn)
Subject: KISS TNC Construction Project.

>    How about a KISS only TNC. This would  be a TNC with only the
>Keying, audio and simple control stuff. Should be small and easy
>to build. It would only do KISS so should be easy to get working
>- plug it in and turn it on.

They already exist, in the form of plug-in HDLC adaptor cards for the PC.
Several designs exist: the HAPN board (Intel 8273), the PACCOMM PC-100
(Zilog 8530) and the DRSI PCPA (also 8530).

Since the KISS TNC needs a host computer anyway, the requirement of these
cards for a computer to plug into is no big deal. (I understand that some
people might have Macs instead of PCs. But the Mac already has an 8530
chip, and it could also be programmed to generate HDLC. Then all you need
is an external modem.)

I think the days of the TNC are numbered. It was originally conceived at a
time when personal computers were big, bulky and expensive, and many hams
could not afford much more than a dumb terminal or TTY. Now that PCs
(generically speaking) are cheap and plentiful, it is time to do away with
the TNC in favor of adapting personal computers directly to packet
applications through the use of plug-in adaptors like the HAPN, PC-100 and
PCPA.

Phil

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

Date: 9 Mar 89 05:20:41 GMT
From: texbell!bigtex!helps!bongo![e-mail]  (julian macassey)
Subject: KISS TNC Construction Project.


    There has been some discussion on rec.ham-radio about
construction projects. Here is a super-duper construction project
that 1. would save money and 2. no manufacturer seems to want to
get involved in.

    How about a KISS only TNC. This would  be a TNC with only the
Keying, audio and simple control stuff. Should be small and easy
to build. It would only do KISS so should be easy to get working
- plug it in and turn it on.

    Does anyone out there have a design worked up?

    I talked to Kantronics, AEA and Pac-Comm about this and they
were not interested for a couple of reasons. First it is a small
market. Secondly it would be an under $100.00 product and not
economically viable for them.

    Maybe someone can come up with one and TAPR can sell us PC
boards just like the old days of the TNC-1.

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

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

Date: Thu, 9 Mar 89 09:44 SET
From: Bruno Peticone <[e-mail]>
Subject: tcp/ip addresses

Hi Folks,

     I am still wondering whether the 3rd byte of the ip address
     domain 44.134.x.y is completely avaliable for Italy or not.
     Can anybody in the netland help me to solve the above problem?
     Many thanks,
                     Bruno Peticone
                     IK5FTK - 44.134.5.18

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

Date: 9 Mar 89 02:30:32 GMT
From: osu-cis!n8emr![e-mail]  (Gary Sanders)
Subject: vk2sg rtty report

==============================================================
|               Relayed from packet radio via                |
| N8EMR's Ham BBS, 614-457-4227 (1200/2400/19.2 telebit,8N1) |
==============================================================

RTTY DX NOTES FOR WEEK ENDING 3 MARCH 1989
BID: RTDX0303

FROM REPORTS RECEIVED IT WOULD APPEAR THAT SOME PACKET STATIONS ARE STILL
USING OUT OF DATE SOFTWARE, HENCE THE INCORRECT BIDS APPEARING AT THE
HEADING OF THESE DX NOTES AT TIMES, THEREBY CAUSING DUPLICATIONS IN SOME
BBS'S.  WONDER WHAT ONE CAN DO ABOUT THAT?

IN THE MAIN THE WEEK HAS BEEN INTERESTING WITH SOME NEW DX APPEARING, AND
MORE IS EXPECTED.

THANKS THIS WEEK GO TO TG9VT, W9CD, VE3GU, I5FLN, W1DA, VK2CS, OD5NG AND
VK2EG.


BANDPASS:

FRIDAY:
9J2KF       14099 KHZ  AT  0125Z  QSL
YI1BGD      14098 KHZ  AT  0315Z  QSL
CE0ZIG      14090 KHZ  AT  0540Z
5Z4B        28093 KHZ  AT  2120Z  QSL
DL7ANP/UG6  14080 KHZ  AT  2130Z  NOTE
C31SD       14088 KHZ  AT  2330Z

SATURDAY:
TF3KB       14089 KHZ  AT  0041Z
9J2KF       14099 KHZ  AT  0125Z
ZS1QK       14086 KHZ  AT  0540Z
UM8MU       21088 KHZ  AT  1355Z
YI1BGD      21092 KHZ  AT  1400Z
RT5US       28095 KHZ  AT  1435Z
TF3EJ       28095 KHZ  AT  1430Z
V85RM       28092 KHZ  AT  2345Z

SUNDAY:
TF3KB       14096 KHZ  AT  1500Z
SV1UT       28091 KHZ  AT  1510Z
YI1ACC      28097 KHZ  AT  1715Z  QSL
5B4SF       14090 KHZ  AT  2000Z
9Y4BK       14084 KHZ  AT  2300Z
V85RM       28093 KHZ  AT  2300Z  QSL
HL2AMO      14094 KHZ  AT  2310Z

MONDAY:
TF3LB       28089 KHZ  AT  1340Z
6W6JX       28089 KHZ  AT  1431Z
7P8DR       14074 KHZ  AT  1518Z  FEC/QSL
V85RM       28090 KHZ  AT  2310Z

TUESDAY:
TA3B        14084 KHZ  AT  0010Z
SV9AKD      14094 KHZ  AT  0120Z
UT5RP       14090 KHZ  AT  0345Z
KH6JEB/KH7  14090 KHZ  AT  0550Z  QSL

WEDNESDAY:
K5KH/KP2    14074 KHZ   AT 0100Z FEC
EA8RA       14090 KHZ  AT  0500Z
FG5GI       14089 KHZ  AT  0505Z
UM8MU       21091 KHZ  AT  1405Z
UZ9CWA      28093 KHZ  AT  1435Z

THURSDAY:
KH6JEB/KH7  28080 KHZ  AT  0010Z
TA3C        14090 KHZ  AT  0450Z
FR5ZD       14082 KHZ  AT  0455Z ARQ


QSL INFORMATION:

9J2KF QSL TO JICA, BOX  30027, LUSAKA, ZAMBIA.

YI1BGD SAYS TO QSL TO HIS HOME ADDRESS: AL-KADMIYA, AL-AIMAH BRIDGE,
HOUSE NO.26/4,BAGHDAD, IRAQ. THIS ALSO APPLIES TO YI1ACC.

5Z4BH QSL'S VIA KE3A.

V85RM COLLECTS HIS QSLS FROM BOX 191, MUARA 4001, BRUNEI.

7P8DR QSL ADDRESS IS BOX 562, MASERU, LESOTHO.

KH6JEB/KH7 WILL QSL VIA HIS HOME ADDRESS.

CARDS FRO 3W1A WORKED BY THE U.S. STATIONS SHOULD BE SENT TO WA4FRU WHO IS
THEIR U.S. QSL MANAGER.


NOTES OF INTEREST:

MARCH.

DESECHO.  KP2A/KP5 WILL BE ACTIVE MARCH 1 THROUGH 12TH.

WD4JNS WILL BE ACTIVE FROM 2ND TO 6TH MARCH FROM TURKS AND CAICOS, CALLSIGN
NOT KNOWN AT THIS TIME.

DJ6JC WILL  OPERATE AS TY6JC FROM 25 TH MARCH FOR ABOUT 7DAYS.

ZL1AMO WILL SHOW FROM NORTH COOK ISLANDS FROM THE MIDDLE OF MARCH.


APRIL.

5W1DP WILL OPERATE FROM KH8, A35, ZK1, ZK3 AND ROTUMA DURING THE APRIL TIME
FRAME.

REVILLA GIGEDO, XF4L WILL OPERATE FROM 11TH TO 19TH APRIL.  THEY HOPE TO
OPERATE RTTY AS WELL AS OTHER MODES.  QSL VIA OH2BN.

MARION ISLAND IS EXPECTED TO APPEAR DURING APRIL.  GEAR WAS SUPPLIED BY
W6PQS AND THE SOUTHERN CALIFORNIA RTTY GROUP.


MAY.

ST PETER AND ST PAUL ROCKS.  3RD TO 10 TH MAY, RTTY CALL WILL BE ZY0SY.
OPERATION BY THE NATAL DX GROUP.

JUNE.

TK/HB9CJC WILL OPERATE FROM CORSICA DURING JUNE.  MORE LATER.

AUGUST.

ANGOLA HAS BEEN DELAYED UNTIL AUGUST, DUE TO A CHANGE IN ARMY PERSONEL.
MORE LATER.

GL DE DX1 (VK2SG)

Written by Syd, VK2SG.  Distributed via packet in North America by Tad,
KT7H @ KE7OM.  Thanks to TG9VT and W9CD for AMTOR forwarding.

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

End of PACKET-RADIO Digest
******************************
10-Mar-89 01:31:02-MST,20937;000000000000
Mail-From: KPETERSEN created at 10-Mar-89 01:25:41
Return-Path: <[e-mail]>
Date: Fri, 10 Mar 89 01:25:40 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #64
To: [e-mail]

PACKET-RADIO Digest         Fri, 10 Mar 89       Volume 89 : Issue  64

Today's Topics:
         1989 TAPR meeting notes, part 1 of 2
----------------------------------------------------------------------

Date: Fri, 10 Mar 1989  01:24 MST
From: Keith Petersen <[e-mail]>
Subject: 1989 TAPR meeting notes, part 1 of 2

This is part one of two postings which make up the meeting notes from
the 1989 TAPR annual meeting which was held on Saturday and Sunday
February 25 and 26, 1989, in Tucson, Arizona.

Each posting has cut lines so readers can piece the two together to
recreate the original file, TAPR89.TXT.

---cut-here---PART ONE OF TWO---cut-here---
Blow-by-blow Report of the 1989 TAPR Annual Meeting

by Paul Williamson, KB5MU
from the SANDPAC Newsletter


On Saturday and Sunday February 25 and 26, 1989, the Tucson
Amateur Packet Radio Corporation (TAPR) held their annual
meeting.  Approximately 75 people were in attendance from around
the US, plus one each from Canada and Brazil.  TAPR President
Andy Freeborn, N0CCZ, opened the meeting promptly at 9:00 AM on
Saturday.  He announced the results of the Board of Directors
election.  The following were elected to serve a three-year term
on the Board: Franklin Antonio, N6NKF; Bdale Garbee, N3EUA; Steve
Goode, K9NG; Eric Gustafson, N7CL; and Lyle Johnson, WA7GXD.

A discussion of the possibility of a new Amateur license class
not requiring a Morse Code examination was on the agenda for
Sunday morning.  In preparation for that discussion, N0CCZ took a
poll of those present.  35 were in favor of a codeless license,
13 opposed, 7 uncommitted.

Harold Price, NK6K, served as program chairman for the meeting.
He introduced Phil Karn, KA9Q, who spoke about "Recent
Developments in TCP/IP".

        Phil Karn, KA9Q: TCP/IP

Karn showed a diagram of the Internet protocol hierarchy to
remind the audience of the general structure of the protocols.
Since he has given the introductory talk at previous TAPR
meetings, he gave only a quick overview of the protocols.  He
then showed a very long list of companies that sell or support
TCP/IP-based products, to show that TCP/IP is a widespread de
facto standard.  He then listed the software modules that are
currently a part of the KA9Q TCP/IP implementation:

IP Applications: FTP, Telnet, SMTP, Finger

AX.25 Applications: Mailbox, BBS/Internet Gateway

Protocols: TCP, UDP, IP, ICMP, RIP, NET/ROM, Ethernet, AX.25,
SLIP, AppleTalk

Drivers: drivers for many Ethernet cards

Karn went on to point out that NET's capability to use a NET/ROM
network to carry IP packets is perfectly in keeping with the
Internet concept of tying existing facilities together into a
working network.  However, link layer protocols cannot patch over
physical layer problems.  That is, the radios and modems must be
able to communicate bits from one station to the next reliably
before the protocols, no matter how well designed, can do a good
job.

An industry standard for Ethernet device drivers has been agreed
upon, and Wollongong (a major TCP/IP vendor) has agreed to
release their device drivers to the public domain as they are
converted to the new standard.  The NET software has been
converted to work with the Packet Driver standard, so it can take
advantage of this working base of driver software.  In addition,
drivers already exist for the Eagle board, HAPN (Hamilton Area
Packet Network) board, the DRSI PC-Packet Adapter, and the
Pac-Comm PC-100 board.  KISS TNC firmware exists for almost all
TNC's, including the TAPR TNC-1 and TNC-2, the VADCG board, the
AEA PK-232 and PK-87, and various Kantronics models.

The major work in progress on the KA9Q NET software involves an
extensive rewrite of the internal structure of the software.
Karn has implemented a simple multitasking kernel (referred to as
"NOS") to replace the awkward up-call interface of the existing
software.  It uses lightweight processes and the Berkeley sockets
interface.  The main idea is to make it easier to integrate
applications software with the basic networking software.  Other
work in progress includes automatic routing, possibly including
the experimental SPF protocols currently being tested on NSFNet,
and intelligent host interfaces for use with computers without
plug-in adapters.

Karn has switched compilers from Aztec C to Turbo C version 2.0.
This is good news for many who are interested in making
modifications to the NET software, since Turbo is much less
expensive, more available, and faster than Aztec.

Karn has also been working on various performance enhancements in
the NET package.  The amateur packet environment has unique
problems due to the very low speed of the radio channel, so it
presents an opportunity for original research in protocol design.
Some of the ideas Karn is working on include round trip time
variance estimation, slow start, congestion window thresholding,
and retry timeout clamping.  He is also adding the capability to
fragment IP packets over multiple AX.25 frames, allowing the use
of shorter frames for better performance over poor channels.

        Greg Jones, WD5IVD: TexNet

The next speaker was Greg Jones, WD5IVD, of the Texas Packet
Radio Society, which designed, installed, and operates TexNet.
TexNet is a 9600 bps statewide network running on custom
hardware.  It uses RCA 700 transceivers in the 440 MHz band.
Jones showed a diagram of the network, which currently includes
three links via leased telephone lines.  Linked lines are used as
a stopgap to help build network connectivity, which helps to
build interest in the network in the newly-connected areas.  The
leased lines can then be replaced with amateur radio links.

TexNet includes a Network Management System, which performs
several functions for the network.  The network keepalive
function of the NMS polls each network node every eight minutes.
If any node fails to respond to several consecutive polls, the
NMS issues a reset command to that node.  The poll responses
contain various information about the operational status of the
node, which is used by the Report Collection and Analysis
function of the NMS.  The information is collected into reports,
which are made available on the network PMS message system for
users to download.  The data collection is also used for network
engineering, permitting the network managers to detect and
correct nodes that have failed or have become isolated from the
network.

Some sample network statistics were presented.  In one 14-day
period, the network recorded 674 connections, of which 137 were
to the network Packet Message Systems (there are three), 403 were
connections through the network to another station, and 5 were to
a node's Conference Bridge facility.  (They consider the
Conference Bridge to be underutilized, and are considering making
the conference network-wide to increase interest.)  An average
weekday sees 2 megabytes of data pass through the network; on a
weekend day the figure is 9 megabytes.

Other networks based on the TexNet hardware and software exist in
Oklahoma and Michigan.  Maps of these networks were shown.  The
Texas group currently has 300 members, and supports three active
working groups: the TexNet Support Group, the Texas Networks
Group, and the Mailbox/BBS Group.  They are currently working on
several projects: a protocol converter/gateway to other networks,
such as TCP/IP or NET/ROM; a new version of their weather
information server, required to interface with the National
Weather Service's new distribution system; software enhancements;
and backbone radio improvements.

        Tom Clark, W3IWI: MicroSat

Tom Clark, W3IWI, took the podium to speak about the MicroSat
project.  The first Ariane 4 launch, currently scheduled for July
15, will carry four MicroSats and two UoSATs of similar design.
The MicroSats will be Pacsat/NA (North American packet
satellite), Pacsat/LU (Argentine packet satellite), DOVE (Digital
Orbiting Voice Encoder), and a satellite from Weber State College
containing a CCD video camera.  All of these satellites will
carry a BBS-in-the-sky system for worldwide store and forward
mail and bulletin transmission.  They will ride on a platform
installed atop the top stage of the Ariane 4 rocket, in the
otherwise-unused corners around the base of the primary payload.
This space provides an inexpensive opportunity to launch several
small satellites.

More opportunities to launch small satellites may be afforded by
Pegasus, a commercial rocket plane being developed by American
Technologies.  Pegasus is a solid-fuel rocket with a small wing,
which can be dropped from a B-52 like the X-15 experimental
rocket plane.  Since the solid-fuel rocket has no throttle, the
main way to control the final orbit is by adding ballast to the
payload.  The Pegasus has been configured so that small
satellites can be used for this ballast.  This may provide a
stream of cheap launch opportunities for MicroSats

The satellites are quite small, only 7 inches on a side.  They
are constructed from five modules, which are stacked up and
bolted together to make the satellite's structure.  Each of the
modules has a different function.  The basic four modules contain
the transmitter, receiver, CPU, and power systems.  The fifth
module contains whatever special application is desired, such as
the CCD camera on the Weber satellite.  All six sides of the cube
are covered with solar panels, which together provide an average
of 6 to 8 watts.

This slim power budget forces the design to be very frugal with
power.  YT3MV has designed a transmitter for the MicroSats that
is 80% efficient from DC to RF.  The CPU is a low-power design by
WA7GXD inspired by the PS-186 and based on an NEC V40 processor.
It contains a 2K boot ROM, 256 kilobytes
error-detecting-and-correcting (EDAC) program RAM, and 8
megabytes of static RAM, and consumes approximately 1.5 watts.
The receiver is a high-performance design by W3IWI.  It makes
remarkable use of low-cost commercial components, such as a
Motorola receiver chip designed for cordless telephones and
inexpensive Toko coils from Digikey.  Clark displayed a prototype
receiver in the flight configuration.  Power budget calculations
indicate that the MicroSats will be capable of continuous
operation.

Another innovative cost-reduction feature of the MicroSat design
is the interconnection scheme.  Instead of an elaborate handmade
wiring harness connecting signals every which way (construction
time: 2 months), the MicroSat is connected largely by a single
ribbon cable between the modules (construction time: 20 minutes).
Each modules contains a Motorola 14469 AART chip, which enables
the modules to communicate serially over a miniature local area
network.

Clark then discussed the uplink bandplan of the two Pacsats.
Their uplink passbands are divided into four 16 kHz channels
each, spaced at 20 kHz.  Since the satellite band on 2 meters is
only 140 kHz wide, the highest channel of one satellite coincides
with the lowest channel of the other.  Two different modulation
schemes are planned.  1200 baud Manchester FSK, compatible with
existing Fuji-OSCAR 12 modems, will be used by less sophisticated
stations.  These stations need not track their uplink frequency
according to the satellite's Doppler shift, since the passband of
each channel is wide enough to accommodate Doppler plus the
narrow 1200 baud waveform.  4800 baud FSK, however, requires more
bandwidth, so users of this waveform must precompensate their
uplink frequency to remove the Doppler shift.  It is expected
that this waveform will be used primarily by gateway and mail
forwarding stations.

Clark explained the choice of Manchester FSK at 1200 baud and
straight FSK at 4800 baud.  The use of HDLC on the baseband data
ensures (through bit-stuffing) that the fundamental frequencies
in the baseband data are 75 Hz to 600 Hz for a 1200 baud data
stream.  These frequencies do not pass through a normal SSB
filter.  Manchester encoding amounts to a DSB modulation around a
1200 Hz carrier, shifting the spectrum right into the center of
the SSB filter.  With four times the data rate at 4800 baud, the
baseband frequencies are four times greater: 300 to 2400 Hz.
This is exactly the passband of an SSB filter, so no Manchester
encoding in necessary or desired.

The choice of waveform is made on a per-channel basis under
software control.  The Harris chip used for demodulation provides
an appropriate matched filter for either waveform on command.
This will permit some channels to be operated at 4800 baud for
the use of gateways while others are operated at 1200 baud for
user stations.

Clark responded to several questions from the audience.  Q: Where
are the bar magnets?  A: The satellites are stabilized by four
bar magnets, which are mounted in the corner edges of the
satellite.  The magnets also provide some additional structural
support to the satellite frame.  Q: How does TAPR fit in?  A:
TAPR and AMSAT have a heavy overlap of personnel.  In addition,
TAPR has funded much of the hardware for Pacsat/NA, for a total
contribution of $21,300.  Q: What about thermal considerations?
A: A detailed thermal model shows that everything runs cold.  The
temperature is predicted to be 0 C plus or minus 5 degrees C.
This is a good temperature for the NiCad batteries.

        Jon Bloom, KE3Z: MicroSat Power Module

Jon Bloom, KE3Z, of the ARRL Laboratory, described ARRL Labs
contribution to the MicroSat project.  He has designed the power
module, including the batteries and battery charge regulator.
The solar cells are arranged in clips of 20 cells in series,
providing about 22 volts when illuminated.  The power control
system provides 10V unregulated and 5V and 8.5V regulated to the
rest of the satellite.  The power control system is heavily
instrumented with telemetry sensors.  A clever circuit based on a
saturated toroidal core is used to measure current without
dissipating much power.

        Harold Price, NK6K: MicroSat Software

Harold Price, NK6K, described the MicroSat software design.
Since the processor in MicroSat is a V40-based system, software
development can rely heavily on standard IBM PC compilers and
tools.  MicroSat software is written in assembler and Microsoft
C, linked with Microsoft LINK.  It is then loaded into the
satellite's processor by a cooperative process between the
satellite's bootstrap ROM loader and the ground station PC.

A primary goal of the software design is ease of implementation
for new satellite applications.  A small multitasking operating
system has been implemented, along with an operating system
services library that emulates the standard "stdio" C library
interface.  It provides the application with a disk-like
interface to the 8 MB bulk memory.  This operating system is a
port of QCF, a product developed by NK6K's company and donated to
AMSAT for satellite use.  WB6YMH is implementing all the low
level I/O routines that communicate directly with the satellite's
hardware.  With these facilities, the applications developer need
only program in portable C and link with the provided libraries
to develop satellite software.  This design enables the software
team to be divided between the operating system and applications
developers, which has never been possible in previous amateur
satellite software development efforts.

The software in the satellite is constantly collecting data from
many sensors throughout all the modules of the satellite.  This
telemetry data is transmitted (at low power) on the downlink
whenever the downlink is not otherwise occupied.  It is also
accumulated into files, which are made available to users as
downloadable files.  In the case of the Weber satellite, some of
the CCD pictures will also be made available for downloading.

The satellite is protected against software bugs.  The only
software which is burned into PROM is a small simple bootstrap
loader.  The actual operating software is uploaded (after launch
if necessary) into EDAC RAM, where it is protected against most
radiation upsets by the EDAC circuitry.  A watchdog timer resets
the processor if the CPU fails to kick it periodically.  A
hardware "Fire code" circuit allows a ground station to reset the
satellite's processor even if it is totally crashed.

The satellite is expected to be easy to access.  The downlink
signal should be quite loud, comparable to the signals from the
Space Shuttle SAREX transmissions.  Omnidirectional antennas
should be adequate, except when the satellite is in view of
heavily populated areas.  An FO-12 modem is the only special
hardware needed to communicate with the satellite.

        Jan King, W3GEY: MicroSat

MicroSat program manager Jan King, W3GEY, displayed the MicroSat
chassis that was used for vibration tests.  It was subjected to
15 G's RMS.  He said that all the solar panels  (which were once
believed to be the critical-path items)had been received from the
vendor.  Each satellite has two transmitters; it is possible (but
not currently intended) to operate both at once.  It is yet to be
determined whether the two transmitters will be placed on the
same frequency or two different ones.  The satellite is expected
to have a long service life.  Its lifetime will probably be
limited by radiation damage to the large RAM array.  The
batteries are 6 Ah GE aviation NiCads, which have functioned
flawlessly on UoSAT for over five years. The total materials cost
for a MicroSat is approximately $43,500.

        Dave Toth, VE3GYQ: HF BBS Network

Dave Toth, VE3GYQ, discussed the HF network of coordinated BBS
systems.  This system is designed exclusively for mail
forwarding.  No users are permitted to use the system directly,
and users are discouraged from transmitting on the network
frequencies.  Several frequencies on various bands are used,
depending on propagation and the required range.  40 meters is
used for intrastate forwarding, 20 meters for interstate
forwarding, and 15 meters for intercontinental forwarding.  30
meters is also used, sometimes in night/day alternation with 10
meters.  Each frequency has an assigned manager, and Toth
provides central coordination for all frequencies.

The network has several deficiencies.  It has low throughput, due
to low data rate and difficult conditions on HF.  It is subject
to the vagaries of HF propagation.  And, it is subject to the
hazard of new or inconsiderate packet operators.  They sometimes
operate on the network frequencies, causing drastic reductions in
network throughput.

In December 1988, the HF network experienced a congestion
collapse.  Throughput remained near zero for several days.  It is
believed that the problem was caused by network operators raising
the retry limit in response to poor conditions.  As more and more
stations retried more and more times, the network approached a
state in which the channel was saturated with retransmissions.
When all stations backed off the retry limit to the original
value and held back mail transmissions for a few days, the
network returned to normal operation.

The HF network plans to test a variation on the AX.25 protocol
called "prioritized ACK".  The idea of this scheme is to give
acknowledgments effective priority on the channel over other
transmissions.  This is thought to reduce the performance
degradation due to the hidden terminal problem.  Suppose station
A is transmitting to station B, and station C has a packet for
station D that it is ready to transmit.  Station C hears station
A, so it is waiting for the end of A's transmission.  In AX.25
Version 2.0, station C would transmit its data as soon as A's
transmission ended (allowing for DWAIT and possibly random
backoff time).  In the prioritized ACK version, station C is
required to wait long enough for station B to send a RR frame to
station A before transmitting.  This permits the RR from B to
arrive at A without collision, even if C cannot hear B.  The HF
network will attempt to determine if this modification actually
leads to increased throughput.

---cut-here---END PART ONE OF TWO---cut-here---

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

End of PACKET-RADIO Digest
******************************
10-Mar-89 02:04:17-MST,21013;000000000000
Mail-From: KPETERSEN created at 10-Mar-89 02:00:33
Return-Path: <[e-mail]>
Date: Fri, 10 Mar 89 02:00:32 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #65
To: [e-mail]

PACKET-RADIO Digest         Fri, 10 Mar 89       Volume 89 : Issue  65

Today's Topics:
         1989 TAPR meeting notes, part 2 of 2
----------------------------------------------------------------------

Date: Fri, 10 Mar 1989  01:59 MST
From: Keith Petersen <[e-mail]>
Subject: 1989 TAPR meeting notes, part 2 of 2

This is part two of two postings which make up the meeting notes from
the 1989 TAPR annual meeting which was held on Saturday and Sunday
February 25 and 26, 1989, in Tucson, Arizona.

Each posting has cut lines so readers can piece the two together to
recreate the original file, TAPR89.TXT.

---cut-here---PART TWO OF TWO---cut-here---
        Mike Lamb, N7ML: No-Code License

After lunch, Mike Lamb, N7ML, of AEA spoke about the code-free license
proposal.  Lamb is on the ARRL committee to study the possibility
of proposing a no-code license to the FCC.  He pointed out that
the early days of packet radio were marked by not only technical
accomplishments, but also impressive salesmanship by the likes of
Pete Eaton.  He asked if TAPR members would be willing to act as
salesmen for a no-code proposal; 15 to 20 hands were raised.
Lamb pointed out that six MHz of spectrum at 800 MHz was
estimated by the FCC to be worth $1,200,000,000, and that the
amateur UHF-and-up spectrum is extremely valuable to commercial
interests.  He stated that bands like 902-928 MHz will be as
important to the Amateur Radio Service in a few years as 144-148
MHz is now, and that we should seek to populate these bands now
to avoid losing them to commercial interests.

        Bdale Garbee, N3EUA: N6GN 1200 MHz Transverter

Bdale Garbee, N3EUA, had several projects to discuss.  The WA4DSY
56 kbps modems have a 28 MHz IF interface, and thus require a
transverter to 220 MHz or higher.  These transverters are quite
expensive and not very available.  Also, spectrum space on 220
and 450 MHz is scarce.  To solve this problem, N6GN is working on
a transverter from 28 MHz to 1200 MHz for use with the DSY
modems.  Spectrum is still available on 1200 MHz, omnidirectional
antennas are practical, and Japanese RF building blocks are
available inexpensively.  The design can also be used at 900 MHz.
The N6GN design, which is currently in prototype, provides 1 watt
or 18 watts if a final Mitsubishi brick is installed.  It has
either a 28 MHz or a 144 MHz IF, permitting use with the DSY
modems or with a 2m satellite station.  It provides fast T/R
switching using PIN diodes, and can be run full duplex by
splitting the LO.  The materials cost is estimated at $150 to
$200.  Garbee asks that potential users of this design contact
him with comments.

        Bdale Garbee, N3EUA: Microwave Ethernet

Garbee is also working on a project to use 10 GHz or 24 GHz Gunn
diode transceivers designed for police radar applications to
transmit very high speed data.  He uses standard Ethernet
transceiver chips with the clock oscillator modified to produce
2.4 Mbps instead of the usual 10 Mbps.  The reduced rate is
necessary to permit use of a Motorola FSK demodulator chip on the
receive side.  He has a prototype working on the bench at 2.4
Mbps.  Operational concerns include stability over temperature
and the validity of current path performance predictions.  Garbee
estimates that a 2 Mbps half-duplex system can be built for
around $200, plus the cost of the computer and Ethernet interface
card.

        Bdale Garbee, N3EUA: KA9Q NET Release

Garbee is also handling the release of KA9Q's NET software.  One
final release of the current (122587.33 derived) software is
planned before the initial release of KA9Q's new NOS NET.  This
last release will contain many changes submitted by many
individuals.  Garbee has been receiving about 100 electronic mail
messages per day, about one third of which contain code
fragments.  Several HP and Apollo technical writers have
volunteered to update and enhance the user documentation for the
package.  Garbee was unwilling to commit to a schedule for the
release, but admitted that late March was a possibility.

        Mike Chepponis, K3MC: Awesome I/O Board

Mike Chepponis, K3MC, described his development of the "Awesome
I/O Board".  The board is a smart I/O controller designed to plug
into a slot on an IBM PC or AT computer.  It contains an 85C30
serial communications controller chip, connected by four DMA
channels to an onboard NEC V40 processor running at 8 MHz.  The
85C30 provides two full-duplex channels.  The V40 shares 8K or
32K of dual-ported RAM with the host PC via the 8-bit XT bus.
Chepponis displayed a wirewrap "not quite working" prototype
board.

Chepponis described two other configurations for similar designs.
In one, the V40 stood alone with its own ROM and RAM, and was
connected to multiple 85C30 SCC's.  One SCC was connected for DMA
and used for a high-speed channel, and the others were connected
for interrupt-driven I/O and used for low and medium speed
channels.  In a second configuration, a stand-alone V40 was
connected to a single 85C30 for DMA.  One channel of the V40 is
used for high-speed communications, and the other channel is
connected to a Macintosh host computer's Appletalk network port.

Chepponis listed a few of the applications he envisions for high
data rate packet radio.  At 56 kbps, "instant" mail delivery, six
TDM digital voice signals, FAX at less than 10 seconds per page,
digital SSTV, and multiperson realtime interactive services such
as remote schematic drawing become possible.  At 2.0 Mbps, file
servers, compressed fast scan TV, 200 TDM digital voice signals,
and various picture formats (even animated) are possible.

Chepponis compared the cost of a conventional 1200 bps packet
station ($1000) to that of a 56 kbps packet station using his I/O
board ($1700).  In terms of bits/second/dollar, the 56 kbps
station is about 25 times more cost effective.

        Phil Karn, KA9Q: WA4DSY 56 kbps Modem

Phil Karn, KA9Q, took the podium again to discuss the design of
the WA4DSY 56 kbps modem.  He stated that this modem is not
well-known in the amateur community.  He has a network of three
DSY modems working on 220 MHz in northern New Jersey.  The DSY
modem uses a modified form of MSK (minimum shift keying).  In
terms of phasor diagrams, MSK can be understood as a vector that
rotates 90 degrees every bit time, at a constant amplitude and
phase velocity.  Thus, it traces out the unit circle on the
phasor diagram.  This modulation scheme has a constant envelope,
but a wide spectrum.  The DSY modem achieves a narrower spectrum
by having the phasor cut the corners of the unit circle, tracing
out a diamond on the phasor diagram.  This results in sinusoidal
phase velocity, and a non-constant envelope.  The DSY modem
generates a signal about 74 kHz wide at 56 kbps, or plus and
minus 14 kHz deviation.

The DSY modem consists of three circuit boards, available from
GRAPES.  The Transmit Encoder board contains a clock generator,
data scrambler (to remove any low-frequency or DC components from
the data), and a state machine waveform lookup table driving two
DACs.  The DAC outputs form the I and Q channel signals, which
are lowpass filtered and passed to the Modem board.  The
modulator consists of a standard I/Q modulator with a 0 dBm 28
MHz output and a receive chain based on a Motorola 3357 FM IF
chip with a crystal controlled LO.  The analog baseband data is
sent to the Receive Decoder board, where a slicer and descrambler
recovers the data and a PLL recovers the clock.

Karn stated that he is a big fan of the DSY modem.  He beleives
that the user stations should be operating at least 56 kbps.  The
channel access problem is critical.  He recommends crossband full
duplex operation, so that collisions may be detected and aborted.

        Dan Morrison, KV7B: Modem Comparison

Dan Morrison, KV7B, described his experiments in collaboration
with Eric Gustafson, N7CL, comparing a phase detection
demodulator for FSK with a simple filter demodulator.  Their goal
is to better understand how HF packet works and how to improve
performance of HF modems.  They used a Kenwood TS-440S and a
Dalanco Spry DSP board together with a beta-test DSP signal
analysis software package running on a PC.  They used the DSP
software to simulate the two demodulators.

Morrison showed several graphs of power versus frequency that
show a discrepancy between the theoretical power spectrum for
random data and the spectrum of actual packet data.  The actual
spectrum shows an additional peak in the center of the main lobe,
which Morrison attributes to the HDLC bit stuffing.

Morrison modeled a naive discriminator, having a linear response
over the frequency range of interest.  This demod performed very
poorly.  Then he modeled a filter demod, whose graph resembles
that of the discriminator to some extent.  Integrating the
frequency response of the filter demod results in a curve that
matches the spectrum of the signal fairly well; a perfect match
would imply an optimal demodulator.  This demod generates good
eye patterns.  Next, he added limiters to the filter demod.
Filters have a reputation as the bane of HF demodulator
performance.  It still generated good eye patterns.  He then
added noise, and still got good eye patterns.  He concludes that
the filter demod works just about as well as the phase detection
demod as long as the signal is bandlimited before the
demodulator.

Morrison presented a graph of a signal before and during a severe
multipath fade.  The attenuation of one tone was clearly visible.
These signals were demodulated, and both demods did well as long
as the envelope of the signal was above the noise level.  A
member of the audience asked "why not demodulate just one tone?",
and Morrison replied "That won't work very well.  What if the
multipath fade took out the tone you were demodulating?".  Tom
Clark, W3IWI, stated that the conceptual model of "tones" was a
poor one for modulations with bit rates about as big as the
shift.  Perhaps the incidental amplitude modulation caused by
selective fading could be used by a sufficiently smart
demodulator.

Morrison then presented graphs of eye patterns for a very noisy
signal received with a 2.4 kHz SSB filter.  This generated a
hopelessly bad eye pattern on the phase demod, and a pretty good
eye pattern on the filter demod.  This is a result of the
narrower frequency response of the filter demod.  Narrowing the
input filtering to the phase demod to 500 Hz produced similar
performance to that of the filter demod.  Morrison concluded that
a well-designed filter demod works very much like an ideal
noncoherent demodulator.  Either modem needs a narrow bandpass
filter before its first nonlinear stage for good performance.

A member of the audience asked if increasing the shift from 200
Hz to 600 Hz would help performance.  His intuition was that it
would.  Morrison stated that it would not, and Clark agreed.
Both had run experiments verifying their conclusions.

        Eric Gustafson, N7CL: TAPR Hardware Projects

Eric Gustafson, N7CL, described three new developments from
TAPR's hardware designers.  Two of them are tiny circuit boards
designed to improve the DCD performance of a TNC's demodulator.
These circuits were described in the last Networking Conference
proceedings.  One is for a TNC-2, and the other is for AM7910
based modems.  The other new development is a hardware upgrade
path for TNC-1 owners.  This board piggybacks on the TNC-1 board
and permits the TNC-1 to run TNC-2 firmware.  This allows TNC-1
owners to keep up with the evolution of TNC firmware, even though
TNC-1 firmware updates have not appeared.  None of these items
are priced or available yet.

Gustafson described the prioritized ACK proposed modification to
the AX.25 Level 2 protocol.  He stated that code implementing
this version of the protocol for TNC-2 will be available for
testing on TOMCAT and CompuServe soon.  The code is based on TAPR
version 1.1.6.

        Jim Vogler, WA7CJO: 10 GHz EME

Jim Vogler, WA7CJO, was introduced by coworker Tom Clark, W3IWI.
Vogler was the first to succeed at 10 GHz EME.  He showed us
pictures of his EME station.  He has a 15' dish with a moving
mass of one ton and a half-power beamwidth of 0.5 degrees.  He
points the antenna at the moon by listening for the noise
reflected from it at 10 GHz, and tracks by means of a video
camera mounted on the edge of the dish.  He can control antenna
pointing to 30 seconds of arc, and frequency to a few hundred
Hertz.  He uses a surplus 100W TWT amplifier with a scalar ring
feed for about 20 MW EIRP.  The TWT beam was defocused, so he
used permanent magnets to refocus the beam.  He was able to hear
his echoes from the moon with 15-20 dB S/N.

Vogler said a few words about the problems of creating a power
amplifier for 1.2 MHz and up.  Transistors for 20W at 1.2 GHz are
$50 and falling.  Amplifiers can be built, but commercial ones
are very costly.  Kits can be a problem, since considerable test
equipment is required to align the amplifier, and mistakes that
destroy the device are costly.

        Jon Bloom, KE3Z: ARRL and Packet

The STA authorizing automatic control of certain stations on HF
has been renewed for another year.  The League hopes to have a
permanent rules change in place by the time it expires.  The
Digital Committee and Membership Services Committee will examine
the results of the testing and propose new rules.

ARRL has established a Technology Grants program, whereby
developers of amateur radio technology can apply for funding from
the League.  This is partially a result of Paul Rinaldo, W4RI,
pushing for improved HF modems and protocols.

Expect a MicroSat article in an upcoming issue of QST.

TNC's are being integrated with the SAREX transceivers in
anticipation of the next ham in space, schedule for STS-35 in
spring of 1990.  The request for prioritization has been
submitted to NASA HQ for the experiment.

        TAPR Business Meeting

President Andy Freeborn, N0CCZ, resumed the chair and conducted
the annual business meeting.  He gave a summary of the year's
activities.  The office complex was closed, and Chris the office
manager now operates the TAPR office from her home.  TAPR had no
booth at Dayton '88, but has requested a double booth in the new
wing for Dayton '89.  A rewrite of the TAPR Bylaws is in
progress.  The DSP Project is now an official joint project of
TAPR and AMSAT.  The two organizations will share the risks and
benefits fully.  Two AT-type computers outfitted for CAD work
were purchased to support hardware design efforts.  They are
presently in use in Tucson and St. Louis.  TAPR has contributed
$21,300 for Pacsat/NA hardware, and is serving as the procuring
agency for all Pacsat hardware purchases.

PSR Editor Scott Loftesness, W3VS, has announced his intention to
retire at the end of the calendar year.  A new volunteer is
sought.  TNC-2 licensing fee income will be ending soon.  A new
project is necessary to provide a source of income.  The Board
has been in continuous session via CompuServe HamNet during the
year; nine votes were taken during that time.  An income
statement and balance sheet were presented.  With an income of
about $61000, the total assets and liabilities of the
organization are $122,500.

A question and answer period followed.  One member stated that
the Board should keep the membership better informed about its
day to day activities, and there was general agreement.  A member
asked about the status of the DSP project.  W3IWI answered that
Bob McGwier, N4HY, has been writing software for the Dalanco-Spry
development system, including several new demodulators.  Since
there is no prototype hardware in the final configuration yet, he
has not begun porting the software to the target system.  W3IWI
guessed that late summer would be earliest possible availability.
The V40 hardware has been designed, but layout has not begun.
The other boards are being fabricated in a prototype version.
They have had problems finding satisfactory CAD software for PWB
layout.  There may be a problem with the V40 chip and interrupts.
It appears that TAPR is standardizing on the V40; this is
important so that we can build up a base of knowledge about its
quirks.  The DSP Project is personnel-limited; more qualified
volunteers would be welcome.

Another member asked if the DSP Project was the only new
development under way.  Freeborn answered that there was another
project in the early design stages: a 9600 baud VHF radio/modem.
This project was mentioned briefly in PSR.  TAPR is wary of
announcing products before they become real, so they try not to
make a lot of noise about a project this early in the design
phase.

Pete Eaton, WB9FLW, led the membership in thanking Andy Freeborn,
N0CCZ, for his outstanding efforts in the past year in
reorganizing the organization.  Applause.

The meeting was adjourned for the day at 5:15 PM.

An additional session was held on Sunday morning, with a single
agenda item:  the no-code license proposal.  Harold Price, NK6K,
led the discussion.  He has been charged, along with other
committee members, with creating a concrete proposal of some sort
to provide to the ARRL committee.  The discussion proceeded in
stages: opening remarks, purposes, and specifics.  An appropriate
background was provided by sounds of hymn-singing from the church
service being held next door.

Your reporter will not attempt to reproduce all the arguments
presented in this 3-hour discussion.  Though the discussion
remained intelligent and civil for the most part, there were
diverging opinions.    The following represents an attempt to
summarize the semi-consensus that evolved during the meeting.

TAPR's purpose in getting involved in the issue in the first
place is to help the ARRL to lead the amateur community to accept
some proposal.  Last time no-code came up, the proposal was
violently opposed by a large fraction of the community.  The
ARRL, being a political organization, will be reluctant to
reverse this position unless it believes there is significant
support for the proposal in the community.  By presenting a
workable proposal and standing behind it, TAPR may be able to
encourage ARRL leadership to try again.

Our purpose in seeking a license that does not require Morse Code
proficiency is threefold:

1. To ensure that crucial spectrum allocations in VHF and up are
utilized and remain available to the Amateur Radio Service,

2. To lure more technically competent people into Amateur Radio, and

3. To lure more young people into Amateur Radio to ensure the future
of the Service.

The specific proposal should have the following characteristics:

o       The existing licensing structure remains as it is.  No privileges
will be given to or taken from any existing licensee.  To do so
would be to invite controversy.

o       An addition licensing structure consisting of two license classes
would be added.  These classes would grant operating privileges
above 30 MHz only.  One license would be fairly easy to obtain,
with a written exam similar in difficulty to the Technician exam.
This license would have very limited privileges.  The licensee
might be prohibited from controlling repeaters, homebrewing
transmitters, or operating high power; and/or the license could
be made nonrenewable.  The license would be limited to selected
bands or subbands.  The other license would be difficult to
obtain, with a written exam more difficult than any now in use.
This license would have full amateur privileges above 30 MHz.

The group was unable to agree on the specifics of the
restrictions to be placed on the beginning license class, or even
on an appropriate name for it, in the time available.  The
Board's committee is charged with fleshing out the proposal based
on the opinions stated during the meeting.  At the end of the
discussion, Freeborn asked how many opinions had been changed by
the arguments.  Several people in the anti-no-code and
uncommitted camps admitted to being swayed toward no-code by the
arguments they had heard.

The TAPR Annual Meeting was adjourned at 12:28 PM.
---cut-here---END OF PART TWO OF TWO---cut-here---

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

End of PACKET-RADIO Digest
******************************
11-Mar-89 01:59:35-MST,11437;000000000000
Return-Path: <[e-mail]>
Date: Sat, 11 Mar 89 01:30:23 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #66
To: [e-mail]

PACKET-RADIO Digest         Sat, 11 Mar 89       Volume 89 : Issue  66

Today's Topics:
              callsign database
           Headend Frequency Translators and packet
         KA9Q (871225) on Compact or Small Model UNIX
            KAM vs. PK232 (2 msgs)
            KISS TNC Construction Project.
         Rusty's callsign info goes to work! (2 msgs)
              Want old CP/M TCP/IP code.
----------------------------------------------------------------------

Date: 10 Mar 89 18:05:52 GMT
From: agate!helios.ee.lbl.gov!ncis.llnl.gov![e-mail]  (Tim Tessin)
Subject: callsign database

In article <[e-mail]>, [e-mail] (Patty Winter) writes:
>
> Doug Thom, N6OYU, has combined Phil Karn's TCP/IP code and Rusty
> Carruth's callsign data to create a wonderful new service for
> both TCP and AX.25 users here on the Peninsula.

Does anyone have the callbook on-line for internet users?
I could provide the machine and the disk space if someone could provide
the database itself.  I can provide probably 30-50 mb for the database.
Access can be by anonymous ftp or other service.

Tim Tessin - AA6EY
PHONE: [phone]
ARPA:  [e-mail]
UUCP:  {ames,lll-crg,lll-lcc,mordor}!lll-tis!tjt

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

Date: 10 Mar 89 17:13:29 GMT
From: orion.cf.uci.edu!uci-ics!venera.isi.edu!aero!trwind![e-mail]  (Bill Gunshannon)
Subject: Headend Frequency Translators and packet

I have what may be a simple question but one for which I have not
been able to come up with a suitable answer.

Other than possibly regulatory reasons (which can be fixed) are
there any technical reasons why we can't run linear translators
for packet much the same as the Headend Re-Modulators used on most
broadband LANs?  I would think this has the potential to eliminate
the "hidden xmitter" problem and even make real CD available to add
to our current CSMA scheme.

OK, I've got my NOMEX underwear on, let me see the error of my ways.

bill gunshannon
KB3YV @ K3RLI
[e-mail]

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

Date: 10 Mar 89 17:04:12 GMT
From: orion.cf.uci.edu!uci-ics!venera.isi.edu!aero!trwind![e-mail]  (Bill Gunshannon)
Subject: KA9Q (871225) on Compact or Small Model UNIX

In article <[e-mail]>, [e-mail] (Phil Karn) writes:
>
> Mark,
>
> I'm surprised to see anybody still working with PDP-11/23s! Well, I don't
> know about chopping up the code to fit in 64K of text space, but you might
> go through what's there and remove whatever you don't consider absolutely
> essential.
>
> You know that PC/XT motherboards are now readily available for less than
> $100, don't you? :-)
>
> Phil


I've got a bunch of LSI 11-03s.

Got any suggestions for them??  :-)


bill gunshannon
KB3YV

[e-mail]

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

Date: 9 Mar 89 23:09:37 GMT
From: aero!trwind![e-mail]  (Bill Gunshannon)
Subject: KAM vs. PK232

In article <[e-mail]>, [e-mail] (D. E. Jacobson) writes:
> One of the big differences between the KAM and the PK232 is that
> the newer PK232 units support TCP/IP which the older versions of
> PK232 and (as far as I can tell) Kantronics don't.  Thats the
> reason I'm leaning toward the PK232.  But I will be reading
> with interest, any other responses to this question.
>
> dennis
>
> pacbell!pbhyf!dejac
> .


Just a minor correction.

The KAM does have KISS in it for running TCPIP.

They have supported in their products for quite some time now and I believe
they were probably the first commercial available TNC with KISS included.

I have used both the KAM and a KPC2 for TCPIP and am pleased with the results
from both of them.
As a means of comparison I also have TNC2 with the KISS only ROM in it and
performance is just as good on the Kantronics boxes.

Hope this info helps someone to get on TCPIP.

73's
bill KB3YV

#include <std.disclaimer>

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

Date: 9 Mar 89 18:42:00 GMT
From: uxg.cso.uiuc.edu![e-mail]
Subject: KAM vs. PK232

> Does anybody out there know the difference in capabilities
> between the two TNCs: KAM (from Kantronics) and PK232 (from AEA).
> I would appreciate it very much hearing about the pros and cons
> of each.

I'd like to hear about anyone interfacing either of these two TNC's to
a Kenwood TS-440 using the digital connection in the rear.  I get the
impression from reading PK-232 documentation (hard to read) and the
TS-440 manual, that the signal/voltage levels are radically different?
I don't know this detail on the KAM or other Kantronics TNC's which I
am leaning towards at the moment.

--phil ka9gwn--

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

Date: 10 Mar 89 06:24:20 GMT
From: shelby!lindy![e-mail]  (Kevin J. Burnett)
Subject: KISS TNC Construction Project.

In article <[e-mail]> [e-mail] (Phil R. Karn) writes:
->>    How about a KISS only TNC. This would  be a TNC with only the
->>Keying, audio and simple control stuff. Should be small and easy
->>to build. It would only do KISS so should be easy to get working
->>- plug it in and turn it on.
->
->They already exist, in the form of plug-in HDLC adaptor cards for the PC.
->Several designs exist: the HAPN board (Intel 8273), the PACCOMM PC-100
->(Zilog 8530) and the DRSI PCPA (also 8530).

These boards aren't very useful for people (like me) who own a Macintosh
or Atari ST or Amiga, i.e. anything other than an IBM PC.  I think a
generic KISS TNC with an RS-232 connector would be great..
--
Kevin Burnett, KC6AOA/AG                AMPR.ORG: 44.4.0.231
"She was an acrobat's daughter, she swung from a noose by her teeth;
 but then one day, her dentures gate way, and she flew through the air
 like a goose."

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

Date: 10 Mar 89 14:14:04 GMT
From: encore!necis![e-mail]  (Rich Bono)
Subject: Rusty's callsign info goes to work!

In article <[e-mail]>, [e-mail] (Patty Winter) writes:
>
> Doug Thom, N6OYU, has combined Phil Karn's TCP/IP code and Rusty
> Carruth's callsign data to create a wonderful new service for
> both TCP and AX.25 users here on the Peninsula.
>
    [ much deleted]

    Rusty's hard work also paid off for packet users in the
southern New Hampshire area... about 3 days after I had my copy of the database
I had ONLINE a 'callbook' server.

    Packet users connect to DOSGATE (NM1D-2 145.07) and issue the command
AUTOCALL NM1D, they are returned a listing similar to that which is in the
call book...

    This service has been very popular... several users have told me
it is easier to use than their own hard copy callbook.

    DOSGATE is usable via standard (AX25) packet, and also has many other
features, such as SEESATS (real time satelite tracking), AUTOEXAM (online
amateur exams from Novice to Extra - contains the complete question pools,
generates a different exam each time),  games, online repeater directory,
simple email, and other various stuff.

    Our local repeater club (the Interstate Repeater Society aka: IRS)
has started the IRS Information System (IRSIS) using DOSGATE.

    Items like the callbook project put a lot of fun and excitement back
into HAM radio!  Who said all newcomers are appliance operators, some have
evolved into SYSTEM BUILDERS!!   (thanks for all the hard work Rusty).


                Rich, NM1D


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

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

Date: 10 Mar 89 08:01:21 GMT
From: [e-mail]  (Patty Winter)
Subject: Rusty's callsign info goes to work!

Doug Thom, N6OYU, has combined Phil Karn's TCP/IP code and Rusty
Carruth's callsign data to create a wonderful new service for
both TCP and AX.25 users here on the Peninsula.

First, he put the callsign info onto a hard disk (a *large* hard
disk!) connected to an AppleShare file server on his AppleTalk
network. Then he had to find a way for remote packet users to access
the info through his Macintosh TCP/IP host. Here (from a presentation
he recently made to the Pacific Packet Radio Society) is a description
of how this was accomplished:

    The only task remaining was to provide access to this
    info easily and quickly over Packet Radio. TCP/IP was
    chosen, for two important reasons. First, because I
    have a station already running TCP/IP, and second, there
    is already a command protocol to get simple text information
    from a TCP/IP node...namely the Finger command.

    Dewayne Hendricks (WA8DZP) graciously offered to add the
    necessary code to the KA9Q package. With the addition of
    one minor syntax change to the finger command, it is now
    easy for anyone with access to my station to get a call
    book listing.

So when you finger (or telnet to socket 79) Doug's machine and
put a "%" before the desired callsign, the request hops over
to the hard disk containing the callbook info.

Just a few days ago, they linked all this with the AX.25 mailbox
capability of the KA9Q package (written by Dan Frank, W9NK) in
order to offer the callbook server to AX.25 users. So now you
can either use the TCP finger command, or just make a normal
AX.25 connection, and look up any U.S. ham. Nifty, eh?!

By the way, this is a good opportunity to publicly thank Rusty
for all his work on the callsign project. In addition to Doug's
server, I'm also aware of an instance where a local ham pulled
out the names of all hams in a given city, then gave the resulting
disk files to the ARES emergency coordinators in those towns. Rusty
--thanks for making all this possible!


Patty

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

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

Date: 10 Mar 89 18:59:29 GMT
From: hamal.usc.edu![e-mail]  (Dick Mead)
Subject: Want old CP/M TCP/IP code.

    If anyone has access to, or can point me to, the source for
    the old CP/M version of TCP/IP, please do so. I have several
    hams asking for it, even after I told them it would not be
    fully function in only 64k. Please, just message if you can help,
    I do not need any messages rehasing the usefulness of CP/M
    or TCP code runing on it or 8080/Z80 cpu's. I already know.

    Thanks & 73's   Dick WB6NGC  <[e-mail]>

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

End of PACKET-RADIO Digest
******************************
12-Mar-89 02:06:43-MST,5564;000000000000
Return-Path: <[e-mail]>
Date: Sun, 12 Mar 89 01:30:40 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #67
To: [e-mail]

PACKET-RADIO Digest         Sun, 12 Mar 89       Volume 89 : Issue  67

Today's Topics:
           Headend Frequency Translators and packet
            KISS TNC Construction Project.
----------------------------------------------------------------------

Date: 11 Mar 89 21:27:16 GMT
From: ka9q.bellcore.com![e-mail]  (Phil Karn)
Subject: Headend Frequency Translators and packet

>Other than possibly regulatory reasons (which can be fixed) are
>there any technical reasons why we can't run linear translators
>for packet much the same as the Headend Re-Modulators used on most
>broadband LANs?  I would think this has the potential to eliminate
>the "hidden xmitter" problem and even make real CD available to add
>to our current CSMA scheme.

Bill, you'd make a great audience shill. :-)

I'm working on exactly this idea for use with the WA4DSY 56kbps modems.  I'm
designing a box that, when connected between a stock receive converter to a
stock transmit converter, forms a 100 KHz linear crossband translator.  I
plan on putting the input on 70cm and the output on 220 Mhz, using channels
already allocated to wideband packet in the ARRL band plan.

The advantages of this scheme are just as you mentioned. Hidden terminals
are eliminated, since everyone can hear everyone else. This makes CSMA work.
But it gives you another important benefit: because of the crossband
operation, the users can easily hear their own signals coming through the
translator as they transmit. The user's controller need only compare what it
is receiving to the buffer it is transmitting. If the comparison fails, or
if a receive error (premature frame end, frame abort, etc) occurs, the
controller can conclude that it got stepped on and abort the transmission.
It then performs a random backoff-and-retransmit operation. This is CD
(collision detection), making the system true CSMA/CD.

Any resemblance to Ethernet is strictly intentional; it is the collision
detection in Ethernet that keeps it stable and efficient even under
pathological overloads. (See the paper delivered by Boggs at SIGCOMM last
summer). Another benefit comes from knowing that if you hear your own packet
come out of the translator intact, chances are very good that your intended
destination also received it correctly. This allows you to eliminate
link-level protocol acknowledgements, further reducing overhead. (You'd
still have TCP providing end-to-end acknowledgements and flow control, of
course; these would be essential no matter how reliable the links were).

The translator design is quite straightforward; the only stumbling block has
been obtaining the crystal bandpass filter needed to establish the bandwidth
of the translator and to protect other users of the band used by the
translator's output. (The tower where I plan to install this thing has a 220
MHz FM repeater). Just yesterday I discovered a supplier that can give me an
8-pole 110 KHz bandwidth crystal filter for a 21.4 MHz IF for about $200.
(The actual modem bandwidth is about 75 Khz using the FCC method, so it's
the ultimate attenuation of the filter, not the precise bandwidth, that I'm
most concerned about).

There needs to be AGC (to prevent the power amplifier from being overdriven
by strong signals) and probably a low-level CW beacon on the edge of the
passband to identify the translator. The result will closely resemble the
linear transponders flown for years on OSCAR satellites. The main difference
will be the lack of heroic (and costly) methods for obtaining maximum
transmitter efficiency; they're unnecessary when you don't have to rely on
solar power.

I see no reason this scheme shouldn't be perfectly legal under existing
rules, since I limit the bandwidth to the maximum allowed for digital
transmissions. The same translator design could also carry analog signals,
since as SSB voice. I don't understand why terrestrial linear translators
aren't more popular, as they represent an excellent way to make better use
of our higher bands with modulation methods more bandwidth-efficient than
FM.

Phil, KA9Q

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

Date: 10 Mar 89 21:12:00 GMT
From: asuvax!stjhmc!f1.n234.z1.fidonet.org![e-mail]  (Jim Grubs)
Subject: KISS TNC Construction Project.

 > From: karn@jupiter..bellcore.com (Phil R. Karn)
 > Date: 9 Mar 89 19:20:40 GMT
 > Organization: Bell Communications Research, Inc
 > Message-ID: <[e-mail]>
 > Newsgroups: rec.ham-radio.packet
 >
 > >    How about a KISS only TNC. This would  be a TNC with only the
 > >Keying, audio and simple control stuff. Should be small and easy
 > >to build. It would only do KISS so should be easy to get working
 > >- plug it in and turn it on.
 >
 > They already exist, in the form of plug-in HDLC adaptor cards for the PC.
 > Several designs exist: the HAPN board (Intel 8273), the PACCOMM PC-100
 > (Zilog 8530) and the DRSI PCPA (also 8530).

Which would you pick for your own use?


--
Uucp: ...{gatech,ames,rutgers}!ncar!noao!asuvax!stjhmc!234!1!Jim.Grubs
Internet: [e-mail]

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

End of PACKET-RADIO Digest
******************************
13-Mar-89 01:27:52-MST,11322;000000000000
Mail-From: KPETERSEN created at 13-Mar-89 01:22:17
Return-Path: <[e-mail]>
Date: Mon, 13 Mar 89 01:22:16 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #68
To: [e-mail]

PACKET-RADIO Digest         Mon, 13 Mar 89       Volume 89 : Issue  68

Today's Topics:
                gateway 3/3/89
----------------------------------------------------------------------

Date: 13 Mar 89 04:28:39 GMT
From: osu-cis!n8emr![e-mail]  (Gary Sanders)
Subject: gateway 3/3/89

==============================================================
|               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 12, March 3, 1989

              10-METER FM PACKET RADIO REDUX

Recently, I received some letters contesting a Gateway item stating that FM
packet-radio was not permitted on 10 meters (see Gateway, Volume 5, Number
8). Citing FCC Part 97.69(a)(2), which states that "When type A2B, F1B, F2B
emissions are used on frequencies below 50 MHz...," the writers argued that
F2B (FM) emissions are permitted on the 10-meter band.  Admittedly,
97.69(a)(2) implies that A2B, F1B and F2B emissions are permitted below 50
MHz, however, such an inference is superseded by the clear intention of
97.61(a) which does not permit A2B or F2B emissions below 50 MHz (and
permits F1B emissions only in certain subbands below 50 MHz.)

AFSK is permitted below 50 MHz because when it is used with a properly
designed and adjusted transmitter, AFSK, while technically a J2B emission,
cannot be distinguished from an F1B emission on the air.  (The user should
make certain that audio distortion, carrier and unwanted sidebands are not
present to the degree of causing interference.) Thus, on any frequencies
below 50 MHz where F1B emissions are permitted by 97.61(a), properly
adjusted AFSK emissions are also permitted.

That's the way it is.  You can look it up! However, this situation may
change, because the ARRL Board of Directors passed a resolution at their
annual meeting in January that directed their Membership Services Committee
to study the feasibility and spectrum-management impact of permitting FM
packet-radio operation on 10 meters above 28.3 MHz. A report on the matter
is scheduled to be presented at the Board's second meeting later this year.
Stand by for future developments.

                 18-MHz BAND PLAN

An item concerning the opening of the 18-MHz band to Amateur Radio
operations appeared in the previous issue of Gateway. A suggested band plan
for 18-MHz operations follows:

 Freq (MHz) Mode

 18.068-18.168 CW
 18.100-18.110 RTTY and packet radio
 18.110-18.168 SSB and other analog operations

 from The ARRL Letter

           LAST RELEASE OF VERSION 9 W0RLI PBBS SOFTWARE

Version 9.07 of the W0RLI PBBS software has been released and is available
from the usual sources. With this release, Hank Oredsen, W0RLI, believes
that Version 9 is "finished" and says that there are "no plans for further
work under that version number."

Hank's next effort will be to provide a useful interface for other
programmers. W0RLI's initial focus will be to eliminate the SMTP interface,
thus, X-forwarding will no longer be supported, and to improve the
import/export interface, thus, allowing I and O-forwarding to support more
formats.

These changes will appear in Version 10.0 at some unknown future date and,
according to Hank, "...will allow any programmer to create and distribute a
more reasonable SMTP interface. My hope is that some of the TCP/IP folks
will do this 'real soon now.'"

             K3RLI CBBS VERSION 6.0 AVAILABLE

Version 6.0 of the K3RLI CBBS Mailbox System software for IBM PCs (and
clones) has been released and is available from the CompuServe HamNet
library (LIB 9). Comments concerning the code should be sent to Ed
Picchetti, K3RLI @ K3RLI, or Joe Lagermasini, AG3F @ AG3F.

               NOVICE NOTCH: TCP/IP

N1DL-8 in Huntington Bay, New York, is a TCP/IP gateway for Novices on
223.42 MHz. The node interconnects Long Island, New Jersey and New England
courtesy of Karl Geng, N1DL

(Gateway would like to continue publicizing Novice packet-radio activity,
so if you know of any, please let me know, too. - WA1LOU)


            CONTINENTAL DIVIDE BRIDGED

A new 40-meter packet-radio network links Colorado's Denver, Montrose and
Durango areas. Before this network was established, packet-radio
communications among these areas was unreliable at best because of the lack
of a direct path across the Continental Divide

The network is essentially a hub-and-spoke arrangement with the hub being
operated by Bud Thompson, N0IA, who runs a full-time 40-meter PBBS in
Lakewood, Colorado, which functions mainly as a port for the 2-meter PBBSs
in the Greater Denver area (WB2ENA, WB0BLV and WA8ZIA).  The Durango spoke
is operated by Warren Holland, WM0Z, who runs a part-time 40-meter PBBS
that serves as a port for the 2-meter PBBS in Durango, KD0DI. The Montrose
40-meter spoke is operated by Bill Allen, WA0OYI, who runs a "Kanbox." Ken
Johnson, N1CWP, works with the net on 40 meters and also works into WB0BLV
in Colorado Springs on VHF. N1CWP is also part of the nationwide 14.111-MHz
PBBS network.

Although all packet-radio message types are handled by the network, its
specialty is type T(raffic), ie, NTS traffic. The N0IA and WM0Z PBBSs are
operating with specially adapted CBBS PBBS software that offers on-line,
prompted, NTS-message formatting plus automatic routing of NTS messages
addressed to selected ZIP Codes. The participating 40-meter PBBSs are
primarily used for message forwarding, but direct user access is permitted.

Additional 40-meter PBBS spokes are needed to complete this network,
especially in southeastern Colorado, Wyoming, and the Salt Lake City and
Phoenix areas. These PBBSs can be part-time operations, but would need to
check in with the hub at least on a daily basis. Interested stations should
check their communications with the hub stations with the upper tone
frequency at 7085.3 kHz (center channel frequency of 7085.2 kHz). Software
will be provided to participating stations in order that they can set up
CBBS PBBS operation with the special NTS formatting capability.

by Warren Holland, WM0Z, and Kit Orlosky, KD0DI from RMPRA>Packet

              ST LOUIS AREA PBBS SEMINAR HELD

Fifty people attended an all-day packet-radio BBS seminar on January 28 in
Belleville, Illinois, that was sponsored by the St Clair County (Illinois)
Amateur Radio Club. Topics discussed included optimal PBBS parameters, PBBS
operating techniques, packet cluster operation and public service PBBS
communications. The following suggested band plan for the St Louis area was
offered by Terry Thorne, KA9YZS:

   Freq     Mode
   (MHz)

   144.91   packet clusters
   144.93   QSOs and data transfers
   144.95   ARES/SKYWARN packet clusters
   144.97   QSOs and data transfers
   144.99   QSOs and data transfers
   145.01   NET/ROM DX QSOs
   145.03   QSOs and data transfers
   145.05   bulletin boards
   145.07   QSOs and data transfers
   145.09   QSOs and data transfers
   223.40   bulletin boards and QSOs

KA9YZS commented that these frequencies were not etched in stone, but are
guidelines for packet-radio activities to help keep peace among operators.

For further information, contact Dave Eacho, KD4PS (111 S Monroe St,
Trenton, IL 62293), or Frank Johnson, N9GQR (308 S 6th St, Monmouth, IL
61462).

from Frank Johnson, N9GQR

           IEEE PUBLISHES PACKET-RADIO ARTICLES

IEEE Journal on Selected Areas in Communications, Volume 7, Number 2,
February, 1989, contained two articles of interest to packet-radio
enthusiasts. "Radio_ISA_Net: A Single-Hop Centralized Packet Radio
Network for PC-to-Mainframe Interconnection," by Michele Aicardi,
Franco Davoli and Alberto Giordano, I4TD, describes the development of
a single-hop packet-radio network at the University of Genoa, Italy,
using AX.25 TNCs to interconnect remote PCs to the Ethernet-based LAN
of the University's Department of Communications, Computer and Systems
Science via the 70-cm band.

"Packet Radio in the Amateur Satellite Service," by Robert J.
Diersing, N5AHD, and former Gateway editor, Jeffrey W. Ward, K8KA,
presents an overview of the UoSAT-2 Digital Communications Experiment
(DCE), the FUJI-OSCAR-12 mailbox and the AMSAT-OSCAR-13 RUDAK. The
article includes descriptions of the satellites' hardware, software
and operational experience.


           OPERATING TIPS FOR PACKET-RADIO MAIL

When sending a message, please insert a hard carriage return with every
line. If you just type and let your TNC send frames without hitting the
return key, you end up with lines that are difficult to read. Even worse,
some of the mail-forwarding systems (including a couple of the wormholes
that lump your messages into a file and ship the file en masse to the other
end of a path) do not support lines longer than 128 characters and, as a
result, your mail arrives at the other end with holes in the text. So, use
the return key for every line at approximately column number 70.

Problems occur when messages contain TNC commands. Usually someone is
describing some new procedure, script, etc. These often have strings of
asterisks (*) embedded in them. The worst case recently combined a
DISCONNECTED"*** Before . The PBBS code on the other end kept interpreting
this as a disconnect message from its TNC and spent two days trying to move
the message -- the systems always disconnected at the same place in the
message. So, be very cautious when you embed TNC commands in a message.
Never let them start in column one and never use "### DISCONNECTED" in a
message. [The hard copy had ***'s replacing the ###'s, but they obviously
might have caused problems in transmission - de n8xx]

from Dr. Tom Clark, W3IWI

               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.

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

End of PACKET-RADIO Digest
******************************
13-Mar-89 02:08:12-MST,7369;000000000000
Return-Path: <[e-mail]>
Date: Mon, 13 Mar 89 01:30:53 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #69
To: [e-mail]

PACKET-RADIO Digest         Mon, 13 Mar 89       Volume 89 : Issue  69

Today's Topics:
            KISS TNC Construction Project.
            packet talks at dayton
            RPICICGE File Server Problems
              vk2sg rtty report 3/10/89
----------------------------------------------------------------------

Date: 12 Mar 89 12:02:01 GMT
From: mcvax!kth!osiris!sics.se![e-mail]  (Anders Klemets)
Subject: KISS TNC Construction Project.

Julian Macassey writes:
>     How about a KISS only TNC. This would  be a TNC with only the
> Keying, audio and simple control stuff. Should be small and easy
> to build. It would only do KISS so should be easy to get working
> - plug it in and turn it on.

Could someone please explain to me, exactly what parts in a TAPR TNC-2
can be omitted if one just wants to run KISS?

I guess one could use a smaller EPROM, say 32 kbit. But except for that
I cannot really see in what way a dedicated KISS TNC (with an RS232
interface) would be cheaper or easier to build.
Am I missing something crucial here?

73's, Anders SM0RGV

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

Date: 13 Mar 89 04:24:23 GMT
From: osu-cis!n8emr![e-mail]  (Gary Sanders)
Subject: packet talks at dayton

==============================================================
|               Relayed from packet radio via                |
| N8EMR's Ham BBS, 614-457-4227 (1200/2400/19.2 telebit,8N1) |
==============================================================

!!!!!! This is a tenative schedule.. Subject to change.. !!!!!!!


Our packet forum will be on Friday, 28 April in room 4. Our schedule is:

1300-1340 Lyle Johnson WA7GXD "Modems and level 3"

1340-1420 Bob McGuire  N4HY   "DSP and PACSAT"

1420-1500 Bdale Garbee N3EUA  "10Mbit/10GHz, Higher Speeds at
                   Higher Frequencies"

1500-1540 Pete Eaton  WB9FLW  "Radios, Radios,
                   Where Are My High Speed Radios?"

1540-1620 Phil Karn  KA9Q     "Low and High Speed TCP/IP"

1620-1700 Chuck Gelm  NC8Q    "Emergency Uses of Packet"

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

Date: Thu, 02 Mar 89 14:39:15 EST
From: "John S. Fisher" <[e-mail]>
Subject: RPICICGE File Server Problems

The file server at RPICICGE has been having a bad streak of luck the last
several weeks.  Many more requests where coming in than could be handled,
and all but requests for the smallest files were getting rejected.

A recent change to the server itself and some on-going changes to the
gateway from NYSERNET to the ARPANET have caused a noticable improvement.
Most requests are now being handled first time whereas before they were
being rejected every time.

In addition, there is a completely identical server located at NDSUVM1,
and it has apparently experienced fewer connectivity problems....

Regards,
JSFisher
Maintainer of LISTSERV@RPICICGE, et.al.

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

Date: 13 Mar 89 04:13:34 GMT
From: osu-cis!n8emr![e-mail]  (Gary Sanders)
Subject: vk2sg rtty report 3/10/89

==============================================================
|               Relayed from packet radio via                |
| N8EMR's Ham BBS, 614-457-4227 (1200/2400/19.2 telebit,8N1) |
==============================================================

RTTY DX NOTES FOR WEEK ENDING 10TH MARCH 1989
Bulletin ID: RTDX1003.

THIS WEEK HAS BEEN RATHER A MIXED BAG, STARTING OFF VERY WELL.  BUT FROM
WEDNESDAY ON IT JUST DIED, AND VERY LITTLE DX WAS SEEN OR REPORTED.  BUT
MAYBE THIS COMING WEEK WILL BE BETTER.

OUR THANKS THIS WEEK GO TO TG9VT, W2JGR, W1DA, OD5NG, W9CD, JA1ACB, I5FLN
AND VK2EG AND OTHERS. THANKS CHAPS.

BANDPASS

FRIDAY
HH2PJ       14096 KHZ  AT  0250Z
A4IKC       14074 KHZ  AT  0900Z  FEC
VU2DNP      28085 KHZ  AT  1404Z
SV1ALM      28093 KHZ  AT  1410Z
TA3B        28083 KHZ  AT  1427Z
HH2BZ       14091 KHZ  AT  1600Z
5Z4BH       14084 KHZ  AT  2100Z  QSL
KH6JEB/KH7  21080 KHZ  AT  2103Z  QSL
9Y4RJS      14084 KHZ  AT  2135Z
PJ2WOL      14083 KHZ  AT  2210Z

SATURDAY

UZ0CWW      14096 KHZ  AT  0530Z
UR2FU       21087 KHZ  AT  1220Z
9H1EV       28093 KHZ  AT  1815Z
FM5EQ       28093 KHZ  AT  1920Z
EA8BIN      21086 KHZ  AT  2050Z
FM5CD       14094 KHZ  AT  2335Z

SUNDAY
3X1SG       21090 KHZ  AT  0820Z
SV0AC       28082 KHZ  AT  1057Z  ARQ
BY1ARN      28082 KHZ  AT  1233Z
VU2SJV      28093 KHZ  AT  1247Z
TA5C        28091 KHZ  AT  1519Z
YB8HX       21095 KHZ  AT  1522Z
UA4HBW      21090 KHZ  AT  1645Z  QSL

MONDAY

YJ8JS       28084 KHZ  AT  0305Z
OD5NG       14074 KHZ  AT  0355Z  ARQ
UA4HBW      14083 KHZ  AT  0330Z

TUESDAY
YJ8JS       28088 KHZ  AT  0015Z
T55G        28083 KHZ  AT  0800Z
7P8DR       21085 KHZ  AT  0800Z  QSL
5Z4BH       21095 KHZ  AT  1200Z
3DA0AL      21090 KHZ  AT  1330Z
EA9KU       21085 KHZ  AT  1800Z
TA3D        14086 KHZ  AT  2005Z
9H1ED       14086 KHZ  AT  2006Z
3X1SG       14092 KHZ  AT  2100Z

WEDNESDAY
6Y5PG       14074 KHZ  AT  0415Z  FEC
HI8EL       14091 KHZ  AT  0148Z
9Y4RJS      14083 KHZ  AT  0202Z
S79D        21093 KHZ  AT  1840Z  QSL
FM5EQ       14095 KHZ  AT  2056Z

THURSDAY
YB8HX       14081 KHZ  AT  0930Z


QSL INFORMATION.

KH6JEB/KH7, QSL VIA HIS HOME ADDRESS.
5Z4BH WILL QSL VIA KE3A.
UA4HBW IS F. PRONIN. PO BOX 353, KUIBYSHEV, 443001  U.S.S.R.
7P8DR QSL TO BOX 562, MASERU, LESOTHO.
S79D QSLS VIA WB4YZU.
U.S. STATIONS WHO WORKED 3W1A, PLEASE QSL VIA WA4FRU.

NOTES OF INTEREST.
FIRST, VU2JX WILL OPERATE AS VU7JX DURING THE BARTG CONTEST.  QSL VIA
VU2XP,  WE BELIEVE.  WILL CHECK THAT LATER.

THE BARTG CONTEST IS THE WEEKEND OF 18TH TO 20TH MARCH.

ALSO THERE IS A REPORT THAT OCEAN ISLAND WILL BE CLASIFIED AS A SEPERATE
COUNTRY FROM KIRIBATI AND THE CALLSIGN OF T33JS HAS BEEN ISSUED, WE
BELIEVE.  THE DATE OF OPERATION IS NOT KNOWN AT THIS TIME.

DL7ANP/UG6 WILL BE ACTIVE UNTIL THE END OF MARCH.  QSL TO THE DL BUREAU,
OR VIA HIS HOME ADDRESS.

DL6JC WILL BE OPERATING FROM TY6JC FROM THE 25TH MARCH FOR ABOUT 7
DAYS.

APRIL.  5W1GP WILL BE OPERATING FROM KH8, A35, ZK1, ZK3 AND MAYBE ROTUMA
DURING THE APRIL TIME FRAME.  REVILLA GIGEDO, XF4L WILL OPERATE FROM 11TH
TO 19TH.  THEY HOPE FOR RTTY AS WELL AS OTHER MODES.  QSL VIA OH2BN.
MARION ISLAND.  ZM8 WILL BE ACTIVE DURING APRIL WITH GEAR DONATED BY W6PQS
AND THE SOUTHERN CALIFORNIA RTTY GROUP.

MAY.  ST PETER AND ST PAUL ROCKS WILL BE ACTIVATED 3RD TO 10TH MAY.  RTTY
CALL WILL BE ZY0SY.  OPERATION BY THE NATAL DX GROUP BRAZIL.

JUNE.  TK/HB9CJC WILL OPERATE FROM CORSICA DURING JUNE.  JG1RC WILL GO TO
THE CAROLINE ISLANDS EITHER IN MAY OR JUNE.  MORE LATER.

AUGUST.  ANGOLA HAS BEEN DELAYED UNTIL AUGUST DUE TO CHANGE IN MILITARY
PERSONEL.

GL DE  DX1. (VK2SG)

Forwarded via packet by Tad, KT7H @ KE7OM.  Thanks to VK2AGE for forwarding
from Australia.

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

End of PACKET-RADIO Digest
******************************
14-Mar-89 01:58:12-MST,2399;000000000000
Return-Path: <[e-mail]>
Date: Tue, 14 Mar 89 01:30:33 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #70
To: [e-mail]

PACKET-RADIO Digest         Tue, 14 Mar 89       Volume 89 : Issue  70

Today's Topics:
                 HAPN
                  TAPR DSP?
----------------------------------------------------------------------

Date: 13 Mar 89 13:58 +0100
From: Magne Maehre <[e-mail]>
Subject: HAPN

The comp.man. at my university, LA4BM bought a HAPN-Card a year ago or so.
He hasn't been very active, so he didn't recognize he had a problem
with the Card until recently.

His problem is as follows:  Every time a packet beeing sent on the frequency,
the Card tries to respond and keys the transmitter for a moment.  If
the packet is addressed for LA4BM all goes well, but if it isn't it still
keys the transmitter. This surely makes a bit a trouble for all trying
to use the freq.

Has anybody else noticed this problem??  Any possible solutions??
If I did not make my self clear enough concerning the problem please
give me a note.
                   -Magne, LA1BFA
============================================================================
E-Mail   :  [e-mail]
        (or something like that)
DecNET   :  56720::M_MAEHRE       -  AVH::M_MAEHRE
Packet   :  LA1BFA @LA8GE
============================================================================
         Dont't tell anyone, but I don't like UNIX
============================================================================

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

Date: 13 Mar 89 17:04:27 GMT
From: vsi1!wyse![e-mail]  (PC-NFS Philip Graham x1124 #)
Subject: TAPR DSP?

I have been hearing very little about the current TAPR project that is working
on a DSP version of a modem for our favorite hobby. Does any one know what it
is when it will be done, are samples/kits going to be available?

DSP chips are really outstanding for this type of application...

Thanks in advance,

73 Phil KJ6NN

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

End of PACKET-RADIO Digest
******************************
15-Mar-89 01:39:42-MST,7402;000000000000
Return-Path: <[e-mail]>
Date: Wed, 15 Mar 89 01:30:38 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #71
To: [e-mail]

PACKET-RADIO Digest         Wed, 15 Mar 89       Volume 89 : Issue  71

Today's Topics:
                KAM vs. PK232
            Packet on the Shuttle
         Rusty's callsign info goes to work!
             TH-215 to Tiny 2 TNC
                tiny-2 tnc fix
----------------------------------------------------------------------

Date: 14 Mar 89 22:57:37 GMT
From: elbereth.rutgers.edu!ron.rutgers.edu![e-mail]  (Ron Natalie)
Subject: KAM vs. PK232

The PK-232 was easy to hook up to the Kenwood 440.  I used the
RCA AFSK input and output jacks and used the "remote" plug (the
one designed to be plugged into the linear) for push-to-talk.
The right way to do this is to use the 13 pin data plug (which
I just got some of).  This allows you to mute the microphone
jack on the front as well.  You just run the PTT and audio lines
from the 5 pin thing on the back of the 232 to the 440.

There are however two problems.  First, the 232 ought to have
a separate AFSK out level for the two radio jacks on it.  We
had to grossly change the Mic gain on the 2M rig to make it
match the 440 FSK in.  We also had to add a little cap across
the 5 pin plug to keep stray RF from holding PTT down.

-Ron

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

Date: 13 Mar 89 16:03:27 GMT
From: oliveb!pyramid!prls!philabs!briar.philips.com![e-mail]  (Robert Casey;6282;3.57;$0201)
Subject: Packet on the Shuttle

copied from amateur radio packet:
 Msg# TSP  Size Read To     @ BBS  From    Date/Time
 25878 BN   1113    2 ALL           N4HAP  8903/0240
 Subject: Packet proposed for shuttle

       From: N4HAP@N4HAP
       To: ALL@USNET
       Subject: Packet proposed for shuttle

       Heath Company recently donated three HK-21 pocket packet
       TNC's to the NASA Johnson Space Center Amateur Radio Club in
       Houston.  As part of the Shuttle Amateur Radio EXperiment
       (SAREX), it is proposed that an HK-21 be used on a March
       1990 shuttle flight.

       In this experiment, amateur radio frequencies will be used
       to transmit packetized data to and from the shuttle.

       If the project is approved, one of the TNC's will be
       specially adapted for space travel.  Nasa will mount it into
       a protective SAREX casing and modifications will be made for
       use in zero gravity.

       From Radio Electronics Magazine - April 1989

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

Date: 13 Mar 89 20:54:13 GMT
From: cadnetix.COM!cadnetix![e-mail]  (Rusty)
Subject: Rusty's callsign info goes to work!

In article <[e-mail]> [e-mail] (Patty Winter) writes:
>>lots of good stuff deleted<<
>. Rusty--thanks for making all this possible!
>
You are welcome!  I'm glad people are starting to get use out of it.
(One of these days, I'll get the data transferred to my PC at home,
and **I'll** get to use it!  half :-).  It is amazing to me how I still
get calls based on some of those first announcements!  Just last week
I got a call from someone hearing about it for the first time, from
a message about 3 months old!  Ah, the vagarities of news....

I understand that there is another callsign server out east somewhere,
and there is a 'company-private' callsign server here in Colorado.
Then there was the person who made a list of all local hams whose
licenses were about to expire.  He contacted everybody on the list
and reminded them to renew.  Some people had totally forgotten about it,
and were very thankful.

I have also heard from a few people who are basically waiting to get
enough room on their disks to hold it all!

-----(and the ham callsign project goes on!  for info, ask:)-------
Rusty Carruth  UUCP:{uunet,boulder}!cadnetix!rusty  DOMAIN: [e-mail]
Cadnetix Corp. [phone]x241 \  5775 Flatiron Pkwy. \ Boulder, Co 80301
Radio: N7IKQ    'home': P.O.B. 461 \  Lafayette, CO 80026

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

Date: 13 Mar 89 16:05:33 GMT
From: oliveb!pyramid!prls!philabs!briar.philips.com![e-mail]  (Robert Casey;6282;3.57;$0201)
Subject: TH-215 to Tiny 2 TNC

copied from packet:
From: [e-mail] (George)
Subject: HOW TO: th-215a to tnc
Date: 04 Mar 89 15:39:34 edt (Sat)
From: [e-mail] (Harry)
Subject: KENWOOD TH-215A TO TNC

THE HOOK-UP OF A TH-215A TO MY PAC-COMM TINY 2 TNC WAS VERY EASY. THERE
ARE NO COMPONENTS INVOLVED IN THE CONNECTION. ALL YOU NEED ARE TWO
PHONE PLUGS: 1 SUB MINI, AND 1 STEREO(3 CONDUCTOR) MINI. BOTH
AVAILABLE FROM RADIO SHACK,TWO TO A PACK.  IF YOU HAVE A KENWOOD
SPEAKER MIKE, THEN THE INSTRUCTION SHEET WILL CONTAIN A DR AWING
SHOWING THE BASIC CONNECTING LINES. IF NOT, HERES HOW ITS DONE:  THE
SUB-MINI IS THE SPEAKER PLUG. THE CENTER PIN GOES TO THE SPEAKER PIN ON
THE 5 PIN DIN ON THE TNC, THE SHAFT IS THE GROUND.

ON THE MINI STEREO PLUG, YOU DONT USE THE CENTER PIN, JUST THE TWO
SHAFT CONNECTIONS. THE SHORT SHAFT GOES TO MIKE, THE LONG SHAFT IS THE
PUSH TO TALK......THATS IT, FOUR WIRES TO THE CONNECTOR THAT GOES TO
THE TNC PLUG, AND YOURE IN BUSINESS!!

ONE VERY VERY IMPORTANT THING-----ALWAYS MAKE SURE THAT ALL BATTERY
SAVE FUNCTIONS ON THE HANDY TALKIE ARE OFF. IF IT ISNT, A SLIGHT DELAY
IN RECEIVING WILL CAUSE RETRYS FROM THE STATION SENDING TO YOU, AND
WILL DELAY PACKET RECEPTION AT YOUR END. PLEASE AKE CAREFUL NOTE OF
THIS. ANY QUESTIONS, REPLY TO K2JOV, HARRY, AT N2ELC-4 BBS IN
N.J......GOOD LUCK!!  1450z, 463 msgs, #25850 last @KD6TH-4 MailBox>

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

Date: 13 Mar 89 16:07:03 GMT
From: oliveb!pyramid!prls!philabs!briar.philips.com![e-mail]  (Robert Casey;6282;3.57;$0201)
Subject: tiny-2 tnc fix

 copied from packet:
 Msg# TSP  Size Read To     @ BBS  From    Date/Time
 25853 BN   1240    0 ALL           N2EZG  8903/1617
 Subject: Paccomm Tiny-2 Factory Mod

       Here is the "Factory" fix for Pac-Comm Tiny-2's & Micro-Power 2's
       that have become hard of hearing.  It seems that Pac-Comm has some
       boards out that work fine when new, but with age the tnc requires
       a huge amount of Audio input from the speaker jack or it won't
       decode properly.  They are lost as to what is deterioating in the
       boards but offer this fix to its customers.
        It is quite simple and very neat, all parts are mounted on the
        under-
        side of a 16 pin IC socket, the Modem chip TCM3105 (U16) is
        removed,
        the modified socket is inserted into existing socket on TNC's
        board,
        and the modem chip is re-installed.

        Parts Needed:
        1 - 16 pin IC socket
        1 - 2222 Transistor NPN (EGC 123AP)
        2 - 10000 ohm 5% resistors (brown-black-orange-gold)

        Instructions:
         Solder 1 resistor to Emitter, other end of resistor to pin 12
          Solder 1 resistor to Base, other end to pin 2
           Solder collector to pin 5
           >EndFile<

Note: I have not tested or verified this mod, proceed at your own risk.
WA2ISE

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

End of PACKET-RADIO Digest
******************************
16-Mar-89 02:00:23-MST,7640;000000000000
Return-Path: <[e-mail]>
Date: Thu, 16 Mar 89 01:30:51 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #72
To: [e-mail]

PACKET-RADIO Digest         Thu, 16 Mar 89       Volume 89 : Issue  72

Today's Topics:
               Does anyone have
                KAM vs. PK232
               Receiving packet w/o TNC
              Setting up TCP/IP (2 msgs)
                  TAPR DSP?
----------------------------------------------------------------------

Date: 14 Mar 89 23:47:30 GMT
From: tektronix!sequent![e-mail]  (Brian Sheets)
Subject: Does anyone have

Does anyone have, or know of, a "YAPP" program for unix.
I would like to download programs from packet to unix while at work.

TIA  brians
--
Brian Sheets (Bonehead)                             "I'll be back"
19730 SW Prospect Ln.
Aloha, Or 97007                                  Arnold Schwarzenegger,
                         Any movie he's been in.

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

Date: 13 Mar 89 16:04:59 GMT
From: mitel!sce!cognos!dgbt![e-mail]  (Barry Mclarnon)
Subject: KAM vs. PK232

From article <[e-mail]>, by [e-mail] (Rich Bono):
>       I have been VERY happy with the TNC's... they work.. have many
> useful features.. are compatible with software... and DON'T look like they
> were thrown together in someones garage/basement workshop!  Plus, Kantronix
> is very responsive to users as far as improving their software, and adding
> many features.. which they "give" to the users for a little over the cost
> of the ROMs themselves..  (ie: ROM update for KAM 27C512, $15)

Your mileage may vary.  Although Kantronics has been gung ho over adding
software bells and whistles, some of which are of dubious value to the
packet community as a whole, they have been less responsive concerning
certain technical problems.  A number of KPC users have experienced
problems, apparently related to flow control bugs, when trying to do binary
file transfers or run certain BBS software, and I gather that Kantronics
was not much interested in helping solve the problem.  Kantronics is also
notorious for selling TNCs that have NO watchdog timer, causing numerous
instances of TNCs glitching and jamming packet frequencies for hours
(probably melting down a few rigs too :-).  I certainly hope they have at
least discontinued that practice.
>
>                               Rich, NM1D
>

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

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

Date: Wed, 15 Mar 89 10:11:08 CET
From: Tom Anna <[e-mail]>
Subject: Receiving packet w/o TNC

There was a discussion lately, if a packet radio station without TNC is
possible. Several good reasons were quoted, that it can not be done.

Why not do it ALL in software ? Hardware requirements: 1 A/D converter
8 bit / 8kHz, a little buffer RAM, and some TTL stuff, all together on
a small PC plug in card. This card digitizes the audio signal from the
receiver in a CD player style, and makes it accessible to the computer.

Software: Some digital filtering, a demodulator and a packet disassembler.
If you sample the audio signal with 8K samples/sec, there is 125 mikro-
seconds CPU time per sample: This should be enough for these tasks.

Only by software changes you could also receive RTTY/AMTOR/SSTV/weather ...
With little extra hardware you might also transmit all these modes.

Before I start programming this, has anybody begun/completed it already ?
Comments welcome. Further details on request.

Tom HB9CWE          BIOMED@CZHETH5A
ETH Zurich     or IBTUSM02@CZHETH1I
Switzerland

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

Date: 15 Mar 89 09:04:17 GMT
From: mcvax!kth!draken!tut!santra!kolvi![e-mail]  (Markku Toijala)
Subject: Setting up TCP/IP

We are (finally!) trying to get some TCP/IP activity on air here
in OH-land and a couple of questions have arised.  I hope you
there with more practicat experience can help:

Most configuration exaples and address-lists still seem to use
domain names of style [e-mail] . However, I understand
that SRI-NIC has registered ampr.org domain for amateur use, so
we should that one?  Any points on that?

I have tried to find out a good gateway between SMTP and MBL-bbs.
So far there seem to be three possible solutions: SERVER, PXX and
changing to W0RLI software.  PXX lacks the abitity to force the
decired PID on a message.  With server you must always address
your mail to user server and add extra lines in the beginning
of message.  Server always sets the sender-field to "server",
not so nice.  W0RLI has no provision to have bulletins sent from
SMTP side?  There are rumors that AA4RE would have SMTP support
in future releases, has anybody heard of Jeff?

Still it seems to me that using SERVER would be the best choise
for now (if you want to have bulletins sent from SMTP). Have I
missed something?

73 de Markku/OH2BQZ
-----
Markku Toijala                         !   UUCP:     {uunet,mcvax}!kolvi!mto
Helsinki University of Technology      !   Internet: [e-mail]
Otakaari 5 A                           !   EARN:     [e-mail]
SF-02150 Espoo,  Finland               !   tel:      [phone]

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

Date: 16 Mar 89 05:07:19 GMT
From: [e-mail]  (Brian Kantor)
Subject: Setting up TCP/IP

The official domain is 'ampr.org'.  Hostnames are therefore

    wb6cyt.ampr.org
    nsf-gw.ampr.org
    sun.ka9q.ampr.org

etc., etc.  But because you may omit the common upper hierarchy of a
domain when you are within that domain, these simplify to just

    wb6cyt
    nsf-gw
    sun.ka9q

for most amateurs.  I'd suggest using the unqualified names on the
air and in hosts.net files, and let the mail gateways take care of
adding the full qualification to the name when necessary.

I don't know who started the 'wb6cyt.ampr' custom; it's not very useful
and it's not very correct.  I think we should stomp on it.

    Brian Kantor    WB6CYT  UC San Diego   [e-mail]
        ampr.org domain czar

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

Date: 14 Mar 89 19:04:29 GMT
From: tektronix!tekecs![e-mail]  (Michael T. Horne)
Subject: TAPR DSP?

>I have been hearing very little about the current TAPR project that is working
>on a DSP version of a modem for our favorite hobby. Does any one know what it
>is when it will be done, are samples/kits going to be available?

The latest word is that most of the folks working on the modem (e.g.
Bob N4HY, Tom W3IWI, etc.) are very busy working on the PACSATS to get
them ready for the launch early this summer.

By the way, the rumor is that the 56K DSP parts (which won't be used in the
first release of the DSP platform) will be <$15/per by the end of the year.
Perhaps they should look closer at those parts and skip the TMS320s all
together? :)

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

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

End of PACKET-RADIO Digest
******************************
17-Mar-89 01:58:48-MST,10534;000000000000
Return-Path: <[e-mail]>
Date: Fri, 17 Mar 89 01:30:26 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #73
To: [e-mail]

PACKET-RADIO Digest         Fri, 17 Mar 89       Volume 89 : Issue  73

Today's Topics:
          Directory Service Standardization
               Does anyone have
           Headend Frequency Translators and packet
            KISS TNC Construction Project.
           Need alternate source for ka9q software.
         Version 1.8 of DOSGATE available...
----------------------------------------------------------------------

Date: 16 Mar 89 07:51:12 GMT
From: att!homxb!hou2d![e-mail]  (J. Gordon Beattie, Jr.)
Subject: Directory Service Standardization

Hi guys,
   I have been watching all kinds of non-discussions of WP and other
directory servers and thought it might be nice to ask you folks who
may or may not be on this list,  or who may or may not be on CompuServe
to get involved with a project which needs doing:

standardization of data elements and system/user services for a directory
service.  I have enclosed some messages that went out to CIS
tonight in order to give you some background.  Anyone who has any
ideas for this project pipe up after you read these messages.
73,
Gordon Beattie, N2DSY

packet:   N2DSY@DK6TH
      [e-mail]
unix:     ...!att!hou2d!n2dsy
cis:      72417,652
 ------------------------------------------------------------
#: 93901 S9/Packet Radio
    16-Mar-89  02:24:54
Sb: #93800-Error in CONFIG.MB
Fm: J. G. Beattie, Jr. N2DSY 72417,652
To: eric williams WD6CMU 71336,1424

WD6CMU, VE3GYQ, W0RLI, WA7MBL, KA2BQE, K3RLI, etc...

Are you guys (or others) interested in defining minimum
functional set of data elements and system/user services for an
Amateur Radio directory service? We would greatly benefit from a
public discussion of such a system and would help remove some of
the operational hassles if we stop and plan a bit. No one is
saying that the systems will be the same, but simply
interoperable.

My preference is for data elements which can be found in CCITT
X.500 Directory Services.  I would like to see a data set
whereby a system which did not support all elements would at
least carry them without discarding the unsupported data.  (Not
a bad idea for mail either...) After this first step we can look
into a common set of services or functions.

Why don't we all get our heads together and agree on something
that will work for the Amateur Community while also providing
for the individual preferences of each developer/user community.
I will be finishing up the promised message header elements
shortly and with it I can have a draft set of directory data
elements. Interested?  What say? 73, Gordon


#: 93899 S9/Packet Radio
    16-Mar-89  02:24:22
Sb: #93738-Error in CONFIG.MB
Fm: J. G. Beattie, Jr. N2DSY 72417,652
To: David Toth VE3GYQ 72255,152

Dave,
   Thanks for the info...It seems that there is a perception
that the WP protocol or plan is a secret...at least that's what
I saw here...could you tell us more?  Our plan is to implement a
server based on the CCITT X.500 Directory Service.  Maybe
through some exchange of ideas we can agree on a common set of
interoperable user/system services for our systems.  We would
also be interested in interoperation with other directories. Our
objective is not really directed at the user, but also systems
and services as directory entries.  Your thoughts? 73, Gordon




#: 93900 S9/Packet Radio
    16-Mar-89  02:24:36
Sb: #93800-Error in CONFIG.MB
Fm: J. G. Beattie, Jr. N2DSY 72417,652
To: eric williams WD6CMU 71336,1424

Eric,
   maybe I am a bit confused...are you the creator of WP?  If
you are then what is Dave, VE3GYQ doing with W0RLI? I was
looking at your discussion of data elements and I would think
that Name searches are reasonable.  I am waiting for Rusty
Carruth's database of callbook data and for another disk.  All
in all we should not really limit our perspective on what is
useful (that is somewhat subjective) when picking data elements.
We should however limit ourselves to practical database sizes
(again somewhat subjective, but more reasonable). I would like
to see what data elements you keep in your system and add those
into my list (pretty much everything in the Objects and
Attributes section of X.500) with a few notable additions like
Callsign, affiliations, appointments, and a few tweaks, like
refining defined data elements for Amateur Radio purposes. So
when do  you think you could send me a list of data elements?
73, Gordon

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

Date: 15 Mar 89 23:54:02 GMT
From: bigtex!helps!bongo![e-mail]  (julian macassey)
Subject: Does anyone have

In article <[e-mail]>, [e-mail] (Brian Sheets) writes:
> Does anyone have, or know of, a "YAPP" program for unix.
> I would like to download programs from packet to unix while at work.
>
> TIA  brians
> --

Dear Brian,
You might want to have a  look at PMODEM from WB6YMH (Skip Hansen). I
know  it works with MS-DOS machines  running Procomm  or some such on
packet. It is a packet version of YMODEM that Skip put together  some
time  ago to do binary transfers  on packet. His source is available,
so you could compile it on your machine and mess around  til it works
or you give up and take up snail racing instead.

    WB6YMH  is good in the call book,  also you can dial into his
sys and grab all you want via landline. Phone is: [phone]

    You might also consider using net (NET.EXE) and doing TCP/IP.
I sometimes  get  ka9q's  net  running on my Unix 3b1. Certainly less
nerve wracking than PMODEM.

Yours

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

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

Date: 14 Mar 89 15:56:00 GMT
From: mitel!sce!cognos!dgbt![e-mail]  (Barry Mclarnon)
Subject: Headend Frequency Translators and packet

From article <[e-mail]>, by [e-mail] (Phil Karn):
>
> I'm working on exactly this idea for use with the WA4DSY 56kbps modems.  I'm
> designing a box that, when connected between a stock receive converter to a
> stock transmit converter, forms a 100 KHz linear crossband translator.  I
> plan on putting the input on 70cm and the output on 220 Mhz, using channels
> already allocated to wideband packet in the ARRL band plan.
>
>   [further details on the translator design omitted]
>
Phil, what do you feel are the advantages of the linear crossband translator
as opposed to the more traditional approach of using a WA4DSY modem as a bit
regenerator in a crossband full-duplex repeater?  I guess that the cost would
be fairly similar.  At first glance, however, the ability to translate ANY
analog signals rather than just the 56 kbs MSK emissions strikes me as more
of a bug than a feature... I suppose it might come in handy in emergencies
'n such.  Also, the lack of regeneration makes the link margins lower.

We've just begun a project here to set up a 56 kbs LAN using some combination
of 220/440/902 MHz, so I'd be very interested in hearing more of your thoughts
on the design philosophy.
>
> Phil, KA9Q
>
  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

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

Date: 14 Mar 89 18:08:07 GMT
From: aero!trwind![e-mail]  (Bill Gunshannon)
Subject: KISS TNC Construction Project.

At this point I am not sure I understand what is being asked for.

I am currently running a TNC2 (among others) with KISS EPROMS
and I don't see where anything else is removable from a practical
stand point.  The TNC costs right around $100 and the proms can be
gotten from a numbert of sources in some cases even free.
Based on this I don't see how anyone could manufacture a TNC for
KISS that would be any cheaper than what is available now.

Maybe a better explanation of the problem is called for.


bill gunshannon
KB3YV

[e-mail]

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

Date: 16 Mar 89 20:40:34 GMT
From: [e-mail]
Subject: Need alternate source for ka9q software.

Is there any other ftp sites which has the ka9q software on it?
I tried ucsd.edu and louie.udel.edu but could not connect to the
machines here from PSU.  Any other locations preferably here on
the east coast would be appreciated.

-Frank-

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

Date: 15 Mar 89 18:50:51 GMT
From: encore!necis![e-mail]  (Rich Bono)
Subject: Version 1.8 of DOSGATE available...

For those that have been following the DOSGATE project,

    I Have a new version of the DOSGATE driver available (version 1.8).
Changes have been made in the parsing of the CONNECT message from the TNC.
This is to allow DOSGATE to work with a wider range of TNC's.

    If you would like the new version of the DOSGATE driver, contact
me.  Or I could post to the NET here in the PACKET group.

    For those who did not receive the original posting of DOSGATE,
there is a copy availble at the archive site.  DOSGATE is a device driver
that "opens the world" of computers to the packet network.  It works with
standard AX.25 packet, and requires NO special software at the users end.

    This allows remote users to run applications via packet.  This is
not "yet another BBS" application!!!  There is NO limit to what can be
accomplished with the DOSGATE driver and packet radio...  I leave it up to
your imagination....

                    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
******************************
18-Mar-89 02:12:44-MST,6242;000000000000
Return-Path: <[e-mail]>
Date: Sat, 18 Mar 89 01:30:22 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #74
To: [e-mail]

PACKET-RADIO Digest         Sat, 18 Mar 89       Volume 89 : Issue  74

Today's Topics:
               Commodore Packet
           Headend Frequency Translators and packet
           KISS TNC Construction Project. (2 msgs)
                  TAPR DSP?
----------------------------------------------------------------------

Date: 17 Mar 89 01:40:42 GMT
From: killer!jolnet![e-mail]  (Brendan Kehoe)
Subject: Commodore Packet

 I've been told of a number of programs for the Commodore 64 (and/~ror 128)
that offer a packet terminal or act as a packet BBS..if any of you have or
know of such a thing, I would appreciate any information that's available.

--
Brendan Kehoe
[e-mail]    | GEnie: B.KEHOE  | Oh no! I forgot to say goodbye
[e-mail]  | CI$: 71750,2501 |  to my mind!
[e-mail] | Galaxy: Brendan |                - Abby Normal

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

Date: 18 Mar 89 05:14:31 GMT
From: ka9q.bellcore.com![e-mail]  (Phil Karn)
Subject: Headend Frequency Translators and packet

>Phil, what do you feel are the advantages of the linear crossband translator
>as opposed to the more traditional approach of using a WA4DSY modem as a bit
>regenerator in a crossband full-duplex repeater?

I was originally thinking along the lines of the bit regenerator too. What
changed my mind was a back-of-the-envelope performance analysis based the
keyup delay of the WA4DSY design (15-20 millisec). This delay has emerged as
the single largest item of channel overhead, protocol headers included. Even
without the extra delay of a regenerator, the keyup delay for a
single-packet transmission represents almost FOUR TIMES the overhead of the
TCP/IP header certain unnamed people thought was "too large" for amateur
use. (TCP/IP headers are 40 bytes; 20 millisec at 56kbps is 140 bytes. I'm
presently using a keyup delay of 150 byte times on our 220.55 MHz simplex
frequency for a little extra margin).

An even more important reason to minimize repeater delay is that it strongly
affects the probability of collisions and hence the efficiency of the
channel under heavy load. Look at Bogg's graphs of Ethernet efficiency as a
function of load and packet size. When the packets get small in relation to
the propagation delay, efficiency under load drops off. Now, "propagation
delay" in this context is the amount of time it takes for everyone to
recognize (and defer to) a transmission on the channel; it is the sum of the
cable or RF propagation delay and the modulator keyup/demod lockup times.
Unlike 10 Mb Ethernet, RF propagation delay in our case is nil (in a single
bit time at 56kbps, light travels 5.35 km, coincidentally just about the
distance from my house to our proposed repater site). But the effective
"propagation delay" of a repeater that took 20 msec to recognize and repeat
the leading edge of a packet would be almost 6,000 km.  The delay of a
linear translator will be on the order of the reciprocal of the filter
bandwidth (1/100Khz = 10 uS or so -- similar to the RF propagation delay and
therefore negligible).

In a local environment, I do not expect the S/N levels to be low enough
to give regeneration much of a compensating advantage.

I will be looking at the design of the WA4DSY modem to see if the keyup
delays can be improved. I know Dale made the transmitter half-duplex out of
fear of QRMing the receiver, but it has been my experience that the halves
are well enough isolated even when operating on the same IF that this isn't
a problem.  Apparently much of the delay is in starting the various crystal
oscillators in the transmitter, and these could be run continuously.

Phil

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

Date: 16 Mar 89 22:01:16 GMT
From: hpfcdc!hpldola!hp-lsd!hp-col![e-mail]  (Bdale Garbee)
Subject: KISS TNC Construction Project.

PE1CHL did a nice Z8530 interface for the Atari that will be supported in the
upcoming version of NET.

The Mac has an 8530 built in already, so hack together a modem and go for it.

I've never messed with an Amiga, but it shouldn't be any harder to build an
8530 interface for it than to build a TNC, and you'd have a nicer result.

Bdale, N3EUA

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

Date: 16 Mar 89 22:05:31 GMT
From: hpfcdc!hpldola!hp-lsd!hp-col![e-mail]  (Bdale Garbee)
Subject: KISS TNC Construction Project.

>I guess one could use a smaller EPROM, say 32 kbit.

KISS will fit fine in a 2716... near as I can remember.

>I cannot really see in what way a dedicated KISS TNC (with an RS232
>interface) would be cheaper or easier to build.

I think you are correct.  By far the most expense is in the sheet metal and
actual PC board, the rest of the components are fairly trivial.  Far better
to spend our design time doing nice Z8530 interfaces for the few remaining
popular machines that don't have them...

Bdale, N3EUA

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

Date: 16 Mar 89 22:10:05 GMT
From: hpfcdc!hpldola!hp-lsd!hp-col![e-mail]  (Bdale Garbee)
Subject: TAPR DSP?

>I have been hearing very little about the current TAPR project that is working
>on a DSP version of a modem for our favorite hobby.

It's coming, but slowly.  A big problem is that it's the same folks working
on the DSP project that are working on the current AMSAT microsat project...
for the most part.  The good news is that there's some commonality in some of
the digital hardware, so some problems that are being found in the AMSAT
designs will get corrected before they get commited to PCB's in the DSP
project, the bad news is that the going is slow.

I'm not closely enough in touch with the actual project to comment much
further.

73 - Bdale, N3EUA

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

End of PACKET-RADIO Digest
******************************
19-Mar-89 02:02:38-MST,1493;000000000000
Return-Path: <[e-mail]>
Date: Sun, 19 Mar 89 01:30:26 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #75
To: [e-mail]

PACKET-RADIO Digest         Sun, 19 Mar 89       Volume 89 : Issue  75

Today's Topics:
                 CP/M TCP/IP
----------------------------------------------------------------------

Date: 19 Mar 89 01:57:29 GMT
From: vega.ucdavis.edu![e-mail]  (0040;0000007265;0;340;141;)
Subject: CP/M TCP/IP

I recently acquired an NEC Starlet, model #pc-8401A.  This is a battery
powered laptop which I am going to use for portable packet.  (It's a lot easier
to carry than my Mac  :-}  )

Is there a version of Net avaialble that will run under CP/M?  I have
32K of RAM, a 32K ramdisk, and a 128k external ramdisk.  I might be
mistaken, but I think that the internal RAM can be switched to 64k
accessible, with no internal RAMdisk.

Phil?  Bdale?  Anyone else?

Thanks and 73's
Steve N6QGG

normal account: [e-mail]
TEMPRARY ACCOUNT UNTIL APRIL 1: [e-mail]

packet: n6qgg @ wa6nwe
tcp/ip: [e-mail]  [44.4.1.243]  <--active as soon as my TNC
                           upgrade arrives...any day now

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

End of PACKET-RADIO Digest
******************************
21-Mar-89 01:50:07-MST,1377;000000000000
Return-Path: <[e-mail]>
Date: Tue, 21 Mar 89 01:30:24 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #76
To: [e-mail]

PACKET-RADIO Digest         Tue, 21 Mar 89       Volume 89 : Issue  76

Today's Topics:
                 C64 PR progs
----------------------------------------------------------------------

Date: Mon, 20 Mar 89 09:34:31 MEZ
From: [e-mail]
Subject: C64 PR progs

on

>Date: 17 Mar 89 01:40:42 GMT
>From: killer!jolnet![e-mail]  (Brendan Kehoe)

writes:


> I've been told of a number of programs for the Commodore 64 (and/~ror 128)
>that offer a packet terminal or act as a packet BBS..if any of you have or
>know of such a thing, I would appreciate any information that's available.

have you had a look to the DIGICOM package ? All you need for it is a
separate modem. It will give you the features of a private BBS, through
connects with hop-to-hop-ACK for other stations, sophisticated remote
controll, comfortable file transfers etc etc.

After all it's available without charge.

73s Detlef ( DK4EG @ DK0MAV )
.

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

End of PACKET-RADIO Digest
******************************
23-Mar-89 01:59:37-MST,11676;000000000000
Return-Path: <[e-mail]>
Date: Thu, 23 Mar 89 01:30:20 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #77
To: [e-mail]

PACKET-RADIO Digest         Thu, 23 Mar 89       Volume 89 : Issue  77

Today's Topics:
               Kam modification
               Receiving packet w/o TNC
              Setting up TCP/IP
              vk2sg rtty report
           Where Can I get started... Beyond tnc-2
             XEROX 820 as a TNC?
----------------------------------------------------------------------

Date: 20 Mar 89 15:10:38 GMT
From: voder!pyramid!prls!philabs!briar.philips.com![e-mail]  (Robert Casey;6282;3.57;$0201)
Subject: Kam modification

copied from packet:

 Msg# TSP  Size Read To     @ BBS  From    Date/Time
 25987 BN   1338    2 ALL           VE3IWJ 8903/0218
 Subject: KAM mod (easy)
 Some of you might have read the bulletin I wrote about improving
 the carrier detect on the KAM. This mod greatly improves the
 reception of packet as well as prevent you from transmitting on
 top of an other signal.
 The best way to do this mod is by just soldering a 22k or 27k
 resistor across R47. R47 is a 220k resistor. It might be a bit
 difficult with out the right tools to remove the old R47. So
 leave it in and just solder the new one across it on the other
 side of the board.
 The mod changes the time constant of the rc network formed by
 C29 and R47. Which is part of the carrier detect function on hf.
 Now that it operates faster, it will do a better job. You should
 see a lot more stations while monitoring and have less retries
 while connected or trying to connect.
 I would like some feedback from people who tried this.
 73 de Nand ve3iwj @ ve3iwj.
 note: I have not tried or verified this mod, proceed at your own risk.
 WA2ISE

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

Date: 20 Mar 89 16:52:26 GMT
From: tektronix!tekecs![e-mail]  (Michael T. Horne)
Subject: Receiving packet w/o TNC

In article a recent article by [e-mail] (Tom Anna):
>
>
>Why not do it ALL in software ? Hardware requirements: 1 A/D converter
>8 bit / 8kHz, a little buffer RAM, and some TTL stuff, all together on
>a small PC plug in card. This card digitizes the audio signal from the
>receiver in a CD player style, and makes it accessible to the computer.

This can be done, but you can probably get an 8530 (or other SCC) and a
modem (e.g., 7910) for less than the price of the above hardware.  In short,
yes you can do it, but why?

>Software: Some digital filtering, a demodulator and a packet disassembler.
>If you sample the audio signal with 8K samples/sec, there is 125 mikro-
>seconds CPU time per sample: This should be enough for these tasks.

In my not-too-long-ago days, I'd say "gofer it!", but today I'd say "you're
reinventing the wheel."  If you want to do it for a learning experience, then
by all means, have at it!  If you are looking for an inexpensive (and quick)
way to get on packet, this probably isn't the way to go about it.

>Only by software changes you could also receive RTTY/AMTOR/SSTV/weather ...
>With little extra hardware you might also transmit all these modes.

Now there you go!  If you really want to support a multitude of protocols/
standards, design a board using a DSP chip (TI 32010, Motorola 56K, etc.),
an ADC/DAC, and the required glue and you're REALLY cooking! :)  Let the
host processor format the data and let the DSP chip do all the filtering and
signal generation/detection/decoding.  The AMSAT/TAPR folks are working on
a project similar to this, and I believe it really holds a lot of promise.

Mike

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

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

Date: 20 Mar 89 20:25:33 GMT
From: hpfcdc!hpldola!hp-lsd!hp-col![e-mail]  (Bdale Garbee)
Subject: Setting up TCP/IP

>I don't know who started the 'wb6cyt.ampr' custom; it's not very useful
>and it's not very correct.  I think we should stomp on it.

I think this is a holdover from when we hoped that .ampr would become a top
level domain... now that it's officially .ampr.org, I've been pushing people
to put either simple hostnames without the .ampr.org, or fully qualified
domain names only, and not anything in between... you suggestion of punting
the .ampr.org on traffic over the air for the moment seems like a good one.

73 - Bdale, N3EUA

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

Date: 22 Mar 89 02:59:07 GMT
From: osu-cis!n8emr![e-mail]  (Gary Sanders)
Subject: vk2sg rtty report

==============================================================
|               Relayed from packet radio via                |
| N8EMR's Ham BBS, 614-457-4227 (1200/2400/19.2 telebit,8N1) |
==============================================================

Bulletin ID: RTDX1703

RTTY DX NOTES FOR WEEK ENDING 17TH MARCH 1989.

THIS WOULD HAVE TO BE ONE OF THOSE WEEKS THAT WILL BE REMEMBERED FOR YEARS
BECAUSE OF THE SUN SPOTS, AND THE DEATH OF THE BANDS.  LAST WEEKEND WOULD
HAVE BEEN THE ONLY DAYS WHERE DX WAS AROUND IN THE NORMAL STRENGTH.  BUT WE
HOPE FOR BETTER CONDITIONS FOR THE B.A.R.T.G. CONTEST THIS WEEKEND.  SEE
YOU IN THE DOG PILES.

OUR THANKS THIS WEEK GO TO TG9VT, W9CD, W1DA, OD5NG, I5FLN, LA9CE, HB9CJC,
VK2EG AND OTHERS.  THE INFORMATION IS APPRECIATED.


BANDPASS

FRIDAY
6Y5PG       14086 KHZ  AT  0605Z  FEC
WA0OII/KH2  14090 KHZ  AT  1222Z
C6AAA       14081 KHZ  AT  1222Z

SATURDAY
UC1AWW      14089 KHZ  AT  0100Z
TY5PG       14089 KHZ  AT  0700Z
HV3SJ       14090 KHZ  AT  0705Z  QSL
TA5C        28092 KHZ  AT  0850Z
T5GG        28090 KHZ  AT  1420Z  QSL
5N9AE       28087 KHZ  AT  1530Z
FR5ZD       21082 KHZ  AT  1758Z  ARQ
EL2E        21088 KHZ  AT  1915Z
TI2ZW       14093 KHZ  AT  2300Z

SUNDAY
TA3D        14091 KHZ  AT  0455Z
RB5IO       14091 KHZ  AT  0500Z
P29JW       14095 KHZ  AT  0533Z
UA4HBW      14084 KHZ  AT  0538Z
UR2FU       21087 KHZ  AT  1031Z
VU2JX       28091 KHZ  AT  1033Z
DF9FA/4S7   28094 KHZ  AT  1138Z
JY9IU       28093 KHZ  AT  1323Z  QSL
6W6JX       28092 KHZ  AT  1346Z
6W7OG       28093 KHZ  AT  1400Z  QSL
5N9ABY      21091 KHZ  AT  1733Z
DL1OAX/UG6  14094 KHZ  AT  2035Z  QSL
3X1SG       14088 KHZ  AT  2056Z
SV9AKD      21090 KHZ  AT  2100Z

MONDAY
P43IDP      14079 KHZ  AT  0352Z  ARQ
5W1GZ       14075 KHZ  AT  0510Z  ARQ
RB5IO       14092 KHZ  AT  0608Z

TUESDAY
YB0QC       21082 KHZ  AT  1435Z
TA3D        14094 KHZ  AT  1845Z

WEDNESDAY
NIL

THURSDAY
NIL


QSL INFORMATION.

HV3SJ, PINO, WILL QSL VIA HIS HOME ADDRESS.  I0DUD IS HIS HOME CALL.
T5GG QSLS GO VIA I2MQB.
JY9IU, WALTER, CARDS VIA HB9AHA OR DIRECT TO WALTER HEDIGER, BOX 13143,
AMMAN, JORDAN.
6W7OG ASKS FOR QSLS VIA HIS MANAGER, F2YT.
DL1OAX/UG6 SAYS CARDS TO HIS HOME CALL, INER MUNDT, BAECKERSKAEMPEN 17,
3070 NIENBURG, FED GERMANY.
HH2PJ CARDS GO VIA BOX 13146, DELMAS, PORT AU PRINCE, HAITI.
YJ8JS SAYS TO QSL TO G0CGL.
A CORRECTION TO LAST WEEK.  THE QSLS FOR THE U.S. STATIONS WHO WORKED THE
3W1 OPERATION GO TO W4FRU NOT WA4FRU.  REPEAT, THEY GO TO W4FRU.
ALSO THE CARDS AND CONTRIBUTIONS FOR THE VU7JX OPERATION THIS WEEKEND GO
TO W2XP.


NOTES OF INTEREST.

THIS WEEKEND VU7JX WILL OPERATE DURING THE BARTG CONTEST FROM THE LACCADIVE
ISLANDS. QSL VIA W2XP.

THERE IS A REPORT THAT OCEAN ISLAND WILL BE SEPERATED FROM KIRIBATI, AND
COUNTED AS A NEW COUNTRY.

DJ6JC WILL OPERATE FROM TY6JC, BENIN, STARTING MARCH 25TH FOR ABOUT 7 DAYS.


APRIL.

5W1GP WILL BE QRV FROM ROTUMA FROM 6TH APRIL.  HIS LENGTH OF STAY IS NOT
KNOWN, BUT HE WILL BE OPERATING BATTERY EQUIPMENT.

XF4L REVILLA GIGEDO WILL OPERATE FROM 11 TH TO 19TH.  THEY HOPE FOR RTTY
OPERATION AS WELL AS OTHER MODES.  QSL TO OH2BN.

MARION ISLAND, ZS8  WILL BE ACTIVATED DURING APRIL.  EQUIPMENT HAS BEEN
DONATED BY W6PQS AND THE SOUTHERN CALIFORNIA RTTY GROUP.

MAY.

ST PETER AND ST PAULS ROCKS WILL BE ACTIVATED 3RD TO 10TH JUNE.  THE RTTY
CALL WILL BE ZY0SY.  OPERATION BY THE NATAL DX GROUP, BRAZIL.

JUNE.

TK/HB9CJC WILL OPERATE FROM CORSICA FROM JUNE 4TH TO JULY 2ND.  QSL TO HIS
HOME CALL.

JG1RVN WILL OPERATE FROM KC6, BELAU, DURING JUNE.  QSL TO HIS HOME CALL.

AUGUST.

ANGOLA HAS BEEN DELAYED UNTIL AUGUST DUE TO CHANGE OF MILITARY PERSONNEL.
QSL VIA I5ICY.


NOW FOR THE RUMOURS.  IT HAS BEEN UNOFFICIALLY REPORTED THAT TUBUAI ISLAND,
CHESTERFIELD ISLAND AND FREDERICK REEF WILL SHORTLY BE LISTED AS NEW
COUNTRIES. (??)

GL DE DX1.
Writted by Syd, VK2SG.  Forwarded via packet by Tad, KT7H @ KE7OM.
--
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: 21 Mar 89 18:48:06 GMT
From: rochester!rit!cci632![e-mail]  (Curtis Braun)
Subject: Where Can I get started... Beyond tnc-2

I've been reading about alternatives, etc to tnc's and ax.25 packet.
This is most provocative. I am not familiar with the radio part
of communications other than a frustrated usr of packet radio via
a hd4040 tnc @1200baud. I KNOW that there is a better way...

It seems to me that if a telebit modem can fly at some higher speeds,
and that the telephone industries can do ISDN (they too need a better
spec) than where can we go. Can't we do multidrop 9600+ communications
like the telephony industry. Why can't a bbs feed be multidrop, then
I won't have to "dial" ops "connect" to one, I'd have my mail on my
BOX where it belongs. With the compression techniques like PKZIP's
archiving program, why can't we incorporate it the scehme of things?
I just heard of a program called flashlink which provides mnp 4 and
mnp 5 additions to the standard modem interface (via software) to
speed up the through put? Why can't the actual packet size be variable
for higher through put? Why can't we do full duplex communications
on the radio, repeaters do it?

As you can see I have a lot of questions, it seems that some of the
local people that I have spoken to have no interest in advancing
the sport. I have found a few that are willing to do Usenet mail
via radio (probably using tcp/ip), but I have a lot ot learn.

Thanks,

    Curtis ( !rochester!kodak!n2hkd!curtis or [e-mail] ) N2HKD

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

Date: 21 Mar 89 22:49:18 GMT
From: dcatla![e-mail]  (David M. Panetta)
Subject: XEROX 820 as a TNC?

I am looking for any information which will help me convert my old
XEROX 820 cpm system for use as a TNC. I would be interested in any
hardware mods and software/firmware information. I have hardware and
software background on the 820 board, but little knowledge about the
how and what to make a TNC. I have an 820-I board with all schematics
and manuals.

Please e-mail responses to the address below. Thanks in advance and 73.


--
Dave Panetta        [e-mail] or gatech!dcatla!dndmp
Digital Communications Assoc., Inc.     [phone] (off)
1000 Alderman Dr, Alpharetta, GA 30201  [phone] (res)

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

End of PACKET-RADIO Digest
******************************
24-Mar-89 01:55:36-MST,1835;000000000000
Return-Path: <[e-mail]>
Date: Fri, 24 Mar 89 01:30:24 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #78
To: [e-mail]

PACKET-RADIO Digest         Fri, 24 Mar 89       Volume 89 : Issue  78

Today's Topics:
            Need packet bbs for SysV Unix
----------------------------------------------------------------------

Date: 22 Mar 89 15:01:04 GMT
From: mcvax!kth!draken!tut!tolsun![e-mail]  (Ari Husa)
Subject: Need packet bbs for SysV Unix

Does anybody know of a packet bulletin board system for
Unix SysV (CTIX) -based computers? The system would preferably
follow the standard RLI/MBL -procedure for forwarding
messages.

We would like to get the source code for such a beast,
and port the system on our Convergent Miniframe computer.
A complete, ready-to-run system would also be acceptable,
if there is such thing around...

Also, please, can somebody tell me the e-mail-address for
Hank, W0RLI? We would love to discuss the possibility to
get the latest source code of his bbs software. We are currently
running a WA7MBL 5.12 bbs on a pc/xt, and we are QUITE satisfied.
Anyway, a true multi connect, multi process system would be
of GREAT interest...

Thank You in advance and vy 73,

-- Luru --
--
==============================================================================
Ari 'Luru' Husa  ===  packet: oh8nup@oh8ta  ===  e-mail: so-luru.oulu.stekt.fi
mail: Tiedonkaari 6 D 25 SF-90570 OULU FINLAND  ===  phone: [phone]
==============================================================================

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

End of PACKET-RADIO Digest
******************************
25-Mar-89 01:57:15-MST,7052;000000000000
Return-Path: <[e-mail]>
Date: Sat, 25 Mar 89 01:30:30 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #79
To: [e-mail]

PACKET-RADIO Digest         Sat, 25 Mar 89       Volume 89 : Issue  79

Today's Topics:
           Headend Frequency Translators and packet
           Where Can I get started... Beyond tnc-2
----------------------------------------------------------------------

Date: 25 Mar 89 00:58:23 GMT
From: jupiter![e-mail]  (Phil R. Karn)
Subject: Headend Frequency Translators and packet

In article <[e-mail]> I wrote:
>I will be looking at the design of the WA4DSY modem to see if the keyup
>delays can be improved. I know Dale made the transmitter half-duplex out of
>fear of QRMing the receiver, but it has been my experience that the halves
>are well enough isolated even when operating on the same IF that this isn't
>a problem.  Apparently much of the delay is in starting the various crystal
>oscillators in the transmitter, and these could be run continuously.

I think I may have mislead some people with the term "half duplex". What
I *meant* to say was that the WA4DSY modem transmitter stops the crystal
oscillators (clock and RF carrier) when the RTS (Request to Send) input
line is brought inactive. Dale's intent here was to prevent possible QRM
to the receiver (which is a completely separate part of the modem) when
the two are configured to operate in a half-duplex mode on the same
frequency. Fortunately, the physical layout was done so well that it
seems this concern was largely unwarranted.  You can even saw the RF
board into two halves (one TX, one RX) and put the modulator and
demodulator into separate shielded boxes if you want, but I haven't
found this to be necessary.

The problem I was alluding to was that the keyed transmit oscillators
are apparently the major components of the 15-20 ms keyup delay;
crystals are very high-Q devices. Some trivial modifications to the
modem would allow these oscillators to run continuously, with only the
transverter actually being keyed. I will be experimenting with these
approaches in the hope of getting the keyup delay down to the 5-10 ms
range, which I understand is the acquisition time of the clock recovery
loop in the receiver. (Here there are some fundamental tradeoffs between
acquisition time and weak-signal performance, so there's a limit to the
turnaround speed of *any* modem.)

There is nothing inherently half-duplex about the WA4DSY modem design
when configured to run on different transmit and receive frequencies.
You can easily leave the RTS line to the transmitter up all the time and
receive data at the same time. There are NO components that have to be
switched between transmit and receive, so in this sense the modem is
completely full-duplex.

Sorry for any confusion.

Phil

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

Date: 24 Mar 89 18:45:49 GMT
From: jfcl.dec.com![e-mail]  (Fred R. Goldstein)
Subject: Where Can I get started... Beyond tnc-2

In article <[e-mail]> [e-mail] (Curtis Braun) writes:
>I've been reading about alternatives, etc to tnc's and ax.25 packet.
>This is most provocative. I am not familiar with the radio part
>of communications other than a frustrated usr of packet radio via
>a hd4040 tnc @1200baud. I KNOW that there is a better way...
Yes, there is.  It's hard to think of a worse way, actually, than what's
been done already!  But let's break it down into the constituent
problems.

>It seems to me that if a telebit modem can fly at some higher speeds,
>and that the telephone industries can do ISDN (they too need a better
>spec) than where can we go. Can't we do multidrop 9600+ communications
>like the telephony industry.

A valid question.  The current use of 212 modem technology is totally
absurd, but it stems from the "appliance operator" mentality.  Ten
years ago some VADGC pioneers had some surplus (already obsolete)
telco 212s to play with; it's also dirt cheap to implement, and fits
into the AF passband (mic filters and all) of commodity FM rigs.
Direct FM would fit 9600 into the same 20 kHz channelization, but
would need better modulators and receivers, and would need to bypass
the audio stages.  The Japanese rig builders don't do this, since
their big market is still voice (and not the US, either).  Hamtronics
does, but their stuff is otherwise primitive (no synthesizer).

You can do 2400 or even 4800 thru an audio system into an FM rig,
but it's not quite so tolerant of mistuning, wrong levels, etc.
And the turn-around time becomes more significant -- with allthose
relays chattering, shorter packet times get overtaken by T/R
switching time. Again a packet-oriented rig (not a voice one) could
fix that in a jif.  Taz Inoue, where are you?

>Why can't a bbs feed be multidrop, then
>I won't have to "dial" ops "connect" to one, I'd have my mail on my
>BOX where it belongs.

That's an application problem; the TCP-IP world does it better,
and some BBSs are smarter than others.  Again it's the appliance
attitude "gotta be MBL/RLI compatible" that holds people back.
There was a lot of flaming recently at the autthor of the TCP/IP
package's AX.25 mailbox subroutine, since it needed the user to hit
CR after connect.  Too tough for the AX.25 users!  (Gimme a break.)

>With the compression techniques like PKZIP's
>archiving program, why can't we incorporate it the scehme of things?
>I just heard of a program called flashlink which provides mnp 4 and
>mnp 5 additions to the standard modem interface (via software) to
>speed up the through put?

Most ham file transfers (on TCP/IP) use ARC or other compression
already.  You only need to compress once; compression does however
make data integrity more important. TCP/IP can handle it.

>Why can't the actual packet size be variable
>for higher through put? Why can't we do full duplex communications
>on the radio, repeaters do it?

Packets are variable-size already, both AX.25 and TCP/IP.
Full duplex is very beneficial; a few packeteers do use it, but
it takes a repeater-pair and repeater to do it (duplexer needed),
and the FM voice boys have pretty much claimed the 2m and many
other repeater channels to themselves already.  This is a big
problem; we do need to shake loose some repeaters!  You  then get
about 4 times the throughtput that you do from hdx digipeaters.
>As you can see I have a lot of questions,

Yes, and they're good ones!  Ham packet radio is largely in a rut.
We need people to move on from the TNC/AX.25/BBS model into some
better things (not NETROM appliances).  There is a lot of progress
already, though.  Stay tuned and plugged in.
      fred k1io

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

End of PACKET-RADIO Digest
******************************
27-Mar-89 01:40:00-MST,4898;000000000000
Return-Path: <[e-mail]>
Date: Mon, 27 Mar 89 01:30:30 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #80
To: [e-mail]

PACKET-RADIO Digest         Mon, 27 Mar 89       Volume 89 : Issue  80

Today's Topics:
              vk2sg rtty report 3/24/89
----------------------------------------------------------------------

Date: 26 Mar 89 19:17:51 GMT
From: osu-cis!n8emr![e-mail]  (Gary Sanders)
Subject: vk2sg rtty report 3/24/89

    It was suggested that I post this bulletin to rec.ham-radio
instead of rec.ham-radio.packet. I basicly decided on .packet because
both packet and rtty are "digital" modes. It dosent really matter
where I post the articles. So its up to you Do you want it posted
in rec.ham-radio or rec.ham-radio.packet?

            Thanks in advance for your comments.

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

==============================================================
|               Relayed from packet radio via                |
| N8EMR's Ham BBS, 614-457-4227 (1200/2400/19.2 telebit,8N1) |
==============================================================

RTTY DX NOTES FOR WEEK ENDING 24TH MARCH 1989
(BID RTDX2403)

FIRST, WE HOPE THAT EVERYONE HAS A VERY HAPPY AND HOLY EASTER.  WE HOPE
THE DX COMES TO YOUR SHACK IN GREAT ABUNDANCE.  IN THE NOTES YOU WILL SEE
SOME STATIONS LISTED AS 28 MHZ, ETC.  THESE WERE SOME OF THE STATIONS WHO
WERE WORKED/SEEN DURING THE CONTEST.  UNFORTUNATELY WE COULD NOT LIST ALL
THE STATIONS THAT WERE IN THE CONTEST, AS SOME OF THE STATIONS WORKED OVER
700 CONTACTS.  SO ONE MIGHT SAY THAT ALL BANDS WERE OPEN AT SOME TIME
DURING THE CONTEST PERIOD.

OUR THANKS THIS WEEK GO TO TG9VT, W1DA, KT7H, LA5WBA, OD5NG AND VK2EG.

BANDPASS:

FRIDAY.
4X6GA       14090 KHZ  AT  0450Z
EVERYONE HOLDING BREATH FOR START.

SATURDAY.
EA9JV       21083 KHZ  AT  0200Z
BY9GA       21090 KHZ  AT  0234Z
XX9KA       14087 KHZ  AT  0910Z
VU7JX       28079 KHZ  AT  0923Z  QSL
3B8FP       14090 KHZ  AT  1336Z  QSL
6W6JX       28 MHZ     AT  1403Z
9K2DZ       28 MHZ     AT  1546Z

SUNDAY
TF3KB       14 MHZ     AT  0349Z
HH2BZ       14 MHZ     AT  0417Z
FS5UQ       14 MHZ     AT  0450Z
DL1OAX/UG6  14088 KHZ  AT  0715Z
KH2/WA0OII  14 MHZ     AT  1215Z
FM5CD       14 MHZ     AT  2148Z
J73EH       21080 KHZ  AT  2245Z
VU7JX       14080 KHZ  AT  2250Z
KX6TY       28 MHZ     AT  2252Z

MONDAY
VU2SJV      14 MHZ    AT  0147Z
CN8EL       14092 KHZ  AT  2105Z

TUESDAY
HH2BZ       14082 KHZ  AT  0050Z
ZK1WL       21095 KHZ  AT  0423Z
PJ2MI       14078 KHZ  AT  1023Z  FEC
HC8VB       14082 KHZ  AT  2335Z

WEDNESDAY
DL1OAX/UG6  14091 KHZ  AT  0635Z  QSL
6Y5PG       14090 KHZ  AT  1239Z
9J2KP       21088 KHZ  AT  1900Z
3X1SG       21091 KHZ  AT  2105Z
P43SP       14093 KHZ  AT  2145Z

THURSDAY.
NIL

FRIDAY
TY9JC       14085 KHZ  AT  2350Z  QSL


QSL INFORMATION:

CORRECTION TO LAST WEEKS QSL INFORMATION, T5GG QSL MANAGER IS I2MOP.
VU7XP WILL QSL VIA W2XP.
3B8FP WILL RECEIVE HIS CARDS VIA KN2N.
DL1OAX/UG6 WILL QSL VIA HIS HOME ADDRESS.  HE WILL BE THE OPERATOR IN
ARMENIA FOR A FEW MORE WEEKS.
J73EH QSLS VIA WA4WIP.
TY9JC WILL QSL FROM HIS HOME ADDRESS OF DJ9JC.


NOTES OF INTEREST:

LA2FFA WILL BE ACTIVE FROM ABOUT 84 DEGREES NORTH FOR ABOUT SIX WEEKS USING
THE CALLSIGN OF JX0A, FROM 22ND MARCH USING PACKET AND OTHER MODES. NO
MENTION OF RTTY.

APRIL.

IT IS REPORTED THAT JIM SMITH WILL BE ACTIVE FROM OCEAN ISLAND, EITHER THE
END OF APRIL OR EARLY MAY.  IT IS HOPED THAT HE WILL THEN TRAVEL TO TUVALU
(T2) IF REQUESTED.

5W1GP WILL BE QRV FROM ROTUMA FROM 6TH APRIL.  HIS LENGTH OF STAY IS NOT
KNOWN, BUT HE WILL BE OPERATING BATTERY EQUIPMENT.

XF4L REVILLA GIGEDO WILL OPERATE FROM 11TH TO 19TH.  THEY HOPE FOR RTTY
OPERATION AS WELL AS OTHER MODES.  QSL TO OH2BN.

MARION ISLAND, ZS8 WILL BE ACTIVATED DURING APRIL.  EQUIPMENT HAS BEEN
DONATED BY W6PQS AND THE SOUTHERN CALIFORNIA RTTY GROUP.

MAY.

ST PETER AND ST PAULS ROCKS WILL BE ACTIVATED 3RD TO 10TH MAY .  THE RTTY
CALL WILL BE ZY0SY.  OPERATION BY THE NATAL DX GROUP BRAZIL.

JUNE.

TK/HB9CJC WILL OPERATE FROM CORSICA FROM JUNE 4TH TO JULY 2ND.  QSL TO HIS
HOME CALL.

JG1RVN WILL OPERATE FROM KC6, BELAU, DURING JUNE.  QSL TO HIS HOME CALL.

AUGUST.

ANGOLA HAS BEEN DELAYED UNTIL AUGUST DUE TO CHANGE OF MILITARY PERSONEL.
QSL VIA I5ICY.

GL DE DX1.

Written by Syd, VK2SG.  Forwarded via packet in North America by Tad,
KT7H @ KE7OM.

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

End of PACKET-RADIO Digest
******************************
28-Mar-89 01:58:37-MST,3993;000000000000
Return-Path: <[e-mail]>
Date: Tue, 28 Mar 89 01:30:22 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #81
To: [e-mail]

PACKET-RADIO Digest         Tue, 28 Mar 89       Volume 89 : Issue  81

Today's Topics:
            KISS PROMS for GLB TNC
           PK-232 RTTY Non-Std Shifts help
               VE3IWJ KAM Mod.
----------------------------------------------------------------------

Date: 27 Mar 89 20:20:00 GMT
From: fluke![e-mail]  (Lane Holdcroft)
Subject: KISS PROMS for GLB TNC

Several friends are running packet with GLB TNC-1's and would like to locate
KISS EPROMS to allow them to run TCP/IP.  If you have any information on a
source, please let me know.  We can also burn the EPROMS from a data file.
Thanks for your help!
73,
Lane KE7UT

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

Date: 27 Mar 89 19:36:12 GMT
From: hpda!hpcupt1![e-mail]  (Brian M. Perkin)
Subject: PK-232 RTTY Non-Std Shifts help

I am looking for someone who is very familiar
with the PK-232 Multimode box. I have been
reading the technical reference manual with
the intentions of retuning the Narrow band
transmitters and receivers to run 850 Hz
TTY shifts. I am not going to cannibalize the
1000 HZ Wide shift circuits, because I still
hope to run VHF packet. Hoping that I am
not a pioneer in this endeavour, I am looking
for advice from anyone who has been down this
path already.
Brian Perkin
hpda!bmp

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

Date: 27 Mar 89 20:25:27 GMT
From: att!alberta!dvinci![e-mail]  (Peter Hardie )
Subject: VE3IWJ KAM Mod.

I installed the VE3IWJ change to R47 in the KAM by just paralleling a 22K
resistor across R47. My experience has been that it does not significantly
improve performance under good conditions and if the band is fading a bit
then it degrades performance. If, for example, a station sends you 4 packets
in one transmission and you receive the first one or two packets at which
point the band fades out and carrier detect drops momentarily, then the KAM
will transmit an acknowledgement while the transmitting end is still sending
packets 3 and 4. I just removed the mod but perhaps a somewhat larger value
than 22K might help out.
I am still having the problem I posted before which is that on a busy channel
the KAM takes an inordinate amount of time to retry an unacknowledged packet.
If for example I send a packet and the other end does not reply, then if the
channel is busy it can take as much as 30 seconds before the KAM tries to send
the packet again and if the other end never sees the retries then with my
RETRY=7 and FRACK=2 (AND PERSIST=255!!) it can take the KAM 5 minutes before
it gives up. By that time though the other end may have already timed out and
called the next BBS (some of them only wait 2 minutes or so). I have had
replies to my previous query from 3 people (sorry I don't have names/calls
here right now) one of whom thought I had set PERSIST very low (hardly likely
OM!) and two from Europe who both have the same problem. I've also had reports
from two US sysops that they've given up on their KAM altogether and got a
PK232 so their BBS can do something useful.
Now, I know there are others out there using a KAM (perhaps?) and if you
are not having this problem I'd like to know what your KAM parameters are
set at. I find it hard to believe that more or less default parameters make
the box totally useless on a busy channel (BTW one of the European ops said
the same problem exists with the KAM on VHF too!)
ANY ideas???
Tnx + 73
Pete VE5VA @ N8GTC (28.113)
bitnet  hardie@sask
usenet  who knows any more? (ihnp4 - R.I.P.)

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

End of PACKET-RADIO Digest
******************************
29-Mar-89 01:55:21-MST,5634;000000000000
Return-Path: <[e-mail]>
Date: Wed, 29 Mar 89 01:31:09 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #82
To: [e-mail]

PACKET-RADIO Digest         Wed, 29 Mar 89       Volume 89 : Issue  82

Today's Topics:
            KISS PROMS for GLB TNC
               paccom tiny2 mod
              Trends in Packet (2 msgs)
             WA7MBL BBS and KPC-2
----------------------------------------------------------------------

Date: 28 Mar 89 17:20:05 GMT
From: fluke![e-mail]  (Lane Holdcroft)
Subject: KISS PROMS for GLB TNC

In article <[e-mail]> [e-mail] (Lane Holdcroft) writes:
>
>Several friends are running packet with GLB TNC-1's and would like to locate
>KISS EPROMS                                 ^^^^^

Oops, that should have been a GLB "PK-1".  Sorry about that!
Thanks, 73, Lane, KE7UT

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

Date: 27 Mar 89 15:03:42 GMT
From: oliveb!pyramid!prls!philabs![e-mail]  (Usenet News)
Subject: paccom tiny2 mod

From: [e-mail] (Robert Casey;6282;3.57;$0201)
Path: briar.philips.com!rfc

       Further to N2EZG's bulletin on constructing an adapter for
       the modem socket to improve the performance of Tiny-2 (and
       Micropower-2) TNCs that have become "hard of hearing": Gwyn,
       W1BEL, of PacComm advises that those not wanting to roll
       their own can call and they'll send an adapter, free of
       charge.  Not all of the TNCs exhibit the problem, and recent
       revs of the TNC boards already have the mod (which inverts
       the phase of a clock signal) in place, so don't bother
       unless you are actually noticing degradation of the modem
       performance.

       73, Barry VE3JF@VE3JF

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

Date: 28 Mar 89 15:41:50 GMT
From: m2c!ulowell!tegra![e-mail]  (Johnathan Vail)
Subject: Trends in Packet

I am thinking of getting back into Packet Radio using TCP/IP.  As I
see it 1200 baud is painful at best and if it isn't already will be
obsolete soon.  I have been following things a bit and it seems like
there are several modems becoming reasonably available.  I believe
there is onw that claims to get 4800 baud on most radios with minimal
tweaking.  And I have seen 9600 baud advertised and discussed as well.
I feel the really high speed stuff won't be used for genreal
communication but for backbones and bridges.

What modems are available now and that will become the "next thing"?

Also, can anyone point me to some local (MA/NH) groups that are doing
TCP/IP.

Thanks.... jv

"The death of God left the angels in a strange position."
 _____
|     | Johnathan Vail  | tegra![e-mail]
|Tegra| [phone]  | N1DXG @ 145.110-, 145.270-, 448.625-
 -----

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

Date: 29 Mar 89 00:52:57 GMT
From: cs.utexas.edu!swrinde!dpmizar!dptudg![e-mail]  (Lee Ziegenhals)
Subject: Trends in Packet

In article <[e-mail]> [e-mail] (Johnathan Vail) writes:
>
>I am thinking of getting back into Packet Radio using TCP/IP.  As I
>see it 1200 baud is painful at best and if it isn't already will be
>obsolete soon.  I have been following things a bit and it seems like
>there are several modems becoming reasonably available.  I believe
>there is onw that claims to get 4800 baud on most radios with minimal
>tweaking.  And I have seen 9600 baud advertised and discussed as well.
>I feel the really high speed stuff won't be used for genreal
>communication but for backbones and bridges.
>...

We have just begun testing the HAPN 4800bps modems in the San Antonio
area.  These are on 70cm for user access (primarily TCP/IP, at least
initially).  They have not been installed long enough to give an exhaustive
review, but so far we are fairly pleased with them.

The thing that attracted us most about the HAPN boards was the cost: $45
for a kit that installs inside your TNC2.  Construction was fairly easy,
and installation in the TNC straightforward.

On the down side, you must modify your radio "take-off" points.  The
receive audio must come directly out of the discriminator, and the transmit
must go straight to the modulator (will work with either FM or PM).  On the
other hand, I am now using the same points for 1200bps as well, and with a
minor mod to the TNC, it works even better than going through the mike
connector.  Also, you can install a simple SPST switch to change from 1200
to 4800 instantly.

I would enjoy hearing from folks who have tried some of the 9600bps modems.
I will post more information on the performance of the HAPN boards after
they have been in use for a while.

--

73, Lee - n5lyt

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

Date: 26 Mar 89 22:17:52 GMT
From: thumper!gamma!mibte![e-mail]  (James Cook)
Subject: WA7MBL BBS and KPC-2

    Hello, I am having a real problem getting Ver 5.12 of MBL's
BBS to work on a KPC-2.  The DCD lead on the EIA-232 seems to be the
problem, have to dummy up the lead to make the PC talk to it.  I have
used the BBS on a PK-232 with no problems.  What I am asking is for
someone to mail me the settings for the KPC-2 when used with MBL bbs. I
would also like to hear from anyone that is using this BBS software.

Thanks
Jim Cook N8JBO

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

End of PACKET-RADIO Digest
******************************
30-Mar-89 02:16:06-MST,6683;000000000000
Return-Path: <[e-mail]>
Date: Thu, 30 Mar 89 01:30:32 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #83
To: [e-mail]

PACKET-RADIO Digest         Thu, 30 Mar 89       Volume 89 : Issue  83

Today's Topics:
               TCPIP for Amiga
                tnc's
               Trends in Packet
             trends in packet ( modems )
----------------------------------------------------------------------

Date: Wed, 29 Mar 89 11:59:17 BST
From: John Heaton 061-275-6011 <[e-mail]>
Subject: TCPIP for Amiga


Hi,

I am running a Commodore Amiga A500 withe the 870829.24 release of the
KA9Q TCP/IP Internet package, and I am now feeling left behind as quite
a few of my friends are using much later and more sophisticated versions
(871225.33m etc!). What I was wondering is, Does anyone know of a later
version for the Amiga.

John Heaton           G1YYH

EARN/BITNET: J.Heaton%UMRCC.ac.uk@UKACRL
DARPA:       [e-mail]
Packet:      G1YYH @ GB7NWP
AMPRnet:     g1yyh.ampr.org [44.131.1.8]

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

Date: 28 Mar 89 21:46:18 GMT
From: cs.utexas.edu!sm.unisys.com!ism780c![e-mail]  (Kirk Davis)
Subject: tnc's

I'm looking into buying a tnc. I was wondering if I could get some
feed back from some people that may have these models:

Pac-Comm:       Looks good... seems to support alot of stuff (netrom
        kiss, UHF/VHF & HF).  Also farly cheap ($119 for the
        Tiny-2 & $159 for the mp-2). But is it any good?

Pakratt-232:    Seems to do it all. Also seems like alot of people
        are using them. But at ~$320 is it worth it?

heath pocket packet:
        Looks real neat, but it doesn't do netrom or HF. ($219)
        (73 has a good review of this in their march edition)

KAM:            Haven't found much info, but they say they're the best.
        Does anyone have anything to say about um?

I would like to get something good for portable use... Yet I would still
like it to be some what flexable. The heath is too much of a trade off.
The pac-comm mp-2 may be the one, but I don't know if it's any good. Does
anyone have any thoughts?

----
[e-mail]

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

Date: 29 Mar 89 16:39:20 GMT
From: tektronix!orca!tekecs![e-mail]  (Mike Horne)
Subject: Trends in Packet

John, you're correct WRT running TCP/IP over 1200 bps packet links; it's
painful at best.  Going to the 4800 bps modems from HAPN (or other) will
make your throughput a little better, but don't expect a 4X performance
increase.  Going to 9600 bps will see somewhate better performance.  All of
this falls apart if your transmitter or receiver (or the other guy's set)
is slow to key up or turnaround.

Of course, the Heatherington modems (56kbps) are available, and others are
doing work on higher speed modems.  Bdale Garbee is working with another
individual on "10 GHz Ethernet."  If you're interested, I'm sure you can
hack around with other high-speed possibilities.

Your assumption that high speed stuff won't be used for general communications
may be true for the regular rtty-packet folks, but I'd love to have a local
comm channel running at 1 Mbps or greater with several hosts on it.  A lot
of us would like to link our PC's and UNIX boxes together so we can do
some "real work" (so to speak); the slower speeds make it difficult, if not
impossible.

By all means, John, don't let 1200 bps modems scare you away from amateur
TCP/IP!  It's an exciting part of packet that is seeing very impressive growth.

Mike

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

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

Date: Wed, 29 Mar 89 16:36:30 MEZ
From: [e-mail]
Subject: trends in packet ( modems )

on

>Date: 28 Mar 89 15:41:50 GMT
>From: m2c!ulowell!tegra![e-mail]  (Johnathan Vail)

writes

>Subject: Trends in Packet

> [.........]
>                I have been following things a bit and it seems like
>there are several modems becoming reasonably available.  I believe
>there is onw that claims to get 4800 baud on most radios with minimal
>tweaking.  And I have seen 9600 baud advertised and discussed as well.
>I feel the really high speed stuff won't be used for genreal
>communication but for backbones and bridges.

>What modems are available now and that will become the "next thing"?

Since springtime  of '87 there are the NORD><LINK modems available
( developed by myself ).
These modems utilize a DPSK modulating scheme which is modeled after
the CCITT V.26. At a subcarrier of 1800 Hz and at a baudrate of 2400 Bd
there's a  datarate of 4800 bps  available ( dibit-encoding scheme  )
or 4800 Bd / 9600 bps.

 Some highlights of this modems are:
no DC component in signal at any time, so lowest AF of xferchannel
is > 400 Hz.
fast synchronisation time of modem : < 5 msec ( @ 4800 bps )
     ( faster at higher speeds )
no squelch required, therefor no squelch delay ( usually 50...150 msec )
interface conforms to CCITT X.21bis ( similar to RS232 ), TTL level
     signals available by means of some jumpers.
modem supplies rx and tx clock.
only standard CMOS-ICs required,
only 1 PS ( +10...+14V ) necessary ( < 3 W ).

Several of these modems are running here since some time with no general
problems so far. The modems are tested on TNC1s and different TNC2 clones.

Like all modems for higher speed these DPSK modems have to be pluged
to a separate data input / output connector at the TRXs.
Future intentions are to provide a dualmode uplink at the nodes so
users might use 202 1200 bps or DPSK 4800 bps on the same frequency.
But this isn't finished yet.

Detlef ( DK4EG @ DK0MAV )
.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

#include <disclaimer.std>


 Detlef J. Schmidt                [phone]
 Computing center
 University Brunswick
 P.O.B. 3329
 D-3300 Braunschweig
 F.R.G.

C0033003 at dbstu1.bitnet
 [e-mail]
 [e-mail]
 CUNYVM.CUNY.EDU![e-mail]
 ..!mcvax!unido!DBSTU1.bitnet!c0033003
etc...
.

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

End of PACKET-RADIO Digest
******************************
31-Mar-89 02:22:09-MST,2081;000000000000
Return-Path: <[e-mail]>
Date: Fri, 31 Mar 89 01:30:51 MST
From: [e-mail]
Reply-To: [e-mail]
Subject: PACKET-RADIO Digest V89 #84
To: [e-mail]

PACKET-RADIO Digest         Fri, 31 Mar 89       Volume 89 : Issue  84

Today's Topics:
           Is there a list of packet bbs's?
           To Jim, W2XO about the CTIX BBS
----------------------------------------------------------------------

Date: 29 Mar 89 02:51:13 GMT
From: osu-cis!killer!jolnet![e-mail]  (Brendan Kehoe)
Subject: Is there a list of packet bbs's?

 Is there a list of not only packet bbs', but of regular boards that're
packet-oriented available?

Thanks..


--
Brendan Kehoe
[e-mail]    | GEnie: B.KEHOE  | Oh no! I forgot to say goodbye
[e-mail]  | CI$: 71750,2501 |  to my mind!
[e-mail] | Galaxy: Brendan |                - Abby Normal

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

Date: 30 Mar 89 12:50:25 GMT
From: mcvax!kth!draken!tut!tolsun![e-mail]  (Ari Husa)
Subject: To Jim, W2XO about the CTIX BBS

Hello, Jim!

About the CTIX BBS program...

Thank you for your answer! I did receive your mail, but somehow I don't seem
to get my reply through... it just keep on bouncing back time after time.
the [e-mail] claims your host to be unknown. Any
ideas how to get through, anyone? It would be greatly appreciated!

My apologies to everyone for this posting. I did try, HONESTLY.. ;-)

73 de Luru
--
==============================================================================
Ari 'Luru' Husa  ===  Packet: oh8nup@oh8ta  ===  E-mail: [e-mail]
Mail: Tiedonkaari 6 D 25 SF-90570 OULU FINLAND  ===  Phone: [phone]
==============================================================================

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

End of PACKET-RADIO Digest
******************************