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

Text File | 1993-12-31 | 319.9 KB | 8,041 lines

Sat,  1 Jun 91 04:30:04 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #137
To: packet-radio


Packet-Radio Digest         Sat,  1 Jun 91       Volume 91 : Issue 137

Today's Topics:
             KA9Q under Unix - now what?
            Packet Mailing Address

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

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

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

Date: 31 May 91 05:28:20 GMT
From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!pitt!w2xo![e-mail]
Subject: KA9Q under Unix - now what?
To: [e-mail]

In article <[e-mail]> [e-mail] (Clay Jackson) writes:
>Well - I now have the KA9Q Net software (which, BTW is better than  a
(stuff deleted)
>
>1)  What do I do next?  I have any IP address, but I have no idea where
>there are any other IP hosts and how I might connect to them.  I'd like
>to test ftp, and work on getting SMTP (which should be a real trick,
>as those of you who have worked with MMDF can appreciate) working.
>
If no one near you is interested in tcp/ip, you can set up
'net' to use the net/rom 'network' to pass your IP packets
to someone accessable via net/rom. There are no full-time
tcp/ip stations here in the Pittsburgh area, but I have
good luck with SMTP to central PA and down to WVA.

With the back-off algorithmn that the KA9Q stuff uses, it
is very tenacious and will 'get the mail through' if there
is any kind of path at all, so it is usable over moderately
long distances on the 'network'.

>2)  The version of net I have seems pretty old (a lot of the commands
>documented in the stuff I have don't work, like tip).  It
>announces itself as version 890421.1a (n3cvl unix test).  Is there a
>later version somewhere (I got this one from WB3FFV?  I'd need
>either an anonymous uucp site or a packet FTP (assuming I get ftp
>working ;-) ) site.

This is the 'official' Unix version of Net. Bob , N3CVL, is the
person who is coordinating the Unix end of things for the project.
Anders (SM0...whoops forgot his call!) has done some work with
NOS for unix. He is here in Pittsburgh at CMU doing some kind
of sabbatical or something.

I would suggest e-mail to Bob, N3CVL ([e-mail]).

>
>73!
>--
>Clay Jackson - N7QNM
>US WEST NewVector Group, Inc
>[e-mail] | ...uunet!uswnvg!cjackso

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

Date: 31 May 91 15:46:15 GMT
From: usc!cs.utexas.edu!ut-emx!ccwf.cc.utexas.edu![e-mail]
Subject: Packet Mailing Address
To: [e-mail]

I live in Austin, and am using N5PSW as my 'full-service' PBBS.
What do you reckon my address is? something like: [e-mail] ?
Are there any non-standard pound sign thingys (#) that I might put in there
to make routing easier? e.g. for Central Texas?
If you are fairly sure of the proper address, would you drop me a note
on packet? Thanks!
73 de David
[e-mail]
[e-mail] <<<< ?

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

End of Packet-Radio Digest
******************************
Date: Sun,  2 Jun 91 04:30:08 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #138
To: packet-radio


Packet-Radio Digest         Sun,  2 Jun 91       Volume 91 : Issue 138

Today's Topics:
               PACKET->Internet Gateway
             Undeliverable mail (2 msgs)

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

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

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

Date: 31 May 91 00:47:51 GMT
From: swrinde!zaphod.mps.ohio-state.edu!menudo.uh.edu!nuchat!farwest![e-mail]
Subject: PACKET->Internet Gateway
To: [e-mail]

Organization: San Diego State University Computing Services

Don't know if the other message/article was posted here, so I'll request again.
Does anyone know if a PACKET (either AX.25 and/or TCP/IP) gatewaye exists
between PACKET radio and Internet?  If so, could someone please state where it
is located?  If not, why has this not been performed?  Additionally, what would
be needed in getting set up?

Robert S. Radvanovsky, KC6ONL
o


 * Origin: Two Wheelers  bikie hangout (1:106/88.0)

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

Date: 1 Jun 91 23:30:00 GMT
From: [e-mail]
Subject: Undeliverable mail
To: [e-mail]

Your message could not be delivered to:

    POLDER@WOLGA

Your message has been enqueued and undeliverable for 3 days.
The mail system will continue to try to deliver your message
for an additional 9 days.

The beginning of your message follows:

Date: Wed, 29 May 91 15:45 MET
From: [e-mail]
Subject: Packet-Radio Digest V91 #134
To: POLDER@WOLGA
Message-id: <[e-mail]>
X-Envelope-to: POLDER@WOLGA
X-VMS-To: Gerrit Polder PA3BYA <[e-mail]>

Packet-Radio Digest         Wed, 29 May 91       Volume 91 : Issue 134

Today's Topics:
           AX.25 Packet TNC Timing Parameters HELP!

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

Date: 1 Jun 91 23:30:00 GMT
From: [e-mail]
Subject: Undeliverable mail
To: [e-mail]

Your message could not be delivered to:

    POLDER@WOLGA

Your message has been enqueued and undeliverable for 3 days.
The mail system will continue to try to deliver your message
for an additional 9 days.

The beginning of your message follows:

Date: Wed, 29 May 91 15:40 MET
From: [e-mail]
To: POLDER@WOLGA
Message-id: <[e-mail]>
X-Envelope-to: POLDER@WOLGA
X-VMS-To: Gerrit Polder PA3BYA <[e-mail]>

remote execution        [uucp job mwoodA1d65 (5/29-7:53:00)]
    rmail attcc!ulab!area88!tom
exited with status 2

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

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


Packet-Radio Digest         Mon,  3 Jun 91       Volume 91 : Issue 139

Today's Topics:
              NET/MAC v2.2 and sys7.0 ?
                 Test
              Undeliverable mail
            WA8DED firmware for KPC2, TNC2

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

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

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

Date: 3 Jun 91 04:31:58 GMT
From: [e-mail]
Subject: NET/MAC v2.2 and sys7.0 ?
To: [e-mail]

Does system7 find NET/MAC 2.2 palatable?  What about B's Mailer?
Any other surprises from the new/improved/kinder/gentler op sys?

Thx,  Jim  N2MPT   (took 1 day shy of 6 weeks...)



----------------------                                   |\  | |
Jim Sandoz trading as [e-mail]       | | | |
 Drexel University Dept of Mechanical Engineering        |/. |_|.

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

Date: 3 Jun 91 03:54:23 GMT
From: mintaka!bloom-beacon!bu.edu!wang!tosspot![e-mail]
Subject: Test
To: [e-mail]

Test.

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

Date: 2 Jun 91 23:31:00 GMT
From: [e-mail]
Subject: Undeliverable mail
To: [e-mail]

Your message could not be delivered to:

    POLDER@WOLGA

Your message has been enqueued and undeliverable for 3 days.
The mail system will continue to try to deliver your message
for an additional 9 days.

The beginning of your message follows:

Date: Thu, 30 May 91 14:05 MET
From: [e-mail]
To: POLDER@WOLGA
Message-id: <[e-mail]>
X-Envelope-to: POLDER@WOLGA
X-VMS-To: Multiple recipients of <[e-mail]>


pr
gen
info

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

Date: 3 Jun 91 00:01:00 GMT
From: [e-mail]
Subject: WA8DED firmware for KPC2, TNC2
To: [e-mail]

Can someone tell me where WA8DED host mode firmware for a TNC2 clone is
available (besides TAPR)?

Also, is the WA8DED firmware available for a Kantronics KPC2?  If so, where
can it be found?


Tnx, Charles AA5AV

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

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


Packet-Radio Digest         Tue,  4 Jun 91       Volume 91 : Issue 140

Today's Topics:
                BAYCOM
            NET/Mac and SYSTEM 7.0
               PACKET->Internet Gateway

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

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

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

Date: 3 Jun 91 15:34:06 GMT
From: [e-mail]
Subject: BAYCOM
To: [e-mail]

   I recently found a copy of BAYCOM on a local BBS, and was
wondering if anyone (here in the U.S.) had the schematics for the
circuit described in the documentation?

   Also, does anyone know if the author is still at the address
listed in the documentation?  I will probably want to send him the
$20DM he is asking...but don't want to go to all the trouble of
getting foreign currency, just to have my letter returned to me.

     -Erik (kb2lzd) Seielstad

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

Date: 3 Jun 91 19:58:31 GMT
From: [e-mail]
Subject: NET/Mac and SYSTEM 7.0
To: [e-mail]

Hello Jim,

NET/Mac has run fine on SYSTEM 7.0 ever since the first Alpha-release...

I suggest you migrate to SYSTEM 7.0 as soon as possible, and I'm sure
you'll encounter A LOT of very pleasant surprises there. Just DO IT!

73 de
  __
 /_/  _/  _   ___
/ / (_/ (_/ / / /

+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+
|Please send your reply to:               |Goes to |Mac  |Software  |
+- - - - - - - - - - - - - - - - - - - - -+- - - - + - - + - - - - -+
|TNO ZP-LAN:adam@tnoal1   (134.221.130.16)| office |SE   |NCSATelnet|
|  internet:[e-mail]            |  same  |same |   same   |
|        or:[e-mail]          |  same  |same |   same   |
|    bitnet:[e-mail]        |  same  |same | DynaComm |
| Ham-radio:pa2aga@pa2aga   (44.137.32.9) |my place|IIx  | NET/Mac  |
|        or:pa2aga@pa2aga-1 (44.137.32.61)|  same  |Plus | NET/Mac  |
|        or:pa2aga@pa2aga-2 (44.137.32.19)|  same  |512Ke| NET/Mac  |
|        or:pa2aga@pi8mac   (44.137.32.22)|  same  |SE/30| NET/Mac  |
|   Ham BBS:[e-mail]          |  same  |any/4| NET/Mac  |
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+

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

Date: 2 Jun 91 00:00:19 GMT
From: usc!sdd.hp.com!zaphod.mps.ohio-state.edu!menudo.uh.edu!lobster!nuchat!farwest![e-mail]
Subject: PACKET->Internet Gateway
To: [e-mail]

Organization: San Diego State University Computing Services

Don't know if the other message/article was posted here, so I'll request again.
Does anyone know if a PACKET (either AX.25 and/or TCP/IP) gatewaye exists
between PACKET radio and Internet?  If so, could someone please state where it
is located?  If not, why has this not been performed?  Additionally, what would
be needed in getting set up?

Robert S. Radvanovsky, KC6ONL


 * Origin: Two Wheelers  bikie hangout (1:106/88.0)

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

End of Packet-Radio Digest
******************************
Date: Wed,  5 Jun 91 04:30:08 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #141
To: packet-radio


Packet-Radio Digest         Wed,  5 Jun 91       Volume 91 : Issue 141

Today's Topics:
               Converting modem to TNC
        new 220 band plan in SoCal - bend over
            Thoughts on BBS authentication
             Undeliverable mail (2 msgs)

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

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

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

Date: 5 Jun 91 02:12:49 GMT
From: uupsi!rodan.acs.syr.edu![e-mail]
Subject: Converting modem to TNC
To: [e-mail]

Hello,

    I have a USRobotics DIRECT 1200 modem that I don't use any
more. I was wondering if there was any way I could convert it to work
as a TNC. It has an RS232 port, and 2 RJ11 sockets.

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

Date: 4 Jun 91 13:37:45 GMT
From: [e-mail]
Subject: new 220 band plan in SoCal - bend over
To: [e-mail]

I've not yet seen the precise band plan that was approved at the recent
220 frequency coordinating meeting here in So Cal (which in itself is
rather strange - you'd think that would be made public almost immediately).

However, reports are that the plan keeps all the existing repeater
allocations intact.  That is, 222 to 222.01 is set aside for weak
signal (EME, etc), and that 222.02 thru 223.38 are repeater inputs,
and 223.62 thru 224.98 are repeater outputs.

I'm told that packet radio gets 223.54 thru 223.60 (4 channels), but
that packet doesn't retain it's current busiest channel, 223.42.

That means that, if reports are correct, all existing links, FM
simplex, SSB, AM, CW, and other uses of the band have simply been told
to fit in the area from 223.39 thru 223.53, or else to just piss off.

There's no room for 56kb packet, spread spectrum, or satellites, except
(of course) to simply place them on top of or between repeater inputs
and outputs.

The vote was something like 67 to 1 in favor; even the packet radio
representatives were duped into giving up the other plans that would
have allowed even ONE 56kb channel (down from the two that had been
available before the band shrunk).

I have to congratulate the repeater owners who managed to get this plan
approved (no other plans were even voted upon, it is reported).  They
have come up with what will undoubtedly be the most ignored band plan
in southern California history.
    - Brian

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

Date: 4 Jun 91 17:43:23 GMT
From: epic.bellcore.com![e-mail]
Subject: Thoughts on BBS authentication
To: [e-mail]

I've had several requests for the "white paper" on cryptographic
authentication of BBS messages that I wrote recently in response to a query
by Paul Rinaldo, W4RI, of the ARRL. Paul is the chairman of the ARRL Digital
Committee, of which I am a member.

In case anybody can't tell, the opinions expressed here are my own.
--Phil

Paul,

This is in response to your request to the Digital Committee for
comments on authentication schemes that might be used to verify the
source and integrity of a message posted to an amateur BBS network.
This letter consists of a quick tutorial on the various forms of
cryptographic authentication, some personal judgements about their
practicality and suitability for the problem at hand, and some personal
opinions on the present regulatory situation.

The scheme that I talked about at the 1987 ARRL Networking Conference
was for authenticating IP datagrams using DES, but the same principles
apply to using any conventional secret key cipher to authenticate any
kind of message. (By "authenticate a message", I mean verifyng that the
message was in fact sent by the claimed sender, and that the message
contents have not be modified along the way.) Such schemes require all
the stations involved to share a single secret key.  Without the key
you cannot compute the proper authenticator for the messages you send,
nor can you verify an authenticator received with an incoming message.

The difficulty of key management with a conventional cipher can range
from "trivial" to "intractible" depending on the application. Key
management is simple as long as there are only a few stations that need
to generate or authenticate messages, and all trust each other. For
example, a DES-based scheme could be applied to a repeater to limit
remote control to a few trusted stations. A single key known to the
repeater would be shared by the control stations and kept secret from
everyone else. An in-person meeting or the telephone would suffice for
distributing the DES keys.

Now consider cases where the operators do not necessarily trust each
other, e.g., autopatch operation. Since many more stations use an
autopatch than control the basic operation of the repeater, its owners
may want individual accountability. A DES-based authentication system
could still work if each user has his or her own key. The same system
could be used to control access to a BBS. In either case, the "server"
(the repeater or BBS) keeps a complete list of keys for all authorized
users and logs each access. This is more work than the previous case,
but it is still entirely practical.

Common to the all these schemes so far is the assumption that only the
server needs to authenticate a request, e.g., the repeater controller
or the BBS. It must protect its users' keys against unauthorized
disclosure, but since the resource being protected by the authentication
system is the server itself, the owner of the server has an incentive
to do this.

But in the more general case where individual pairs of stations must be
able to authenticate each other, things get much more complicated. Each
pair has to have a key that is known only to that pair; if you have N
stations, you need a total of N^2 keys. All these keys must be
exchanged by some secure means before authentication can occur, and
they must be kept secret. To do this for every pair of amateurs in the
world is clearly impractical. And if you want *any* amateur to be able
to verify the authenticity of, say, a broadcast BBS message (to carry
on the amateur "self-policing" tradition, of course), there is *no*
solution using conventional cryptography - the same key needed to
verify a message could be used to forge one.

Some form of secret key authentication might still be practical between
neighbors in a packet backbone or a BBS autoforwarding network. But
this would only authenticate your immediate neighbors; it would not
authenticate the origins of the traffic they pass from other nodes. For
example, one BBS sysop could create illegal traffic and then pass it to
a neighbor claiming that it originated somewhere else, and there would
be no way to disprove this. So you really do want the authentication to
be "end to end", not "hop by hop", and we're left with an unsolved key
management problem.

One way to reduce the N^2 key problem is to establish a "key
distribution center" that maintains a list of all the users' private
keys. Users wishing to authenticate themselves to each other do so by
first authenticating themselves to the KDC. The KDC then generates a
"session key" (a random number) and sends it to the two parties
encrypted in their own keys. The parties then decrypt the session key,
yielding a shared secret that can be used for authentication. Still,
only the parties involved can authenticate each other; someone
listening in could not. (In most environments, this is an advantage;
somebody else's conversations are none of your business.)

MIT has developed a system based on this model called "Kerberos"; it is
in operation at MIT and elsewhere (the code is free). Nevertheless, it
has the drawback that authentication depends on the availability and
reachability of the KDC. But the fact that the KDC must have a complete
list of the users' private keys works against deploying multiple KDCs
with copies of the database for redundancy; the more KDCs there are,
the more opportunities for the database to be compromised. The scheme
also assumes that all of the parties (the two users and the KDC) have
the ability to communicate with each other in real time, a bad
assumption for amateur packet radio.

So the inescapable conclusion is that authentication schemes based
solely on private key cryptography are of limited utility in amateur
packet radio; they cannot solve the general problem. Fortunately, there
is a new alternative: public key cryptography (PKC). In PKC, the keys
used for encryption and decryption are different. Furthermore,
knowledge of the encryption key, Ke, does not imply knowledge of the
decryption key, Kd; in fact, the algorithms ensure that it is extremely
difficult to determine Kd from Ke. The combination of Ke and its
corresponding Kd is called a "key pair"; for this reason, public key
cryptosystems are sometimes called "dual key" ciphers, as opposed to
"single key" ciphers like DES.

The leading public key scheme, RSA, was invented by Ron Rivest, Adi
Shamir and Len Adelman while at MIT. They hold a US patent on it that
is being exploited by RSA Data Security, Inc. (There is no patent
protection on RSA outside the USA).

The original idea behind RSA was to allow you to publish Ke (hence the
name, "public key" cryptography) so anyone could send you a secret
message without prior arrangement.  As long as you keep Kd secret, only
you can decrypt it. But when used "backwards", RSA can also do
authentication. If you encrypt a message using Kd (your DECRYPTION key,
known only to you), then anyone can decrypt it using your Ke (your
public ENCRYPTION key). Anyone who decrypts such a message then knows
that whoever generated it must have known your Kd. This procedure of
using RSA in reverse is called "signing".

In practice, it is not desirable to run an entire message through RSA
to authenticate it because it is very slow, much slower than secret key
ciphers like DES.

There is a better way. Functions exist to quickly "hash" a message of
arbitrary length into a relatively small, fixed size "message digest".
They are much like cyclic redundancy codes (CRCs) except that they are
much more complex because they are designed to detect intentional
"transmission errors" as well as natural ones.  With a good function,
it is computationally infeasible even for someone who knows it to
produce two messages that hash to the same value, or to determine the
input that produces a given value. They are not ciphers, because they
have no key and their outputs cannot be "decrypted".

One message digest algorithm is MD4 ("message digest #4") by
Ron Rivest, who has placed it in the public domain. MD4 takes a message
of any length and produces a 128-bit (16 byte) result. Rivest
conjectures that it would take on the order of 2^64 operations to find
two inputs that hash to the same value, and 2^128 operations to find an
input that hashes to a given value. These are impressive numbers, so if
the algorithm holds up under analysis it should be quite secure in
practice.

Given RSA and MD4, one authenticates a message by first computing its
hash code with MD4. Then RSA is used to "sign" the hash code (by
encryption with the sender's private key, Kd) and the result is appended
to the message. The party wishing to authenticate the message also
computes the message digest. It then decrypts the encrypted message
digest received with the message (using the published key of the
sender, Ke) and compares it to the value it has just computed. If they
match, the message is genuine.

There still remains the problem of distributing the public keys.
Although they may be freely read by anyone, they must still be
protected against modification. Otherwise someone might forge a
signature of a message under someone else's name using a public key/
private key pair of his own creation; if the receiver can be duped into
accepting this bogus public key, then he will believe that the
signature is genuine.

One way is to publish the public keys as widely as possible, in so many
places that no one could possibly modify all of the copies of a
particular key that reach the intended target of a deception. For
example, the keys could be published on CD-ROM, or they could be listed
in the back pages of QST. But these schemes have two drawbacks: cost
and time.

Another refinement, "certification", addresses this problem. If a
"certifying authority" can be set up to sign the public keys of
individual users with its private key, then only the public key of the
certifying authority needs to be widely published. For example, the
ARRL might select and publish its own public key in QST. It could then
accept public keys from individual amateurs (accompanied with some
non-cryptographic form of authentication, such as a notarized
statement). The ARRL would sign the individual public keys with its
private key and return the results. Note that the ARRL need NOT know
the individual's private keys.

The signed public keys are known as "certificates". They can be
distributed by the users themselves (e.g., in a mail header) because
anyone can readily verify their authenticity with the published ARRL
public key. This eliminates the need for an online KDC. The ARRL's
workload might be a problem, but a solution exists for this too: a
hierarchy of certifying authorities. For example, each League Division
might act as the certifying authority for the amateurs in its area,
using a Division public key that has been certified by ARRL HQ.
Divisions might further delegate the workload to their constituent
Sections. The verification of an individual user's certificate would
therefore require the certificates of all of the certifying authorities
in the hierarchy as well as the published key of the ARRL.

So in theory, anyway, authentication based on public key cryptography
solves many of the problems associated with the earlier secret key
schemes. However, many practical obstacles would still remain:

1. The RSA algorithm is patented in the USA, and the owners of the
patent are holding it fairly close to their chest. Negotiations between
RSA and the Internet Activities Board (IAB) have been dragging on for
several years now over an agreement for the use of RSA in the Internet.
It is not at all clear how much the patent royalties will be, or how
they will be charged. (The leading theory is that the royalties will be
tied only to the issuance of certificates, not to the actual
implementation or use of RSA, but this is not yet final.) Would the use
of RSA in amateur packet radio (resulting in the payment of royalties
to RSA DSI) be considered as furthering the "regular business affairs"
of RSA DSI? (Hopefully not, but considering some of the FCC rules
interpretations we've been seeing lately...)

2. The algorithms are, by amateur standards, quite complex. At a
minimum, they would probably require every amateur to have a PC-class
computer to hash and sign messages. Given that a major reason TCP/IP is
still a relatively esoteric mode in amateur packet radio is the
reluctance of many amateurs to upgrade from C-64s and "dumb terminals",
it seems unlikely that universal user authentication could happen any
time soon. And I won't even *begin* to discuss the user education
issues.

3. Even if a full-blown RSA-based authentication system as described
earlier could be deployed, it is not clear that it would solve the
specific problem that originally prompted your query. Someone accused
of posting an illegal message to an amateur BBS could still claim that
his secret key had been stolen and used by someone else. Or he could
accuse the local "Section Certification Manager" of signing a bogus
public key with his callsign on it and using it to "frame" him by
sending verboten traffic. Even if a key really has been stolen and the
owner notifies the certification authorities, how do they spread the
word that the previously distributed public key is no longer valid?
These issues are still the subject of much discussion in the research
community. Furthermore, this technology has yet to have its first test
in a court of law.

In sum, although I find cryptographic authentication to be a
fascinating topic that has some potential for use in amateur radio, I
do not feel that it is "ready for prime time". Mandating its use at
this time would be an enormous overreaction to the "problem" of
controlling inappropriate BBS traffic.

Quite frankly, the FCC's heavy-handed behavior in this case has me
greatly concerned. I think they're going after a fly with a battleship.
I do not know whether they sincerely believe that they're "protecting"
amateur radio or if they have some more sinister motive. I can only
hope for the former, so we can reason with them.  Every new development
carries with it some risk of abuse; the more powerful the technology,
the greater the risk. Amateur packet radio is no exception; even in its
presently primitive state, it is useful enough to tempt some commercial
entities to abuse it. We should be able to convince the FCC that
requiring unrealistically stringent mechanisms to prevent even the
occasional commercial abuse of amateur packet radio runs the far
greater risk of destroying all of the good that it can do.

Lately, several of us (WA8DZP, K3MC, N6RCE, NG6Q and I) have been
taking a close look at the low power spread spectrum modems that are
rapidly becoming available for use under Part 15 rules on 902-928 MHz
and other shared ISM/amateur bands. In my own opinion, building high
speed (say, 100-500kb/s) metropolitan area networks under Part 15 rules
seems entirely feasible, even with the 1W power limit - given proper
design and engineering (good sites, directional antennas, power
control, efficient channel access methods, etc). True, the performance
of the existing generation of equipment is disappointing, mainly due to
the lack of receiver processing gain in most models. But with the new
FCC rules mandating the use of "true" spread spectrum receivers, plus
the commercial drive behind this industry, it seems likely that the
cost/performance ratio of this equipment will rapidly improve.
Unfortunately, the same probably cannot be said for amateur packet
radio gear, where the large scale production of inexpensive, high speed
radio modems seems as far away as ever. Hence our initial interest in
this technology.

But this latest blow from the FCC is making Part 15's complete absence
of licensing requirements, content and/or usage restrictions look
mighty attractive indeed - even though my primary intent is to use the
network for the kind of personal experimentation that has traditionally
been done in the amateur service. Are the FCC's rules really
"protecting" the amateur service if they scare off those who are most
interested in making technical contributions to the service?

I think it's time that the FCC not only remove the burden of
responsibility for content from automatic relay stations, but that it
loosen up its draconian definition of "business communications" as
well. A lot has happened to the telecommunications industry since the
Eyebank Docket; in particular, it is certainly no longer the job of the
FCC to protect a telephone company from "lost business". The amateur
rules should be pragmatic, with the realization that absolute
prohibitions do far more harm than good.

A simple "hams shalt not sell communications services" rule should
suffice to make any abuses self-limiting, as few hams I know would be
willing to use their time and their stations to help make money for
others if they didn't get a cut of it. Such a rule would be far clearer
than the present "no business interest" rule. The current rule has
spawned an entire generation of armchair amateur lawyers who revel in
interpreting the rules in the most restrictive fashion possible. One
only need look at how the field of computer networking is pretty much
passing amateur radio by to see the chilling effect of the present rules.

73,

Phil Karn

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

Date: 4 Jun 91 23:31:00 GMT
From: [e-mail]
Subject: Undeliverable mail
To: [e-mail]

Your message could not be delivered to:

    POLDER@WOLGA

Your message has been enqueued and undeliverable for 6 days.
The mail system will continue to try to deliver your message
for an additional 6 days.

The beginning of your message follows:

Date: Wed, 29 May 91 15:45 MET
From: [e-mail]
Subject: Packet-Radio Digest V91 #134
To: POLDER@WOLGA
Message-id: <[e-mail]>
X-Envelope-to: POLDER@WOLGA
X-VMS-To: Gerrit Polder PA3BYA <[e-mail]>

Packet-Radio Digest         Wed, 29 May 91       Volume 91 : Issue 134

Today's Topics:
           AX.25 Packet TNC Timing Parameters HELP!

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

Date: 4 Jun 91 23:31:00 GMT
From: [e-mail]
Subject: Undeliverable mail
To: [e-mail]

Your message could not be delivered to:

    POLDER@WOLGA

Your message has been enqueued and undeliverable for 6 days.
The mail system will continue to try to deliver your message
for an additional 6 days.

The beginning of your message follows:

Date: Wed, 29 May 91 15:40 MET
From: [e-mail]
To: POLDER@WOLGA
Message-id: <[e-mail]>
X-Envelope-to: POLDER@WOLGA
X-VMS-To: Gerrit Polder PA3BYA <[e-mail]>

remote execution        [uucp job mwoodA1d65 (5/29-7:53:00)]
    rmail attcc!ulab!area88!tom
exited with status 2

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

End of Packet-Radio Digest
******************************
Date: Thu,  6 Jun 91 04:30:08 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #142
To: packet-radio


Packet-Radio Digest         Thu,  6 Jun 91       Volume 91 : Issue 142

Today's Topics:
               Converting modem to TNC
                 FAQ
              PSE HELP : TNC-220 & KISS
                   security
              Undeliverable mail

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

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

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

Date: 6 Jun 91 01:30:11 GMT
From: pa.dec.com!nntpd.lkg.dec.com!sousa!sndpit.enet.dec.com![e-mail]
Subject: Converting modem to TNC
To: [e-mail]

In article <[e-mail]>,
    [e-mail] writes...
>       I have a USRobotics DIRECT 1200 modem that I don't use any
>more. I was wondering if there was any way I could convert it to work
>as a TNC. It has an RS232 port, and 2 RJ11 sockets.

Not easily.  I'm pretty sure the modem standards aren't the same, and
getting a modem which expects to talk in full-duplex mode to talk in half
duplex mode is non-trivial.  Besides, even if you _did_ get it to work, you
still need the PAD (Packet Assembler/Disassembler), to have the rest of the
TNC.  Why not get a kit from somebody or build one fron scratch?

Willie Smith
[e-mail]
[e-mail]
{Usenet!Backbone}!decwrl!sndpit.enet.dec.com!smith

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

Date: 5 Jun 91 03:14:20 GMT
From: panix![e-mail]
Subject: FAQ
To: [e-mail]

Is there a(n) FAQ list for this newsgroup?

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

Date: 5 Jun 91 13:28:28 GMT
From: mcsun!ukc!edcastle!hwcs![e-mail]
Subject: PSE HELP : TNC-220 & KISS
To: [e-mail]

Well thanks for reading this, it is my last hope...............

I have been running TCPIP (both g1emm v1.6 and g1yyh v2.5) over the
past few months and have been having a persistant problem.

I use a TNC-220 from paccomm (v1.1.6c1) firmware, All and I mean all of the
other users in the area are using AEA PK232`s.

My problem is that the 220 is persistently missing packets during an
ftp or telnet transfer, and I just cannot work out why. I have spent ages
trying to elimate possibilities, the station comprises of :

Amiga/PC XT clone (does not make a difference)
PACCOMM TNC 220
ALINCO ALM 203-E H/H (or a yeasu FT290R does not seem to make a diff)
Indoor Slim Jim antenna (student flat!!!).

The symptoms are that in kiss mode the DCD light comes on to register
the traffic on the channel but the con light does not flash to indicate
that it has been rx`ed correctly, consequently the machine at the other end
contunues to backoff and i get stuck. All AX25 sessions work OK that is what
I cannot understand because to my mind IP sits on top of it.

Which brings me to the conclusion that the TNC does not like long packets,
maybe the buffer gets full....etc I`m only guessing, A UUEDCODED ASCII request
(I.e. DU xxxx) also gets stuck.

I hope its something straight forward but this is driving me crazy...

I phoned the UK PACCOMM importer who said to try three things :

1. Make sure AWLEN 8 and PARITY 0 before going into kiss mode.
2. Reduce the Compute to TNC baud rate to 2400
3. Cry.

None of which makes any difference, I have also tried using a BSX2 (TNC2 clone)
with the latest TAPR 1.1.7b code but still no joy. Is there something so
different in the PK 232 (I understand it still uses a Z80 unless the input side
is different)

Has anyone come across this problem and if so do you know of a fix.

P.S Please not that the other station is 5 miles away and we have a clear
frequency.

Please HELPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP!!!

Thanks

Robin GM4YED

INTERNET : [e-mail]

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

Date: 30 May 91 04:28:29 GMT
From: mcsun!unido!drnhh!mcshh!ccsq![e-mail]
Subject: security
To: [e-mail]

Hi,
we at our University-Network are using a so called 'wizard-code' to
protect our machines.
Here a short explanation:
After logging in (with or without password) two line like the
following appears:

     1  2  3  4  5  6  7  8  9  0
     4  3  8 10  5  4  3  9  1  2

The first line is for reference only, the second one is for every login
differently produced by a random generator.
In your mind you 'hide' a secrete formula insted of a password. The formula
may look like '2*8-1+k3'. With the second line from the wizard-generator
and the formula you have to calculate your password for this session, in
the example above this will be:

2.th number(3) * 8.th number(9) - 1.st number(4) + 3 (constant) = 26

If the choosen formula is not too simple, it would take a long time
of scanning to guess it. It is even possible, to block the account
for a certain time, if the answer is n-times wrong...

Of course, before you may use this feature, you have to exchange the
formula with the sysop of the bbs. Could be, that will be a problem...

The code for this wizard-protection is not in the public-domain,
but a thing, this little hack is not a hard work...

Greetings, Klaus
--
Klaus Kleemann           ][   ampr  : [e-mail]
2085 Quickborn           ][   Privat: [e-mail]
             ][   Duty  : [e-mail]
             ][   X400  : [e-mail]

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

Date: 5 Jun 91 23:32:00 GMT
From: [e-mail]
Subject: Undeliverable mail
To: [e-mail]

Your message could not be delivered to:

    POLDER@WOLGA

Your message has been enqueued and undeliverable for 6 days.
The mail system will continue to try to deliver your message
for an additional 6 days.

The beginning of your message follows:

Date: Thu, 30 May 91 14:05 MET
From: [e-mail]
To: POLDER@WOLGA
Message-id: <[e-mail]>
X-Envelope-to: POLDER@WOLGA
X-VMS-To: Multiple recipients of <[e-mail]>


pr
gen
info

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

End of Packet-Radio Digest
******************************
Date: Fri,  7 Jun 91 04:30:07 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #143
To: packet-radio


Packet-Radio Digest         Fri,  7 Jun 91       Volume 91 : Issue 143

Today's Topics:
               PACKET->Internet Gateway
         Param command broken in NOS_0423.EXE
          The 'hidden transmitter' problem.

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

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

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

Date: 4 Jun 91 00:23:20 GMT
From: elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!menudo.uh.edu!lobster!nuchat!farwest![e-mail]
Subject: PACKET->Internet Gateway
To: [e-mail]

Organization: San Diego State University Computing Services

Don't know if the other message/article was posted here, so I'll request again.
Does anyone know if a PACKET (either AX.25 and/or TCP/IP) gatewaye exists
between PACKET radio and Internet?  If so, could someone please state where it
is located?  If not, why has this not been performed?  Additionally, what would
be needed in getting set up?

Robert S. Radvanovsky, KC6ONL
-


 * Origin: Two Wheelers  bikie hangout (1:106/88.0)

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

Date: 6 Jun 91 10:10:00 GMT
From: [e-mail]
Subject: Param command broken in NOS_0423.EXE
To: [e-mail]

Hello,

In the NOS.EXE from 0423 (PA0GRI version 1.6h) the param command seems to
be broken. If I do a 'param ax0 6 65' to disable the blinking led of my
DTNC-1 (Dutch TNC-1) the led doesn't stop blinking as it does with the NOS.EXE
from 0201 (PA0GRI version 1.6e). So the '6 65' doesn't go to the TNC anymore.
If I give the command 'param ax0 75' to set the DTNC-1 into KISS mode the
answer is: 'Parameter 75 not supported'. In the previous version this gave
no problems.

In the source listings I have seen that the code has changed but it is not
clear to my why it changed and how it works now. In the previous version
I could at least send any character I wanted to the TNC. This seems not to
be possible anymore.

Any clues?

Greetings, Robert van den Nieuwendijk PA3AMO

Robert van den Nieuwendijk         | Phone:       [phone]
Technical services of the Dutch    | Telefax:     ([phone]
Ministry of Agriculture            | Telex:       45330 CTWAG NL
TFDL-DLO Afd Informatietechnologie | AGROnet:     GEMINI::NIEUWENDIJK
P.O. BOX 356                       | SURFnet:     AGRT03::NIEUWENDIJK
NL-6700 AJ  Wageningen             | PSImail:     PSI%18370040906::NIEUWENDIJK
The Netherlands                    | Internet:    [e-mail]

X400:  C=NL; ADMD=400NET; PRMD=MIN LNV; O=MIN LNV; OU=TFDL;
       S=van den Nieuwendijk; G=Robert

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

Date: 6 Jun 91 09:17:13 GMT
From: [e-mail]
Subject: The 'hidden transmitter' problem.
To: [e-mail]

The 'hidden transmitter' problem will be with us forever; in a classic
client-server system, something like Hubmaster is a way to solve some
of the grosser deficiencies; but in a true peer-to-peer system its no
help.
I rather like the idea of a dual-channel system with the second
channel being used to send 'back off' messages in case you get the
transmitter-collision problem; this only works if you have true
full-duplex capability and the TNCs etc. can stop sending in mid-frame
on receiving a 'backoff'. (Maybe just de-key the TX and let the TNC
carry on till its finished?) Put the supervisory channel on a different
frequency, (remember that the supervisory channel would only ever carry
'backoff' frames so the chance of a collission there is much reduced).
Just thoughts.....

  Pete Lucas [e-mail]  [e-mail]    PJML%IA.NWL.AC.UK@UKACRL

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

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


Packet-Radio Digest         Sat,  8 Jun 91       Volume 91 : Issue 144

Today's Topics:
               Converting modem to TNC
             DSP 2232 info wanted
                 SUBSCRIPTION
                 Test
          The 'hidden transmitter' problem.

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

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

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

Date: 7 Jun 91 03:55:07 GMT
From: comp.vuw.ac.nz!cc-server4.massey.ac.nz![e-mail]
Subject: Converting modem to TNC
To: [e-mail]

Converting a modem to a TNC is sort of like converting a child's
trolley to a motorised vehicle.  They both need a body and wheels but the
the main bit (the motor) is missing :-).  In the case of the TNC, the
main bit is the microprocessor and it's control program to do all the
packet encoding and decoding.

If, on the other hand, all you want to do is USE the modem to give you
a packet station, then this should be possible, if you have either a
PC or a C64 computer.  There are two programs for a PC that will do
all the packetising and de-packetising for you, all you need is a
dumb modem and a radio.  These program are called PMP (poor man's
packet) and BAYCOM.  I prefer PMP but BAYCOM seems to have more
features - they work. I've been using PMP daily for the last 15 months.
For a C64 the program is called DIGICOM.

Unfortunately, I don't have the IP addresses of any sites
that have these programs.  If you get stuck (and no-one else obliges
with the FTP addresses) then let me know and I'll either find them
for you or mail you copies of the programs.


Cheers
Giovanni - ZL2BOI

--
------------------------------------------------------------------------------
Giovanni Moretti, Computer Science Dept, Massey University, Palmerston North,
Mail: Internet: [e-mail], Pkt-Radio: ZL2BOI@ZL2TCA | New Zealand
Ph 64 63 69099 x8694,FAX [phone] | QUITTERS NEVER WIN, WINNERS NEVER QUIT
------------------------------------------------------------------------------

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

Date: 7 Jun 91 00:26:26 GMT
From: comp.vuw.ac.nz!matai.vuw.ac.nz!ctl.co.nz!mof.govt.nz![e-mail]
Subject: DSP 2232 info wanted
To: [e-mail]

Hello everyone, I have just seen an advertisement in the April issue
of Radio Communications about a new TNC/modem made by AEA, model number
DSP2232. Can someone send me some information on this device, ie what
are its capabilities, price etc. Is this the replacement for the PK232?
Thanks in advance...

Charles Tetenburg (ZL1BQJ)              Internet: [e-mail]

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

Date: 7 Jun 91 18:47:43 GMT
From: [e-mail]
Subject: SUBSCRIPTION
To: [e-mail]

SUB PACKET-RADIO  Allen Graham Gates

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

Date: 5 Jun 91 17:51:35 GMT
From: hpl-opus!hpspdra![e-mail]
Subject: Test
To: [e-mail]

Did I pass the test?
;-)

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

Date: 6 Jun 91 21:58:36 GMT
From: hpl-opus!hpnmdla![e-mail]
Subject: The 'hidden transmitter' problem.
To: [e-mail]

In rec.radio.amateur.packet, [e-mail] (Pete Lucas, NCS-TLC, Holbrook House, Swindon) writes:

>
>     The 'hidden transmitter' problem will be with us forever; in a classic
>     client-server system, something like Hubmaster is a way to solve some
>     of the grosser deficiencies; but in a true peer-to-peer system its no
>     help.
>

   If we limited amateur radio to only peer-peer sytems I believe much of the
utility of the nbfm HT would be lost (no repeaters).
  It seems to me that in the real world higher performance amateur
communications made possible by effective use of resources increasingly
require coordination and cooperation.
   If in striving for peer-to-peer systems you would seek increased
autonomy ("I did it my way", "rugged individualist" etc) then I think that
is counter to the development of a  shared resource like a wide area
network.

In a very real sense, a second, "control channel" is a jointly owned
resource used to facilitate communication.

  Just a thought.


Glenn Elmore -N6GN-

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





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

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


Packet-Radio Digest         Sun,  9 Jun 91       Volume 91 : Issue 145

Today's Topics:
                   KAM/PBBS
               PACKET->Internet Gateway
          The 'hidden transmitter' problem. (2 msgs)
            Thoughts on BBS authentication
              Undeliverable mail

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

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

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

Date: 8 Jun 91 23:22:37 GMT
From: [e-mail]
Subject: KAM/PBBS
To: [e-mail]

Hello name here is Roland /KA2RC/. I have a KAM Tnc that I am very happy
with. However I recently upgraded it to 4.0. Is there anything that the
books do not tell me about the upgrade that might be handy info to know?
Also is it possible to increase the size of the PBBS beyond the 20 size.
By the way there was a question some days ago about HF BBS's. There is an
excellant one on 21.101 in Subic Bay PI. The call is KJ6WO.SUBIC.PHL.OC
Gordy is the Psyop.
73 and thanks in advance
de Roland [e-mail]


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

Date: 6 Jun 91 05:39:35 GMT
From: nuchat!farwest![e-mail]
Subject: PACKET->Internet Gateway
To: [e-mail]

Organization: San Diego State University Computing Services

Don't know if the other message/article was posted here, so I'll request again.
Does anyone know if a PACKET (either AX.25 and/or TCP/IP) gatewaye exists
between PACKET radio and Internet?  If so, could someone please state where it
is located?  If not, why has this not been performed?  Additionally, what would
be needed in getting set up?

Robert S. Radvanovsky, KC6ONL
i


 * Origin: Two Wheelers  bikie hangout (1:106/88.0)

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

Date: 7 Jun 91 19:24:37 GMT
From: photon![e-mail]
Subject: The 'hidden transmitter' problem.
To: [e-mail]

In article <06.Jun.91.10:21:32.BST.#[e-mail]>, [e-mail] (Pete Lucas, NCS-TLC, Holbrook House, Swindon) writes:
|>
|> The 'hidden transmitter' problem will be with us forever; in a classic
|> client-server system, something like Hubmaster is a way to solve some
|> of the grosser deficiencies; but in a true peer-to-peer system its no
|> help.

OK, then, set it up so that as the packet is beng received, it also regenerates
it back to the output.  This assumes, of course, that the node is full-dux.
If the node hears a scramble packet in the middle, immediately stop sending
the regenerated packet and sent out an abort frame.
--
Kurt Freiberger, wb5bbw   [e-mail]   409/847-8706
Dept. of Computer Science, Texas A&M University  DoD #264
*** Not an official document of Texas A&M University ***

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

Date: 8 Jun 91 14:52:01 GMT
From: swrinde!cs.utexas.edu!asuvax!anasaz!qip![e-mail]
Subject: The 'hidden transmitter' problem.
To: [e-mail]

In article <[e-mail]> [e-mail] (Kurt Freiberger) writes:
]In article <06.Jun.91.10:21:32.BST.#[e-mail]>, [e-mail] (Pete Lucas, NCS-TLC, Holbrook House, Swindon) writes:
]|>
]|> The 'hidden transmitter' problem will be with us forever; in a classic
]|> client-server system, something like Hubmaster is a way to solve some
]|> of the grosser deficiencies; but in a true peer-to-peer system its no
]|> help.
]
]OK, then, set it up so that as the packet is beng received, it also regenerates
]it back to the output.  This assumes, of course, that the node is full-dux.
]If the node hears a scramble packet in the middle, immediately stop sending
]the regenerated packet and sent out an abort frame.

We have some full duplex regenerative packet repeaters here in Arizona
for exactly the purpose of eliminating the hidden transmitter problem.
It works!

Recognizing the scrambled packet in the middle doesn't really do any
good, since the node is jammed until both senders stop transmitting.


--
John Moore HAM:NJ7E/CAP:T-Bird 381 {ames!ncar!noao!asuvax,mcdphx}!anasaz!john
USnail: 7525 Clearwater Pkwy, Scottsdale,AZ 85253 anasaz![e-mail]
Voice: [phone]        Wishful Thinking: Long palladium, Short Petroleum
Opinion: Support ALL of the bill of rights, INCLUDING the 2nd amendment!
Disclaimer: The opinions expressed here are all my fault, and no one elses.

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

Date: 5 Jun 91 08:27:41 GMT
From: mcsun!ukc!uos-ee!thorin.ee.surrey.ac.uk![e-mail]
Subject: Thoughts on BBS authentication
To: [e-mail]

A very interesting and informative article. Pity it is not legal to
pass any message in anything but plain unencrypted text, using the
defined transmission formats.

IE WE can not use any key or cypher on the packet network.


Now it may be that US rules allow this, though I should hope not
as any business could use the bands for any purpose and no-one
would be able to tell, a short cut for PMR ?

73 Mike

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

Date: 8 Jun 91 23:31:00 GMT
From: [e-mail]
Subject: Undeliverable mail
To: [e-mail]

Your message could not be delivered to:

    POLDER@WOLGA

Your message has been enqueued and undeliverable for 9 days.
The mail system will continue to try to deliver your message
for an additional 3 days.

The beginning of your message follows:

Date: Thu, 30 May 91 14:05 MET
From: [e-mail]
To: POLDER@WOLGA
Message-id: <[e-mail]>
X-Envelope-to: POLDER@WOLGA
X-VMS-To: Multiple recipients of <[e-mail]>


pr
gen
info

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

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


Packet-Radio Digest         Mon, 10 Jun 91       Volume 91 : Issue 146

Today's Topics:
         Frequently Asked Question (FAQ) list coming
       Specs for RAMSEY 2 Meter Xcvr Kit/ Address&Phone-Ramsey
            Thoughts on BBS authentication
              WIRELESS digest available

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

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

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

Date: 10 Jun 91 05:45:02 GMT
From: maverick.ksu.ksu.edu!matt.ksu.ksu.edu![e-mail]
Subject: Frequently Asked Question (FAQ) list coming
To: [e-mail]

For the past few weeks, I have been assembling a Frequently Asked Question
(FAQ) list for this newsgroup (rec.radio.amateur.packet) and the
packet radio mailing list.

This message is being put out to inform everyone that the FAQ is
on the way and I plan to get it done in 2 weeks.

-Steve Schallehn, KB0AGD
Kansas State University

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

Date: 9 Jun 91 20:32:29 GMT
From: swrinde!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!abvax!iccgcc![e-mail]
Subject: Specs for RAMSEY 2 Meter Xcvr Kit/ Address&Phone-Ramsey
To: [e-mail]

Since I have had enough direct inquiries about the Ramsey 2 Meter transceiver,
I think a general post is in order.

The Ramsey kit is as follows:


2 Meter Amateur PLL Synthesized FM Transceiver  -  Model FTR-146

I paid $125 + tax at the Dayton Hamvention for it - I don't know if that was
a show special or not.

It is basically a 2 Meter radio with the following specs:

(This is taken from Ramsey Publication no. M146FTR - Kit assy and instruction
Manual for the kit - Copyright 1991 Ramsey Electronics)
(All rights, credits go to Ramsey Electronics...)
Hopefully I didn't insert any typo's...

Freq Range: 144.000 to 147.995 MHZ
       (actually its 143.000 - 148.110 Mhz, but NOBODY would
        transmit out of band!   8-]  )
Tuning: Diode programmable PLL synthesis
PLL Programming: 5 KHZ steps
Transmit Offset:  Simplex, +600 KHZ, -600 KHZ
Mode:   NBFM
Packet Operation: 5 pin DIN connector for TNC cable
Power:  13.8 VDC +/- 10% (negative grounding)
Current:  1.5 Amps Transmit
      200 ma Receive (no signal)
Antenna Impedance:   50 Ohms
Microphone Impedance:   500-600 Ohms
T-R Switching:    PIN Diodes
PTT Circuit:     Solid State
Semiconductors: 4 IC's, 26 transistors, 25 diodes (plus programming diodes)
        (and LOTS of inductors, capacitors and resistors!)

Transmitter:

Final Power Output:   4-6 Watts
Final Output Stage:   MRF237 or equivalent
Modulation:      VCO
Maximum freq deviation:  +/- 25 KHZ., +/- 5 KHZ NBFM
Modulation Distortion: less than 5%


Receiver:

Circuitry:   Double Conversion superhet
         first IF:  10.7 Mhz
         second IF:  455 Khz

Sensitivity:   12 db SINAD less that 0.35 uv.
selectivity:   +/- 7Khz (-6db)
           +/- 15 Khz (-60db)
           4-pole crystal filter at 10.7 Mhz

Squelch sensitivity:  less than 0.25 uv.
Audio output:      More than 2.0 Watts  (!)


Its basically a TRUE Amateur Radio hobbyist's radio.


Where to get one you ask?  Well...

Ramsey Electronics, Inc.
Amateur Radio and Hobby Kits Department
793 Canning Parkway
Victor, New York  14564

Phone:  [phone]    FAX: [phone]


No, I'm not an employee of Ramsey, nor am I getting anything for sitting
at a terminal on a Sunny Sunday Afternoon and typing this.  I just think
that this is a GREAT radio kit and a lot of fun to build and use!


--
  John Gibbons             N8OBJ                     Macedonia, Ohio

       Of all the things I've lost, I miss my mind the most...

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

Date: 9 Jun 91 18:39:22 GMT
From: [e-mail]
Subject: Thoughts on BBS authentication
To: [e-mail]

mcsun!ukc!uos-ee!thorin.ee.surrey.ac.uk![e-mail] (Mike) writes:

>A very interesting and informative article. Pity it is not legal to
>pass any message in anything but plain unencrypted text, using the
>defined transmission formats.

>Now it may be that US rules allow this, though I should hope not
>as any business could use the bands for any purpose and no-one
>would be able to tell, a short cut for PMR ?

I think that you totally missed the point.  The discussion is based on
how to AUTHENTICATE that the user of a BBS is actually who he SAYS
that he is.  This was not discussing encryption of the message TEXT,
but how to build a system where you COULD hold a person responsable
for what HE PUT IN A BBS!  Most especially messages of a COMMERCIAL
nature!

Recently in the U.S.A., a ham DID insert into a BBS a message that was
deemed COMMERCIAL by nature by the FCC.  The BBS's that automatically
forwarded the messages were also held liable, but the person that had
entered the message claimed "someone else was using my callsign" and thus
got off the hook.  Impossible to say for sure whether it WAS the person
who's call was on the message or whether it WAS someone else.

This message string discusses ways to avoid that in the future.
This would not have any intention to (nor would it) encrypt or obscure
the message CONTENT so it should not be seen as ENCRYPTION per se.

Sorry to see that you have rules so strict over there.  I guess that
you will never be able to use the 56KBS Heatherington modems since
they use a randomizing method with published key that you all would
probably consider "encryption".

It's a shame when the rules inhibit innovative development don't you
think?   We ought to change the rules .....

Mark Bitterlich
[e-mail]
[e-mail]

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

Date: 9 Jun 91 19:52:20 GMT
From: pacbell.com!tandem![e-mail]
Subject: WIRELESS digest available
To: [e-mail]

The weekly digest for the WIRELESS mailing list is now available on
tandem.com through anonymous FTP.  The digest can be found in

    wireless/digest-060891


==============================================================================
Weekly digest for WIRELESS mailing list

Week ENDING June 8, 1991

This digest (or back issues) can be obtained by anonymous FTP to tandem.com
from the wireless directory.

The file wireless/wireless explains the purpose of the mailing list and
describes how to subscribe and post.

To subscribe to the mailing list, send a mail message to
'[e-mail]' with the following line in the body:

    add <your e-mail address> wireless

for example:

    add [e-mail] wireless

The e-mail address *must* be fully qualified with the full domain name.

The WIRELESS mailing list is moderated by Stuart Phillips and Kevin Rowett.
==============================================================================

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

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


Packet-Radio Digest         Tue, 11 Jun 91       Volume 91 : Issue 147

Today's Topics:
              ATV - High Speed Digital ?
           Converting modem to TNC (3 msgs)
        FLEA all SUMMER at MIT - Sunday, June 16, 1991
            ftp PMP/Baycom wanted
             KAM/PBBS [more questions...]
                Packet
          PACKET->Internet Gateway (3 msgs)
              Packet at 56kbps: How to?
          The 'hidden transmitter' problem.
             Undeliverable mail (2 msgs)
             Wanted: W0RLI Version 13.01

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

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

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

Date: 10 Jun 91 18:13:44 GMT
From: usc!sdd.hp.com!mips!cs.uoregon.edu!milton!sumax!polari![e-mail]
Subject: ATV - High Speed Digital ?
To: [e-mail]

Has anyone tried to use ATV equipment to send high speed
digital information, along the lines of the "back up
your computer disk on your VCR", by making a modem that
outputs something that looks like a standard TV signal?

Should be good for over 4 Mbps, and if you work it right
you can put your ID out as a visual signal.

Mark Zenier  [e-mail]  [e-mail]

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

Date: 10 Jun 91 12:15:44 GMT
From: usc!sdd.hp.com!caen!news.cs.indiana.edu!noose.ecn.purdue.edu!eg.ecn.purdue.edu![e-mail]
Subject: Converting modem to TNC
To: [e-mail]

In article <[e-mail]> [e-mail] (Giovanni Moretti) writes:
>
>If, on the other hand, all you want to do is USE the modem to give you
>a packet station, then this should be possible, if you have either a
>PC or a C64 computer.  There are two programs for a PC that will do
>all the packetising and de-packetising for you, all you need is a
>dumb modem and a radio.

    Does anybody have the straight scoop on how to go about interfacing
a dumb (or Hayes-compatible, for that matter) 1200 baud modem to one's
HT and PC, for use by PMP or baycom? I have a PC and the PMP code, and what
I believe is a working 1200 baud modem (flea market special, don'cha know:-),
but lashing them all together seems to leave a lot of mental loose ends.
Particularly on the modem <-> radio side, since the modem expects to see Ma
Bell out there...

    Any tips gladly appreciated. Followups to this group.

>Cheers
>Giovanni - ZL2BOI


--
    |  Mike Young KA9HZE                |       [e-mail]    |
    |  Purdue University EE Dept.       |       ...!pur-ee!young        |
    |  W. Lafayette, IN  47907          |                               |
    _____________________________________________________________________

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

Date: 10 Jun 91 15:31:35 GMT
From: usc!aero-c![e-mail]
Subject: Converting modem to TNC
To: [e-mail]

In article <[e-mail]>, [e-mail] (Mike Young) writes...

>Particularly on the modem <-> radio side, since the modem expects to see Ma
>Bell out there...

Well, I'm not quite certain that the modem expects to see Ma Bell out there.
Most modern modems have a leased-line setting to disable dial-tone detection,
and the older modems didn't even have dial-tone detection.  The question, in
my mind, is a matter of matching that RJ-11 jack on the modem line out to
the TNC.  (I am right that you'd still need a TNC to set TX, correct?)

I'm a complete neophyte to Packet, in fact, I just passed my tech. last wkend.
However, I had this same thought (i.e. why not use the modem I've already got).

Well, what about it out there?  Would it work, how do you wire it up, and is
your modem permanently crippled for regular work.  Ideally, I'd like an
external box that plugs into the RJ-11.

--Pete

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

Date: 10 Jun 91 16:54:06 GMT
From: pa.dec.com!nntpd.lkg.dec.com!sousa!sndpit.enet.dec.com![e-mail]
Subject: Converting modem to TNC
To: [e-mail]

In article <[e-mail]>,
    [e-mail] (Peter L. Thomas) writes...
>In article <[e-mail]>,
    [e-mail] (Mike Young) writes...
>>Particularly on the modem <-> radio side, since the modem expects to see Ma
>>Bell out there...
>Well, I'm not quite certain that the modem expects to see Ma Bell out there.
>Most modern modems have a leased-line setting to disable dial-tone detection,
>Well, what about it out there?  Would it work, how do you wire it up, and is
>your modem permanently crippled for regular work.  Ideally, I'd like an
>external box that plugs into the RJ-11.

You forgot that most 'modern' modems expect to receive a modem tone before
they will connect, or conversely will disconnect if the tone goes away.
Phone modems are made for full-duplex, and you would have to play a _lot_
to get one to work half-duplex.

Also, I don't know the exact details, but aren't the modem standard
different?  I seem to remember most 1200-baud phone modems being Bell 212,
whille packet modems are Bell 303 (or something).

Then don't forget you still need a PAD (Packet Assembler/Disassembler),
unless you have a PeeCee or C64 or something to do that part for you.

OK, let's hear from the other side, let's say I have a TNC with (only) a
9600-baud modem [like the PacComm UP3-9600], and I want to add a 1200-baud
modem to it.  Does anyone make just the 1200-baud modem as a kit?  Is there
an easy circuit that would use an Exar 2206(?) or something?  I suspect
it's easier to build a 1200-baud packet modem from scratch than adapt a
phone modem....

Willie Smith
[e-mail]
[e-mail]
{Usenet!Backbone}!decwrl!sndpit.enet.dec.com!smith

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

Date: 10 Jun 91 21:06:06 GMT
From: pa.dec.com!nntpd.lkg.dec.com!mast.enet.dec.com![e-mail]
Subject: FLEA all SUMMER at MIT - Sunday, June 16, 1991
To: [e-mail]

Date: Wed, 5 Jun 1991 13:01 EDT
From: [e-mail]

This coming Sunday the next...

***** 50 cent buyers discount with hardcopy of this notice ********

COMPUTERS - ELECTRONICS - HAM RADIO - COMPUTERS - ELECTRONICS

          FLEA  all SUMMER at MIT
           Sunday, June 16, 1991
             9AM-2PM

Come to the city for a great flea - plenty of free parking.

    MIT's  electronics and ham radio flea will take
    place on the third Sunday of each month this summer,
    April thru October.

    There is tailgate space for over 400 sellers and
    free, off-street parking for >1000 cars!

    Buyers admission is $1.50 (you get 50c off if
    you're lucky enough to have a copy of our add)
    and sellers spaces are $8.00-each at the gate
    or $5.00 if mailed by the preceding 5th.

    The flea will be held at the corner of Albany and
    Main streets in Cambridge; right in the Kendall
    Square area from 9AM to 2PM, with sellers set-up
    time starting at 7AM.

    !! RAIN or SHINE !!  Have no fear of rain, a covered
    tailgate area is available for all sellers (6'8" clearance).

    Talk-in: 146.52 and W1XM/R-449.725/444.725 (PL 114.8/2A).

    Sponsors: MIT Electronics Research Society
          MIT UHF Repeater Association (W1XM)
          MIT Radio Society (W1MX)
          Harvard Wireless Club (W1AF)

    For more info / advanced reservations 617 253 3776

******** 50 cent  buyers discount with hard copy of this notice ************

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

"The opinions expressed here in no way represent the views of Digital
 Equipment Corporation."

James J. Reisert                Internet:  [e-mail]
Digital Equipment Corp.         UUCP:      ...decwrl!mast.enet!reisert
146 Main Street                 Voice:     508-493-5747
Maynard, MA  01754              FAX:       [phone]

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

Date: 10 Jun 91 15:34:15 GMT
From: [e-mail]
Subject: ftp PMP/Baycom wanted
To: [e-mail]

Can someone email me the site(s) for ftp'ing the PMP and Baycom apps?
Also, are these just "drivers" ie can I use them "underneath" another
app, say NOS on a pc?  Or are they stand-alone comm programs?  I'm
looking for a cheap KISS modem, in effect, since NOS will do all of
protocol bundling for tcp/ip.  So I don't need ax.25 or ROMS or much
at all.

73,  Jim N2MPT


----------------------                                   |\  | |
Jim Sandoz trading as [e-mail]       | | | |
 Drexel University Dept of Mechanical Engineering        |/. |_|.

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

Date: 10 Jun 91 18:16:04 GMT
From: usc!apple!xanadu![e-mail]
Subject: KAM/PBBS [more questions...]
To: [e-mail]

In article <[e-mail]> [e-mail] (ASQJ-NBF) writes:
>Hello name here is Roland /KA2RC/. I have a KAM Tnc that I am very happy
>with. However I recently upgraded it to 4.0. Is there anything that the
>books do not tell me about the upgrade that might be handy info to know?
>Also is it possible to increase the size of the PBBS beyond the 20 size.
>By the way there was a question some days ago about HF BBS's. There is an
>excellant one on 21.101 in Subic Bay PI. The call is KJ6WO.SUBIC.PHL.OC
>Gordy is the Psyop.
>73 and thanks in advance
>de Roland [e-mail]
>

I just upgraded to 4.0 last night.  From 2.85.  It looks like there
is good stuff in the 3.0/4.0 upgrade.  Especially the simplified
PBBS access that went into 3.0.  The question I have is...Is there
any software that uses host mode other than the PC program from
kantronics?   Has anyone done a mac program that uses host mode?
I'd really like to be able to work rtty while monitoring packet
and it looks like its technically feasable now.

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

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

Date: 10 Jun 91 11:40:42 GMT
From: news-server.csri.toronto.edu!bonnie.concordia.ca!ccu.umanitoba.ca!bison!sys6626![e-mail]
Subject: Packet
To: [e-mail]

Can someone describe to me what packet is?  And what kind of setup do you
need to use it?

Thanks alot!

Gary

--- (Gary Stimpson) a user of sys6626, running waffle 1.64
E-mail: [e-mail]
system 6626: 63 point west drive, winnipeg manitoba canada R3T 5G8

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

Date: 8 Jun 91 04:15:08 GMT
From: swrinde!zaphod.mps.ohio-state.edu!menudo.uh.edu!buster!nuchat!farwest![e-mail]
Subject: PACKET->Internet Gateway
To: [e-mail]

Organization: San Diego State University Computing Services

Don't know if the other message/article was posted here, so I'll request again.
Does anyone know if a PACKET (either AX.25 and/or TCP/IP) gatewaye exists
between PACKET radio and Internet?  If so, could someone please state where it
is located?  If not, why has this not been performed?  Additionally, what would
be needed in getting set up?

Robert S. Radvanovsky, KC6ONL
t


 * Origin: Two Wheelers  bikie hangout (1:106/88.0)

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

Date: 11 Jun 91 00:43:21 GMT
From: sdd.hp.com!caen!sol.ctr.columbia.edu!cunixf.cc.columbia.edu!cunixb.cc.columbia.edu![e-mail]
Subject: PACKET->Internet Gateway
To: [e-mail]

In article <[e-mail]> [e-mail] (Robert S. Radvanovsky KC6ONL) writes:
>Organization: San Diego State University Computing Services
>
>Don't know if the other message/article was posted here, so I'll request again.
>Does anyone know if a PACKET (either AX.25 and/or TCP/IP) gatewaye exists
>between PACKET radio and Internet?  If so, could someone please state where it
>is located?  If not, why has this not been performed?  Additionally, what would
>be needed in getting set up?
>
>Robert S. Radvanovsky, KC6ONL
>i
>
>
> * Origin: Two Wheelers  bikie hangout (1:106/88.0)

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

Date: 10 Jun 91 01:57:39 GMT
From: nuchat!farwest![e-mail]
Subject: PACKET->Internet Gateway
To: [e-mail]

Organization: San Diego State University Computing Services

Don't know if the other message/article was posted here, so I'll request again.
Does anyone know if a PACKET (either AX.25 and/or TCP/IP) gatewaye exists
between PACKET radio and Internet?  If so, could someone please state where it
is located?  If not, why has this not been performed?  Additionally, what would
be needed in getting set up?

Robert S. Radvanovsky, KC6ONL


 * Origin: Two Wheelers  bikie hangout (1:106/88.0)

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

Date: 10 Jun 91 15:57:02 GMT
From: [e-mail]
Subject: Packet at 56kbps: How to?
To: [e-mail]

How is 56kbps (commonly) achieved for packet radio? I have heard of
the "Grapes" modem used in conjunction with KA9Q for high speed
TCP/IP on the 220mHz band.

Is some kind of KISS mode TNC needed for this setup, or does the
PC need a special high speed COM I/O board of some kind?

There is some interest in my area (mid MO) in building a state wide
high speed packet network. Most of the folks are thinking 9600 bps
but I'm wondering why we shouldn't go further and use 56kbps instead.

I'd appreciate any comments about the radio and PC hardware needed for
56kbps. Perhaps the 450mHz band would be better than the 220mHz band.
Perhaps some kind of spread spectrum at 900mHz under part-15 at
100+kbps would be better still!

Thanks.

73 WA0R

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

Date: 10 Jun 91 17:53:04 GMT
From: mdisea![e-mail]
Subject: The 'hidden transmitter' problem.
To: [e-mail]

In article <06.Jun.91.10:21:32.BST.#[e-mail]> [e-mail] (Pete Lucas, NCS-TLC, Holbrook House, Swindon) writes:
>
>The 'hidden transmitter' problem will be with us forever; in a classic
>client-server system, something like Hubmaster is a way to solve some
>of the grosser deficiencies; but in a true peer-to-peer system its no
>help.
>I rather like the idea of a dual-channel system with the second
>channel being used to send 'back off' messages in case you get the
>transmitter-collision problem; this only works if you have true
>full-duplex capability and the TNCs etc. can stop sending in mid-frame
>on receiving a 'backoff'. (Maybe just de-key the TX and let the TNC
>carry on till its finished?) Put the supervisory channel on a different
>frequency, (remember that the supervisory channel would only ever carry
>'backoff' frames so the chance of a collission there is much reduced).

Come now. The hidden transmitter problem pretty much disappears when you
go to a duplex system. The network switch needs to run full duplex on the
MAN/LAN frequency, and the user's transceivers need to run split frequency,
but they do not need to run full duplex. This operation is almost identical
to the way voice users work. The only addition that makes things nice is
for the network node to not only "echo" the packets back, but to send a
"digipeated" copy as well, after the user quits transmitting. This is
only needed in the case where the user wants to connect to himself. The
digipeat function can be made intelligent so that it occurs only when the
user actually requests it. There are still a few delays in the system making
it slightly slower than direct point-to-point, due to transmitter key-up
times. The system works quite well, by the way. If you visit Atlanta, GA,
try out the PEG/GRAPES 146.13/73 machine (call KD4NC-1).

Jack Brindle
ham radio: wa4fib/7

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

Date: 10 Jun 91 23:31:00 GMT
From: [e-mail]
Subject: Undeliverable mail
To: [e-mail]

Your message could not be delivered to:

    POLDER@WOLGA

Your message has been enqueued and undeliverable for 12 days.
No further attempts will be made to deliver your messsage.

Your entire message follows:

Date: Wed, 29 May 91 15:40 MET
From: [e-mail]
To: POLDER@WOLGA
Message-id: <[e-mail]>
X-Envelope-to: POLDER@WOLGA
X-VMS-To: Gerrit Polder PA3BYA <[e-mail]>

remote execution        [uucp job mwoodA1d65 (5/29-7:53:00)]
    rmail attcc!ulab!area88!tom
exited with status 2


    ===== stderr was =====
rmail: Return to att!VMD.CSO.UIUC.EDU!I-PACRAD
rmail: Cannot return mail.
rmail: Cannot create dead.letter
rmail: Cannot return mail.
rmail: Cannot create dead.letter

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

Date: 10 Jun 91 23:31:00 GMT
From: [e-mail]
Subject: Undeliverable mail
To: [e-mail]

Your message could not be delivered to:

    POLDER@WOLGA

Your message has been enqueued and undeliverable for 12 days.
No further attempts will be made to deliver your messsage.

Your entire message follows:

Date: Wed, 29 May 91 15:45 MET
From: [e-mail]
Subject: Packet-Radio Digest V91 #134
To: POLDER@WOLGA
Message-id: <[e-mail]>
X-Envelope-to: POLDER@WOLGA
X-VMS-To: Gerrit Polder PA3BYA <[e-mail]>

Packet-Radio Digest         Wed, 29 May 91       Volume 91 : Issue 134

Today's Topics:
           AX.25 Packet TNC Timing Parameters HELP!
        Internet-packet gateway mailing list (2 msgs)
               W0RLI BBS WANTED

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

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

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

Date: 28 May 91 02:08:50 GMT
From:
 usc!rpi!think.com!spool.mu.edu!munnari.oz.au!yoyo.aarnet.edu.au!frodo.cc.flinde
 rs.edu.au!adelaide.edu.au![e-mail]
Subject: AX.25 Packet TNC Timing Parameters HELP!
To: [e-mail]

Over the past few months on our local Packet LANs here in Adelaide
I have noticed an increasing amount of congestion as a result of
very badly set TNC timing parameters. Some people appear do have
things like Dwait set to zero! I would like to put together
a set of suggested parameters to put in the local packet news
letter here and wonder if people could offer some suggestions as
to what the various TNC parameters should be set to.

The LANs here typically consist of 1 BBS with multiconnect/multiuser
capabilities (4 users plus a forwarding BBS conenct), several
digipeaters and about 10-20 people on simultaneously either being
connected to the BBS (often via one of the digipeters) or having
conversations/file transfers via several of the digipeaters or
using the fairly large number of PMS's that are on the channel
(of which there are about 10 on 24 Hours a day).

Any suggestions on what typical TNC parameters should be used would
be most useful.

The users here have typically either the older style TNC-2's with the
dwait parameters and increasingly there are TNC's like the
MFJ and KAMs which have the slottime/persist parameters. What
would be the optimum parameters for the BBS and the Digipeaters
and also for the users to use?

Also I would be interested in a detailed description of how the
slottime/persist parameters work.

Please send replies via E-Mail to my address below. If there are
sufficient replies I will sumarise and post the results in a couple
of weeks.

Thanks in Advance...  Grant VK5ZWI
--
Grant Willis (VK5ZWI) Elec.Eng.| AARNet/Internet1: [e-mail]
Adelaide Uni. South Australia  | ACSnet/Internet2: [e-mail]
Disclaimer: What I write is    | Packet Radio: VK5ZWI@VK5TTY.#SA.AUS.OC
mine, NOT the uni's!           | AmPRnet TCP/IP: [44.136.171.11]

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

Date: 28 May 91 12:15:15 GMT
From: uhccux!mpg.phys.hawaii.edu![e-mail]
Subject: Internet-packet gateway mailing list
To: [e-mail]

I would like to setup a mailing list of hams who run an Internet-packet
mail gateway.  The purpose of the mailing list would be to share ideas and
concerns about running such gateways.  I figure such discussions might be
inappropriate for tcp-group and would get lost in the noise in
rec.radio.amateur.packet.  The information shared in such a mailing list would
be a little more 'secure' and low-profile than if it were blurted out in
tcp-group or rec.radio.amateur.*.

If you run such a system, please let me know and I will place you on the list
if you're interested.

Tony
AH6BW
--
Antonio Querubin
[e-mail] / [e-mail] / [e-mail]

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

Date: 28 May 91 21:13:57 GMT
From: photon![e-mail]
Subject: Internet-packet gateway mailing list
To: [e-mail]

Please put me on the list.  My reply to you bounced.  Guess aggieland doesn't
know Hawaii is a state yet!! 8-}

--
Kurt Freiberger, wb5bbw   [e-mail]   409/847-8706
Dept. of Computer Science, Texas A&M University  DoD #264
*** Not an official document of Texas A&M University ***

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

Date: 28 May 91 12:32:02 GMT
From: fs7.ece.cmu.edu!o.gp.cs.cmu.edu!andrew.cmu.edu![e-mail]
Subject: W0RLI BBS WANTED
To: [e-mail]

Does anyone know if there is any machine on the network where I
can obtain the W0RLI BBS Program (Not the source code, just the
executable), via anonymous FTP?
The local packet bbs sysop is getting his copy via modem and long
distance phone call. I promised him that I would check to see
if it's available on the net via ftp. Again....I don't need the
source...just the binary executables.
Which machine would have the latest releases?

Thanks
\paul
WA3TLD

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

Date: 29 May 91 01:09:48 GMT
From:
 swrinde!mips!spool.mu.edu!munnari.oz.au!uniwa!cc.curtin.edu.au![e-mail]
 u
To: [e-mail]

References <[e-mail]>, <[e-mail]>,
 <[e-mail]>
Subject : Re: Time bug in KA9Q v 910423

In article <[e-mail]>,
 karn@epic..bellcore.com (Phil R. Karn) writes:
> In article <[e-mail]> [e-mail] (Tom Thompson) writes:
>>    (1) replace the INT 1A call in NET with fetching the tick
>>        count from BIOS data area (with ints off since long fetches
>>        not indivisible):
>>        cli(); ticks = *(long far *) 0x40006cL; sti();
>
> Tom,
>
> Many thanks for the suggestion. With some minor variations I'm making
> this change to the code right now. After initial testing I will upload
> the new version to thumper.bellcore.com in /pub/ka9q/nos. Hopefully
> this will fix the problem.
>
> Phil

   This seems to fix the problem (at least on my machine, anyway!).
Thanks, Phil.

.....Ron
--

===============================================================================
 Internet: [e-mail]                | "The Universe is so
 Bitnet: [e-mail]    | utterly disorganised
 UUCP  : uunet!munnari.oz!cc.curtin.edu.au!Murray_RJ | that it can only have
Amateur Packet Radio: VK6ZJM@VK6BBS.#WA.AUS.OC       | been written in Pascal"
           TCP/IP: 44.136.204.14, 44.136.204.19  |  -- The Phantom Waffler
===============================================================================

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

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

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

Date: 10 Jun 91 12:45:13 GMT
From: o.gp.cs.cmu.edu!andrew.cmu.edu![e-mail]
Subject: Wanted: W0RLI Version 13.01
To: [e-mail]

I am looking for the W0RLI BBS program Version 13.01.
I only need the .EXE, not the source.
Does anyone know if there is a machine on the net where I can
get it via anonymous FTP?

Paul
WA3TLD

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

Date: 10 Jun 91 18:03:48 GMT
From: mdisea![e-mail]
To: [e-mail]

References <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject : Re: Converting modem to TNC

In article <[e-mail]> [e-mail] (Mike Young) writes:
>       Does anybody have the straight scoop on how to go about interfacing
>a dumb (or Hayes-compatible, for that matter) 1200 baud modem to one's
>HT and PC, for use by PMP or baycom? I have a PC and the PMP code, and what
>I believe is a working 1200 baud modem (flea market special, don'cha know:-),
>but lashing them all together seems to leave a lot of mental loose ends.
>Particularly on the modem <-> radio side, since the modem expects to see Ma
>Bell out there...

Before the preliferation of relatively cheap TNC/modems we actually did
use converted modems for packet communications. They worked well. There
was very little that was needed to convert them, just remove the phone
line couplers. Of course they were Bell 202 modems. I don't believe that
Hayes ever made a 202 compatible modem. The point is that Bell 212 (the
commonly used standard for Asynchronous phone line use) is quite a bit
different than the Bell 202 modems hams use on slow speed packet. It is
definitely not worth while to try to convert the newer modems. Most are
based on IC technology where everything is in one chip. Using 2206's and
2211's, Bell 202 modems are CHEAP.

So what are the differences? The frequency tones, primarily. Bell 212 uses
a full duplex pair to talk both ways simultaneously. Bell 202 is one pair,
simplex only.

I'm not trying to discourage experimentation, just lower the frustration
level...

Jack Brindle
ham radio: wa4fib/7

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

Date: (null)
From: (null)
I have been running a Packet Radio <---> USENET Gateway for the past couple
of months. Thus far it has supported limited e-mail transactions and has
supplied articles from the rec.radio.amateur group to the local Packet
Bulletin Board system.

In the interest of publicizing the Amateur Radio Service and provide e-mail
access between people on the Network and their friends on Packet Radio I
have decided to notify you of this gateway. This is a volunteer effort on
my part, and subject to my available time.

Transactions initiated in the Amateur Radio Packet System are automatically
sent over the Network. Packet Radio message handling has limited the naming
for messages to six upper case and numeric characters. I maintain an alias
list to Network addresses.

Transaction initiated on the Network Side, if confirmed to be an Amateur
Radio Operator, will also be automatic. Otherwise, they will be manually
handled since the rules require that any transmissions on the Amateur
Radio Service be initiated by an Amateur Radio Operator.

Mailing to the packet domain can be as simple as mailing to my system using
the Call Letters (or name) of the destination amateur. For example:
[e-mail]. I have Rosters for Alberta, so a message to me
stating the name of the operator can be sufficient as I will look up their
call letters. If the Amateur is not on packet (anywhere in North America), I
will endeavor, under the free National Telegraph System (NTS) instituted by the
Amateur Radio Service, to get the message off. In that case, I recommend that
messages be kept short, 25 Words or so, and that a phone number and address be
included in the text of the message. No delivery times are guaranteed ...

I will also accept for sale and wanted items to be placed into the Amateur
Radio Swap and Shop (on Packet and over other modes of service) if they are
related to the Amateur Radio Service. Due to the rules of non-commercial
activities on Amateur Radio, the scope of Amateur Related is fairly limited I
must warn you. Scanners, SW, Transceivers and Computers ok, No price is quoted,
only a contact name, phone or address. Many non-amateurs, SWL and Scanner
types, do listen in on the voice Swap and Shops.

Drop me a note if you have any questions about the gateway or the Amateur
Radio Service.

Ciao, Mark Salyzyn  [e-mail]  Packet:VE6MGS@VE6MC
* * * * * *  ====================== Meir Green
 * * * * * * ====================== (Internet) [e-mail]
* * * * * *  ====================== [e-mail]  [e-mail]
 * * * * * * ====================== (Amateur Radio) N2JPG

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

Date: 11 Jun 91 00:40:22 GMT
From: swrinde!elroy.jpl.nasa.gov!turnkey!orchard.la.locus.com!devnet.la.locus.com![e-mail]
To: [e-mail]

References <06.Jun.91.10:, 21:, 32.BST.#[e-mail]>r
Subject : Re: The 'hidden transmitter' problem.

In article <06.Jun.91.10:21:32.BST.#[e-mail]>,
[e-mail],
(Pete Lucas, NCS-TLC, Holbrook House, Swindon) writes:

>The 'hidden transmitter' problem will be with us forever; in a classic
>client-server system, something like Hubmaster is a way to solve some
>of the grosser deficiencies; but in a true peer-to-peer system its no
>help.

  Why is the hidden transmitter problem with us forever? There are
topologies where there are no hidden transmitters to be concerned with.

>I rather like the idea of a dual-channel system with the second
>channel being used to send 'back off' messages in case you get the
>transmitter-collision problem; this only works if you have true
>full-duplex capability and the TNCs etc. can stop sending in mid-frame
>on receiving a 'backoff'. (Maybe just de-key the TX and let the TNC
>carry on till its finished?) Put the supervisory channel on a different
>frequency, (remember that the supervisory channel would only ever carry
>'backoff' frames so the chance of a collission there is much reduced).

  When designing an extension, consider the existing user base. How
will anybody be able to use this scheme?

  A better approach is to make the entire topology visible to all
nodes; you can do this by taking a standard voice repeater (on a 600kHz)
split, and transmitting through it. No digipeating, mind you; there's
no need since everyone in the topology can hear you. This also means
that all nodes in the topology can willfully defer when the channel is
busy. A better approach is to hook a modem in between the receiver and
transmitter to regenerate the data; the next thing is to use a coherent
DCD to trigger the COR. This arrangement works perfectly with existing
hardware and is relatively simple by itself.

   The N6GPP duplex repeater is one such configuration; the only
thing that causes collisions there on a practical basis are radios
with slow transmit delays; between the time a radio is keyed up and
RF is emitted, one is exposed to a collision. I enjoyed reliable,
efficient coverage to a very large area using GPP.

  The point of enhancements is not to make things more complicated
because you can; the point is to get enhanced or additional functionality
with the least overall additional complication.

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

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

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


Packet-Radio Digest         Wed, 12 Jun 91       Volume 91 : Issue 148

Today's Topics:
               Converting modem to TNC
         Gonetz - KGB/GRU Lightsat service available
               PACKET->Internet Gateway
                packet modems
            PK-88 birdie on 145.01
               portable packet
              Undeliverable mail
               Unix Packet Help Needed
             Wanted: W0RLI Version 13.01
                 X.25

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

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

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

Date: 11 Jun 91 18:53:21 GMT
From: theory.TC.Cornell.EDU![e-mail]
Subject: Converting modem to TNC
To: [e-mail]

In article <[e-mail]> [e-mail] (Willie Smith) writes:
>OK, let's hear from the other side, let's say I have a TNC with (only) a
>9600-baud modem [like the PacComm UP3-9600], and I want to add a 1200-baud
>modem to it.  Does anyone make just the 1200-baud modem as a kit?  Is there
>an easy circuit that would use an Exar 2206(?) or something?  I suspect
>it's easier to build a 1200-baud packet modem from scratch than adapt a
>phone modem....

    Yes!  TI makes a "kit" in the form of a chip:  the TCM3105.  This
chip, a handful of resistors & caps, a crystal, and you have a Bell 202
1200 baud modem.  A friend of mine wired a modem up *inside* a DB25
shell.
    Call your local TI sales droid for a databook & sample.  Single
quantity, these chips run $14, or so.  Not super cheap, but well worth the
price.
--
=  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =
Andrew C. Payne, N8KEI        UUCP:  ...!cornell!batcomputer!payne
              INTERNET:  [e-mail]

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

Date: 11 Jun 91 19:34:25 GMT
From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!mips!apple!well![e-mail]
Subject: Gonetz - KGB/GRU Lightsat service available
To: [e-mail]


The 1 June 1991 issue of Jane's Defence Weekly has an article on
"lightsats" - lightweight, low-orbit, low-cost, short-lived
satellites (pp. 926-7).  Included is a brief description of "the
only truly operational lightsat system in the world," run by
the Soviet Union:

"The most recent generation is known as 'Sextet' in the West and
is launched in groups of six on Proton boosters.  The currently
active constellation of 24 small satellites is referred to by
the Soviets as Gonetz (Messenger).  Gonetz is believed to be
used by the KGB and the GRU for store-and-forward messaging
because their low earth orbit periodically places them out of
range of receiving stations.  It is unclear what, if any,
distinction exists between the military and civilian versions of
Gonetz.

"Last year, an international consortium was formed to market
Gonetz worldwide for civilian digital relay of voice, fax and
data from isolated locations to hub stations. Within the USA,
marketing services are provided for the Consortium of Small
Satellite Constructors and Service Providers (COSSCASP) by New
York-based DYJ Technologies..."

Does anyone have more information about this system?  Like, how
much it costs, and what the phone/address of DYJ Technologies
is?  What frequencies it uses?  Data formats, etc.?

--
!.|.!.|.!.|.!.|.!.|.!.|.!.|.!.|.!.|.!.|.!.|.!.|.!.|.!.|.!.|.!.|.!.|.!.|
Robert Horvitz    1122-1/2 E St. SE    Washington, DC 20003-2232    USA
              uucp:  ...uunet!capital!rhorvitz

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

Date: 9 Jun 91 04:28:48 GMT
From: agate!spool.mu.edu!caen!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!pitt!w2xo![e-mail]
Subject: PACKET->Internet Gateway
To: [e-mail]

In article <[e-mail]> [e-mail] (Robert S. Radvanovsky KC6ONL) writes:

>Don't know if the other message/article was posted here, so I'll request again.
>Does anyone know if a PACKET (either AX.25 and/or TCP/IP) gatewaye exists
>between PACKET radio and Internet?  If so, could someone please state where it
>is located?  If not, why has this not been performed?  Additionally, what would
>be needed in getting set up?
>
I can gateway mail from packet to internet. However, everything coming
from internet to packet must be manually checked for FCC compliance
and I can only deliver internet/usenet mail to addresses that are aliased
to callsigns in my distribution file for internet/usenet mail. The packet
mail headers only allow for amateur call signs as a mail address, so
the bbs mail daemon checks a file of call signs first to determine
if this person (the call signee 8-) ) is reachable via internet/usenet
and then  mails it to him/her using the unix mailer.

To mail to packet from internet/usenet, mail to "[e-mail]" and
make the first line of the message a valid RLI/MBL message command
line followed by a subject line, ie;

SP W7ZZZ@W6ABC<W5QQQ
Burned-out finals
I blew my finals again last night..... etc etc etc
...more text lines
...more text lines
/EX

The last line of the text must be a "/EX", which must begin in
column 1 of the text line. This all you will recognize as standard
packet bbs message form.

Sorry it isn't more elegant, but it's a first hack..

-Jim Durham  ([e-mail]) or packet-wise: [e-mail]

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

Date: 11 Jun 91 01:25:28 GMT
From: swrinde!cs.utexas.edu!convex!mic!letni!rwsys!kf5iw!k5qwb![e-mail]
Subject: packet modems
To: [e-mail]

The modems used for 1200 baud packet are similar to a Bell 202 (201?)
not the Bell 212. The 212 is full duplex with the transmit and receive
at different frequencies. The 202 is simplex ( one direction at a time )
and uses the same tone frequencies both ways. A TNC usually has the
modem built in but most provide for using another such as PSK.

If you find a 202 ( mine was 5 bucks ), you should be able to wire it
to the rs-232 connector and run BAYCOM. You need a circuit to key the
TX and possibly a level control for the mic input. The RX audio works
OK and the modem should have 4-wire strapping to separate them. The
rs-232 to modem wiring is strange too and I don't have that handy.

Best bet is to look for a real TNC.



-------------------------------------------------------------------------
         [e-mail]
73,              utacfd.utarl.edu!letni!kf5iw!k5qwb!lrk
Lyn Kennedy      K5QWB @ N5LDD.#NTX.TX.US.NA
         P.O. Box 5133, Ovilla, TX, USA 75154

-------------- "We have met the enemy and he is us."  Pogo --------------

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

Date: 10 Jun 91 15:08:00 GMT
From: usc!zaphod.mps.ohio-state.edu!ncar!csn!boulder!bohemia!f510.n5000.z200.METRONET.ORG![e-mail]
Subject: PK-88 birdie on 145.01
To: [e-mail]

Yes Jerry! I too have noticed a birdie on 145.01 fron the PK88. I
took the easy way out and switched operation to 145.05 which is used
extensively here in Minnesota. Unfortunately, I don't have any
suggestions for you at this time, but if you come up with anything
i'd appreciate it if you'd pass it on.
Gary [e-mail]
---
 * Origin: The Computer Lab (200:5000/510)

--
Gary Box - via MetroNet node 200:5000/301
UUCP: ...!boulder!bohemia.METRONET.ORG!510!Gary.Box
INTERNET: [e-mail]

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

Date: 10 Jun 91 15:15:00 GMT
From: usc!zaphod.mps.ohio-state.edu!ncar!csn!boulder!bohemia!f510.n5000.z200.METRONET.ORG![e-mail]
Subject: portable packet
To: [e-mail]

Hi Brett. I assume by your message you have access to a portable
computer. In that case you need only add a radio and a TNC. 2 meter
radios can be obtained used for around $100 and a packet only TNC
such as a PK88 run around $120. If you don't have a portable
computer, any portable with terminal capability should be
suffecient. I've used a Radio Shack model 100 with great success.
All this stuff runs on 12 volts so any car battery will do. A deep
cycle marine battery is better, but not necessary. Let me know how
it turns out. My packet address is [e-mail]
Gary
---
 * Origin: The Computer Lab (200:5000/510)

--
Gary Box - via MetroNet node 200:5000/301
UUCP: ...!boulder!bohemia.METRONET.ORG!510!Gary.Box
INTERNET: [e-mail]

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

Date: 11 Jun 91 23:32:00 GMT
From: [e-mail]
Subject: Undeliverable mail
To: [e-mail]

Your message could not be delivered to:

    POLDER@WOLGA

Your message has been enqueued and undeliverable for 12 days.
No further attempts will be made to deliver your messsage.

Your entire message follows:

Date: Thu, 30 May 91 14:05 MET
From: [e-mail]
To: POLDER@WOLGA
Message-id: <[e-mail]>
X-Envelope-to: POLDER@WOLGA
X-VMS-To: Multiple recipients of <[e-mail]>


pr
gen
info

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

Date: 11 Jun 91 13:43:24 GMT
From: amdcad!dgcad!dg-rtp!aquila![e-mail]
Subject: Unix Packet Help Needed
To: [e-mail]

    I would appreciate some advice in piecing together a packet station.

    I will be getting an old GE EXEC (2M) for the radio.

    I have a 10mhz 286. 4mb memory, hard disks, 1 serial, 1 parallel
    (hopefully to remain comitted to the printer), and mono video.

    I have a DOS partition and a Xenix partition (rev 2.3).

    I am not interested in being an intermediate node in any network -
    only a terminal or an endpoint destination. And this for AX.25
    (unless IP is better in my area). My friend in Idaho, whom I'll
    primarily communicate with uses AX.25.

    I have several goals:

        1) Use simple, inexpensive, TNC if possible.

        2) Use outboard TNC if possible.

        3) Use PC for processing horsepower.

        4) Use XENIX for the operating environment. I use
           XENIX the most and the packet software could be
           monitoring the port full time while I did other
           work.

        a) XENIX would mandate code that  was written in C or
           assembler but that used standard i/o functions
           (although I suppose I could write a device driver).
           Sources would probably need to be available.

        5) Have the PC be a "private node" or "BBS" so that
           messages were delivered to my PC instead of having
           to connect as a terminal to read them. I'm not sure
           if my terminology is quite correct here.

           If I can run the software under XENIX then I can
           leave the machine up in the same environment full time
           so message delivery won't be a problem.

        6) To minimize system loading, it would be nice if the
           TNC could be configured to pass only traffic for
           me. I would appreciate knowing how this affects the
           price class of the TNC.

    So, Is this possible? How much of it is? Thanks very much for
    your help. I hope to be making a racket with packet soon!
--

Mike Harris - KM4UL                      [e-mail]
Data General Corporation                 {world}!mcnc!rti!dg-rtp!harrism
Research Triangle Park, NC

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

Date: 11 Jun 91 13:02:44 GMT
From: sdd.hp.com!caen!uwm.edu!linac!att!cbnews![e-mail]
Subject: Wanted: W0RLI Version 13.01
To: [e-mail]

Does anybody know where I can get the KA9Q packet software? I'd like
to try it out and learn more about it.

Andrew Gaunt
KA1YLG
[e-mail]
ZZ

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

Date: 10 Jun 91 15:04:00 GMT
From: usc!rpi!zaphod.mps.ohio-state.edu!ncar!csn!boulder!bohemia!f510.n5000.z200.METRONET.ORG![e-mail]
Subject: X.25
To: [e-mail]

Hi Fred. The AX.25 standard is available from the{ ARRL as "AX.25
AMATEUR PACKET-RADIO LINK-{LAYER PROTPCOL". I have this book and it
gives all the necessary internals of the protocol, which is very
similar the standard AX.25. Let me know how your project turns out
Gary; [e-mail]
---
 * Origin: The Computer Lab (200:5000/510)

--
Gary Box - via MetroNet node 200:5000/301
UUCP: ...!boulder!bohemia.METRONET.ORG!510!Gary.Box
INTERNET: [e-mail]

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

Date: 11 Jun 91 17:23:43 GMT
From: [e-mail]
To: [e-mail]

References 32.BST.#[e-mail]>, <[e-mail]>, <[e-mail]>
Subject : Re: The 'hidden transmitter' problem.

Yes, a "full duplex' (i.e., real-time) repeater will allow stations
within its service range to avoid hidden terminal, thus nearly
completely avoiding collisions, so you can run maxframe back up to 7.
Also, if the carrier can be kept on between transmissions, you can
completely avoid squelch opening delays, so you can cut 'way down on
TXD and speed up the whole channel.

If the repeater is built using a K9NG modem as an FSK regenerator
in the repeat path going from repeater receiver demodulator to its
transmitter modulator, voice won't pass through the repeater without
extreme distortion, so it won't get taken over by the local old farts,
but it will pass BOTH 1200 AFSK and 9600 bps FSK, so it can be shared
between the two groups.

Here in SoCal, I've built one such system, which we hope to have in
mountaintop service sometime soon.  We used a 50w Motorola Mitrek with
the power output throttled back a bit, a K9NG, and a TNC at 9600 bps.
People who run 1200 bps only get the repeater, but the 9600 bps users
get both repeater usage AND network node access, thus encouraging more
people to upgrade to 9600 bps.

(If you do this, you do NOT set the network node to full duplex, since
the users aren't full duplex.  That way it won't try to ACK their
packets while they're still transmitting.)

My hope would be to place repeaters like this in each community, and
then link them together on some other band using some intelligent
routing scheme.  A person would connect to the repeater's node for all
his network services, and with one in each community, few people would
ever be out of range.

I think it's a good way to go.
    - Brian

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

Date: 11 Jun 91 22:41:41 GMT
From: sdd.hp.com!elroy.jpl.nasa.gov!turnkey!orchard.la.locus.com!devnet.la.locus.com![e-mail]
To: [e-mail]

References 32.BST.#[e-mail]>, <[e-mail]>, <[e-mail]>
Subject : Re: The 'hidden transmitter' problem.


I wrote:
>  A better approach is to make the entire topology visible to all
>nodes; you can do this by taking a standard voice repeater (on a 600kHz)
>split, and transmitting through it. No digipeating, mind you; there's
>no need since everyone in the topology can hear you. This also means

And then Kim Elmore replies:

>       Is this really true?  I ask the question in all sincerity because
>I wonder about stations on the repeater fringe that communicate with stations
>*beyond* the repeater fringe.  What about that case?  Isn't there then still a
>hidden transmitter?  I understand that there will be *fewer* hidden
>transmitters, but they won't really go away, will they?  I'm no networking
>topologist, just curious.

   Sure, this could be a problem, if there is another duplex repeater on
the same pair not too far away. It could also be a problem if people are
running simplex packet on the repeater input frequency. Either case is
not too likely.

>       I also see situations where this could make things *worse* instead
>of better: two stations with limited range that can hear each other fine
>but don't need the repeater.  It's the old saw of "QSY if you can work
>direct" but voice users seldom do this (around Boulder, anyway) so why
>should packet users be any better?  In this case, two stations who don't
>need the repeater wind up using it regardless.

  I refer to this as the "watering hole" syndrome; everybody wants to
be where everybody else is. This can lead to greater congestion on
pair than otherwise might be experienced; however, keep in mind that
the same thing can happen on simplex frequencies, where the degradation
suffered due to congestion would be worse.

  At the same time, the watering hole has advantages... everyone else
is there, afterall. It doesn't make sense for everyone in the coverage
area to run NET/ROM (it offers no advantage in accessing other local
nodes, and one NET/ROM server could link off of the duplex pair). TCPIP
works quite well in a duplex system, and offers so much more functionality
than simple AX.25.

>       Aside from avoiding the store-and-foreward delay, will such a system
>be significantly faster?  Why not just up the speed, aside from the fact that
>the world is currently locked into 1200 bps?

   By making the topology visible to all participants, the window for
collisions (especially due to hidden transmitters) is almost entirely
eliminated. This alone provides a sizable advantage when the channel
starts to become loaded. A duplex repeater provides advantages at
ANY baud rate; in fact, I think it can be shown that the advantages
are more pronounced at higher baud rates.

  The duplex repeater does not so much speed things up under ideal
conditions (it does a little), but it avoids serious performance
degradation under average (or poor) conditions. This is more like
a quality versus quantity issue.

>       I sort of think it's smarter technically and politically to move the
>packet up in both speed and frequency, but many folks locally feel that the
>cost would be prohibitive.  I wonder... Duplex repeaters aren't cheap, either,
>and I'm not sure that such an approach would be classed as "advancing the
>state of the art" or as "bending over backwards to maintain the status quo".

 Sure, I agree that higher speeds and frequencies have appeal, but they
start to cost *everybody* more. A duplex repeater improves the channel
utilization enormously for a large number of users without requiring any
of the users to invest in new radios, TNCs or computers.

  Rather than taking my word for it, read the paper by Scott Avent in
the proceedings of the Seventh ARRL Computer Networking Conference (In
fact, spend the $50 or so, and buy the volumes for the entire series of
the CNCs. They're worth their weight in gold). Figures are presented
which indicate that a duplex repeater will provide at least 68% better
throughput on a loaded channel than a digipeater.  This number is
probably indicative of the bottom end of the range (i.e. you may
get better mileage). I'd speculate that a poorly connected topology of
2400 baud nodes (with hidden xmitters, etc) probably would not outperform
a topology connected well by a duplex repeater.


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

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

Date: 11 Jun 91 16:31:53 GMT
From: swrinde!cs.utexas.edu!asuvax!ncar!virga.ucar.edu![e-mail]
To: [e-mail]

References 21:, 32.BST.#[e-mail]>, <[e-mail]>
Subject : Re: The 'hidden transmitter' problem.


 stuff deleted...


>  A better approach is to make the entire topology visible to all
>nodes; you can do this by taking a standard voice repeater (on a 600kHz)
>split, and transmitting through it. No digipeating, mind you; there's
>no need since everyone in the topology can hear you. This also means

 stuff deleted...

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


    Is this really true?  I ask the question in all sincerity because
I wonder about stations on the repeater fringe that communicate with stations
*beyond* the repeater fringe.  What about that case?  Isn't there then still a
hidden transmitter?  I understand that there will be *fewer* hidden
transmitters, but they won't really go away, will they?  I'm no networking
topologist, just curious.

    I also see situations where this could make things *worse* instead
of better: two stations with limited range that can hear each other fine
but don't need the repeater.  It's the old saw of "QSY if you can work
direct" but voice users seldom do this (around Boulder, anyway) so why
should packet users be any better?  In this case, two stations who don't
need the repeater wind up using it regardless.

    Aside from avoiding the store-and-foreward delay, will such a system
be significantly faster?  Why not just up the speed, aside from the fact that
the world is currently locked into 1200 bps?

    I ask these questions because there has been some suggestions locally
that duplex repeaters are the way to avoid the hazards of NET/ROM or TheNet
or whatever is used at the network level.  Also, these have been suggested as
a "better" way to utilize the duplex channels than are voice repeaters.  I
really don't know if that's true or not, but all of the voice pairs are
taken on the Front Range.  Wouldn't it be smarter to have nodes
ingest the slow data and be linked on a different band zipping along at some
significantly higher rate, like 56k bps?  Or is there something I'm missing
here?

    I sort of think it's smarter technically and politically to move the
packet up in both speed and frequency, but many folks locally feel that the
cost would be prohibitive.  I wonder... Duplex repeaters aren't cheap, either,
and I'm not sure that such an approach would be classed as "advancing the
state of the art" or as "bending over backwards to maintain the status quo".

    Somebody educate me!

                73, Kim Elmore, N5OP [44.20.0.67]
                    [e-mail]

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

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


Packet-Radio Digest         Thu, 13 Jun 91       Volume 91 : Issue 149

Today's Topics:
              ATV - High Speed Digital ?
                cable problem
           Converting modem to TNC (2 msgs)
          memory problems with nos_0531.exe (2 msgs)
              Packet at 56kbps: How to?
         Param command broken in NOS_0423.EXE
              PSE HELP : TNC-220 & KISS
             Undeliverable mail (2 msgs)
                 W0RLI 13.01
           Where to get BBS software for Xerox-820?

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

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

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

Date: 12 Jun 91 14:55:04 GMT
From: swrinde!cs.utexas.edu!wuarchive!emory!wa4mei!ke4zv![e-mail]
Subject: ATV - High Speed Digital ?
To: [e-mail]

In article <[e-mail]> [e-mail] (Mark Zenier) writes:
>Has anyone tried to use ATV equipment to send high speed
>digital information, along the lines of the "back up
>your computer disk on your VCR", by making a modem that
>outputs something that looks like a standard TV signal?
>
>Should be good for over 4 Mbps, and if you work it right
>you can put your ID out as a visual signal.

We use this technology to back up our Quantel still store systems.
I decided to run some simple tests. We normally do digital dumps
to one inch professional tape machines with signal to noise ratios
of around 50 db. The encoding technique is fairly tolerant of small
"dropouts" due to tape wear, but longer dropouts due to tape damage
confuse the system. This would correspond to short and long noise
bursts respectively on a radio channel. I dubbed the signal back
and forth between one inch and VHS tape multiple times. This degraded
signal to noise and added the equivalent of some multipath distortion
due to the "smearing" of VHS technology. I got a lot of read errors
on the resulting tape. This isn't real over the air testing, but it
looks like the system would work on P5 transmissions if multipath
is minimized.

The protocol used takes advantage of redundancy and FEC, but the
modulation method, encoding as white and black pixels in an AM
TV field, leaves something to be desired. A direct PSK encoding
would be much better. Also the protocol is designed for half-duplex
with large block sizes, again not ideal for two way packet style
transmissions.

Gary KE4ZV

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

Date: 13 Jun 91 02:15:22 GMT
From: [e-mail]
Subject: cable problem
To: [e-mail]

I am having trouble wiring my Yaesu FT-370 HT to my MFJ TNC.  I can get the
receive pins wired up right, but I can't hey the transmit & PTT pins wired up right.  Any help would be appreciated.  I don't read thesse groups often so
please E-mail any answers.  Thanks.

Brian Hartsfield
[e-mail]
WD4AEJ

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

Date: 12 Jun 91 18:48:43 GMT
From: intran![e-mail]
Subject: Converting modem to TNC
To: [e-mail]

There has been a substantial amount of talk about converting a current Modem to
a TNC.  Eh, try calling TAPR, get the TNC-2 kit (about $100), build it, and
you are all set.  You have KISS if you want, options for a PBBS, and it is
compatible with all the BBS type software.  This free's up the PC (excepth of
course when you want to read the mail everyone sent you), or when you
want to send folks mail.

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

Date: 12 Jun 91 15:27:39 GMT
From: sdd.hp.com!swrinde!cs.utexas.edu!wuarchive!emory!wa4mei!ke4zv![e-mail]
Subject: Converting modem to TNC
To: [e-mail]

In article <[e-mail]> [e-mail] (Willie Smith) writes:
>
>Also, I don't know the exact details, but aren't the modem standard
>different?  I seem to remember most 1200-baud phone modems being Bell 212,
>whille packet modems are Bell 303 (or something).

Bell 202.

>OK, let's hear from the other side, let's say I have a TNC with (only) a
>9600-baud modem [like the PacComm UP3-9600], and I want to add a 1200-baud
>modem to it.  Does anyone make just the 1200-baud modem as a kit?  Is there
>an easy circuit that would use an Exar 2206(?) or something?  I suspect
>it's easier to build a 1200-baud packet modem from scratch than adapt a
>phone modem....

Kantronics makes a daughter board for their DE56 that does 1200 baud.
It's $79 though so it's cheaper just to build your own from the Exar
chips or use a 7910 like Kantronics does in their 1200 baud designs.
There's also a single chip solution by TI used by Pac-Comm. Overall
the Exar chips seem to work best.

Gary KE4ZV

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

Date: 12 Jun 91 13:36:21 GMT
From: usc!rpi!zaphod.mps.ohio-state.edu!caen!spool.mu.edu!cs.umn.edu!uc!apctrc!voyager![e-mail]
Subject: memory problems with nos_0531.exe
To: [e-mail]

Yesterday, I downloaded what I understand is the latest version of nos.  The
version I got is the modified version from PA0GRI (did I get his call right?),
and was the 05/31 version.  If it helps, I got it from the ka9q area on
wb3ffv's bbs system.

now, I've run into lots of problems with all versions of nos regarding
memory, but these usually involve nos eating up RAM and never giving it
back...thus eventually locking the system and requiring a hard reboot.  (If
anyone knows a fix for this, please pass it along.)

But, the problem I'm facing here is even worse --- with about 590 k of RAM
sitting there wide open (after mess-dos or 4dos, depending on which computer
we're talking about, was loaded), nose0531.exe refuses to run on both of
the computers I tried it on --- error message from each was to the effect
that the program is too large to fit in memory.

am I missing something here?  did I perhaps assume incorrectly that this
executable (in mess-dos's .exe naming style) was for dos?  or has someone
else run into this?

any help would be greatly appreciated.....
   --jim

Standard disclaimer....These thoughts are mine, not my employer's.

------------------------------------------------------------------------------
Share and Enjoy!  (Sirius Cybernetics Corporation, complaints division)
73, de n5ial

Internet:  [e-mail]    or    [e-mail]
Amateur Radio:
   TCP/IP:    [e-mail] (44.72.47.193)
   Packet:    BBS went QRT for good...still searching for new one.
------------------------------------------------------------------------------

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

Date: 12 Jun 91 21:02:02 GMT
From: epic![e-mail]
Subject: memory problems with nos_0531.exe
To: [e-mail]

In article <[e-mail]>, [e-mail] (Jim Graham) writes:
|> But, the problem I'm facing here is even worse --- with about 590 k of RAM
|> sitting there wide open (after mess-dos or 4dos, depending on which computer
|> we're talking about, was loaded), nose0531.exe refuses to run on both of
|> the computers I tried it on --- error message from each was to the effect
|> that the program is too large to fit in memory.

Yes, NOS is getting far too large for MS-DOS. This is particularly
true with some of the "value added" versions that have extra features
not in my "base" code.

Your only real option is to go into the source file config.h and turn off
all the features you don't need in your configuration. Then remake the
net.exe file and you'll see that it has shrunk considerably.

There are two longer-term solutions for this problem: move to UNIX for
the fancy, large applications (this has the advantage that many of the
applications are already freely available in the Internet/Usenet world
and do not have to be reinvented for NOS), and recompiling NOS to run
under a DOS extender on 386 class machines. I have not yet begun to
work on this latter approach, but I am starting to get interested
particularly since I've heard that there is a GNU C version for the
386 with a DOS extender.

Phil

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

Date: 11 Jun 91 21:29:43 GMT
From: usc!zaphod.mps.ohio-state.edu!wuarchive!emory!wa4mei!ke4zv![e-mail]
Subject: Packet at 56kbps: How to?
To: [e-mail]

In article <[e-mail]> [e-mail] (Charlie Turner) writes:
>How is 56kbps (commonly) achieved for packet radio? I have heard of
>the "Grapes" modem used in conjunction with KA9Q for high speed
>TCP/IP on the 220mHz band.

We use the KA9Q code as a base for our switch code with our 56kb modem,
but it is not limited to TCP/IP. It will happily act as a digi or netnode
for any AX25 frame regardless of any upper layer protocol in use.

>Is some kind of KISS mode TNC needed for this setup, or does the
>PC need a special high speed COM I/O board of some kind?

We furnish a special KISS56 eprom image and modification instructions
for using a TNC as the interface between the 56kb modem and the computer.
However, a special COM I/O board is better. We recommend the Ottawa PI
card and the Gracilis Packet Twin card. A DRSI card will also work, but
will totally flatline a PC while receiving a 56kb packet. Gracilis also
has a very high performance standalone card that will drive three of our
modems simultaneously while acting as a switch. The Kantronics DE56 is
capable of driving two of the modems while acting as a switch.

>There is some interest in my area (mid MO) in building a state wide
>high speed packet network. Most of the folks are thinking 9600 bps
>but I'm wondering why we shouldn't go further and use 56kbps instead.
>
>I'd appreciate any comments about the radio and PC hardware needed for
>56kbps. Perhaps the 450mHz band would be better than the 220mHz band.
>Perhaps some kind of spread spectrum at 900mHz under part-15 at
>100+kbps would be better still!

We run in the 433 Mhz link band here in Georgia as well as having some
links on 222 Mhz. If you are going to use a PC as your switch, you need
an AT class machine with at least a 5Mb hard disk. A couple of DRSI
cards will service your low speed ports, a Packet Twin will drive the
56kb modem and a 9600 baud link, and a standard COM port will handle
the phone modem for remote sysop use. Or you can use external KISS and
KISS56 TNCs and some hacked up 16550 equipped COM ports. You tend to
run out of interrupts quickly. We find that old 5 MB hard disks hold
up better than floppies at our un-airconditioned mountaintop sites.
For 56kb, the modem *is* a radio operating on 29 Mhz. You need a
transverter to bump the signal up to 220 or 440. We use Microwave
Modules MMT432S and Sinclabs transverters. Most any *linear* transverter
will work.

Gary KE4ZV

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

Date: 12 Jun 91 20:47:58 GMT
From: epic![e-mail]
Subject: Param command broken in NOS_0423.EXE
To: [e-mail]

In article <[e-mail]>, [e-mail] (Robert van den Nieuwendijk, tel. [phone]) writes:
|> In the source listings I have seen that the code has changed but it is not
|> clear to my why it changed and how it works now. In the previous version
|> I could at least send any character I wanted to the TNC. This seems not to
|> be possible anymore.

Yes, a few months ago I redid the whole param internals in NOS, and I
guess this has been picked up by PA0GRI. The idea was to allow symbolic
parameter names instead of forcing people to remember numbers, and to
provide a much more general purpose interface for hooking on other control
parameters. For example, with the param command you can now drop DTR to
a modem by saying "param com1 dtr 0". I also wanted there to be a common
"param" user interface for devices other than asynch ports talking to
KISS TNCs - internal HDLC devices, for example.

There's a table of parameters that can be extended to include whatever
special parameters a given device supports.

Phil

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

Date: 12 Jun 91 20:44:36 GMT
From: epic![e-mail]
Subject: PSE HELP : TNC-220 & KISS
To: [e-mail]

In article <[e-mail]>, [e-mail] (Robin Alexander) writes:
|> My problem is that the 220 is persistently missing packets during an
|> ftp or telnet transfer, and I just cannot work out why.
[...]
|> Which brings me to the conclusion that the TNC does not like long packets,
|> maybe the buffer gets full....

Robin,

Yes, this is the most likely cause. To confirm it, specify a small
(e.g., 100 bytes) TCP MSS value and try to pull over a file with FTP.
If this works, then the problem is most likely a hardwired limit on the
size of incoming frames.

The original AX.25 spec limited frames to 256 bytes max, but many
TCP/IP operators run larger frames to improve the efficiency of large
file transfers. The original KISS code by K3MC could handle
arbitrarily large frames, but some vendor reimplementations have hard-coded
limitations.

Phil

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

Date: 7 Jun 91 23:31:00 GMT
From: [e-mail]
Subject: Undeliverable mail
To: [e-mail]

Your message could not be delivered to:

    POLDER@WOLGA

Your message has been enqueued and undeliverable for 9 days.
The mail system will continue to try to deliver your message
for an additional 3 days.

The beginning of your message follows:

Date: Wed, 29 May 91 15:45 MET
From: [e-mail]
Subject: Packet-Radio Digest V91 #134
To: POLDER@WOLGA
Message-id: <[e-mail]>
X-Envelope-to: POLDER@WOLGA
X-VMS-To: Gerrit Polder PA3BYA <[e-mail]>

Packet-Radio Digest         Wed, 29 May 91       Volume 91 : Issue 134

Today's Topics:
           AX.25 Packet TNC Timing Parameters HELP!

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

Date: 7 Jun 91 23:31:00 GMT
From: [e-mail]
Subject: Undeliverable mail
To: [e-mail]

Your message could not be delivered to:

    POLDER@WOLGA

Your message has been enqueued and undeliverable for 9 days.
The mail system will continue to try to deliver your message
for an additional 3 days.

The beginning of your message follows:

Date: Wed, 29 May 91 15:40 MET
From: [e-mail]
To: POLDER@WOLGA
Message-id: <[e-mail]>
X-Envelope-to: POLDER@WOLGA
X-VMS-To: Gerrit Polder PA3BYA <[e-mail]>

remote execution        [uucp job mwoodA1d65 (5/29-7:53:00)]
    rmail attcc!ulab!area88!tom
exited with status 2

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

Date: 13 Jun 91 01:25:35 GMT
From: [e-mail]
Subject: W0RLI 13.01
To: [e-mail]

I was about to upload this to tomcat, when I checked and
found it there already ...
SO, it IS available by anonymous FTP on tomcat.gsfc.nasa.gov
in the /bbs/w0rli directory, as  MB1301.EXE

73, Dave

ve3gyq @ ve3gyq.on.can.na (packet)
ria.ccs.uwo.ca!toth!dave
[e-mail]

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

Date: 12 Jun 91 17:09:00 GMT
From: [e-mail]
Subject: Where to get BBS software for Xerox-820?
To: [e-mail]

Hello:

I am about to resurrect my Xerox 820 packet BBS and am looking for a
recent version of the W0RLI software (or replacement).  I have version
11-point-something from about three years ago, but there have been some
changes in mail addressing since then.  Is anybody still maintaining
this software?  Where can I get a copy?

Jeff Austen     k9ja     bitnet: jra1854@tntech

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

Date: 12 Jun 91 19:05:33 GMT
From: pacbell.com!mips!swrinde!elroy.jpl.nasa.gov!grian![e-mail]
To: [e-mail]

References 21:, 32.BST.#[e-mail]>, <[e-mail]>
Subject : Re: The 'hidden transmitter' problem.

[e-mail] (Dana H. Myers) writes:

>In article <06.Jun.91.10:21:32.BST.#[e-mail]>,
>[e-mail],
>(Pete Lucas, NCS-TLC, Holbrook House, Swindon) writes:

>>The 'hidden transmitter' problem will be with us forever; in a classic
>>client-server system, something like Hubmaster is a way to solve some
>>of the grosser deficiencies; but in a true peer-to-peer system its no
>>help.

>  Why is the hidden transmitter problem with us forever? There are
>topologies where there are no hidden transmitters to be concerned with.

>>I rather like the idea of a dual-channel system with the second
>>channel being used to send 'back off' messages in case you get the
>>transmitter-collision problem; this only works if you have true
>>full-duplex capability and the TNCs etc. can stop sending in mid-frame
>>on receiving a 'backoff'. (Maybe just de-key the TX and let the TNC
>>carry on till its finished?) Put the supervisory channel on a different
>>frequency, (remember that the supervisory channel would only ever carry
>>'backoff' frames so the chance of a collission there is much reduced).

>  When designing an extension, consider the existing user base. How
>will anybody be able to use this scheme?

>  A better approach is to make the entire topology visible to all
>nodes; you can do this by taking a standard voice repeater (on a 600kHz)
>split, and transmitting through it. No digipeating, mind you; there's
>no need since everyone in the topology can hear you. This also means
>that all nodes in the topology can willfully defer when the channel is
>busy. A better approach is to hook a modem in between the receiver and
>transmitter to regenerate the data; the next thing is to use a coherent
>DCD to trigger the COR. This arrangement works perfectly with existing
>hardware and is relatively simple by itself.

>   The N6GPP duplex repeater is one such configuration; the only
>thing that causes collisions there on a practical basis are radios
>with slow transmit delays; between the time a radio is keyed up and
>RF is emitted, one is exposed to a collision. I enjoyed reliable,
>efficient coverage to a very large area using GPP.

>  The point of enhancements is not to make things more complicated
>because you can; the point is to get enhanced or additional functionality
>with the least overall additional complication.

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

When I worked at Hughes Aircraft, the gentleman who keeps that repeater
working right had an adjcent cubicle.  We had several long talks over
lunch about just this topic.  I was suitably impressed with this idea,
and wondered why there were not more packet _re_peaters (as opposed to
the digipeater).

Anyway, if anybody is interested, the 'GPP system is a regular Micor
repeater with a Bell 202 modem in the audio path, wired back-to-back for
regeneration via a few jumpers on the RS-232 plug.  Big Deal.
Supervisory control is via a command decoder on another radio channel.

--
Mike Morris   WA6ILQ   | This space intentionally left blank.
PO Box 1130            | All flames to /dev/null please.
Arcadia, CA. 91077     | All opinions must be my own since nobody pays
818-447-7052 evenings  | me enough to be their mouthpiece...

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

Date: 12 Jun 91 21:29:20 GMT
From: epic![e-mail]
To: [e-mail]

References <[e-mail]>, <[e-mail]>, <[e-mail]>
Reply-To : [e-mail]
Subject : Re: The 'hidden transmitter' problem.

In article <[e-mail]>, [e-mail] (Brian Kantor) writes:
|> Yes, a "full duplex' (i.e., real-time) repeater will allow stations
|> within its service range to avoid hidden terminal, thus nearly
|> completely avoiding collisions, so you can run maxframe back up to 7.

I don't completely agree with this. Several years ago when I analyzed
the problem of optimizing maxframe, I concluded that it should be 1 on
*any* half duplex channel, regardless of whether there are any hidden
terminals. You should instead vary the *packet length* in response to
changing bit-error-rate conditions. Of course, with the one-packet-per
frame methods we have for encapsulating IP datagrams, it is not always
possible to send large frames, so in some situations you might still
do better by increasing maxframe above 1. But you could still do
better on a good path by keeping maxframe=1 and enlarging the data
field to the optimum value.

Note also that for the full-duplex repeater to really pay off, you
need full duplex user terminals as well so you can detect collisions
and abort transmissions before you've wasted a lot of channel time.
Brian has been doing this with voice in his car for some time with a
full duplex UHF transceiver - he can instantly tell when he's doubling
with somebody through the repeater, or when he's in a bad spot. Works
like a charm.

Some thoughts on full-duplex digital repeaters in general:

Yes, they do indeed go a long way towards eliminating hidden terminals
and the channel-access inefficiencies that they cause. But this does
NOT necessarily make them the most efficient way to use spectrum. The
problem is the same as with FM voice repeaters: a frequency pair is
occupied over a very wide service area, even if the stations talking
to each other are immediate neighbors.

For this reason I believe the problems of simplex channel access with
omnidirectional antennas are still worth solving. A collection of
"digipeaters", properly designed, could potentially carry more total
bits/sec/square kilometer than a single high-level full duplex
repeater covering the same area because of the possibility of
simultaneously reusing the spectrum several times within the coverage
area.

Now I use the term "digipeater" generically - I do NOT mean
digipeaters as we now know them. Although they would receive and
automatically retransmit packets on the same frequency, these
"digipeaters" would have automatic transmitter power control, and they
would use automatic routing algorithms that minimize the total RF
energy expended on moving a packet INSTEAD OF minimizing the number of
hops required. In other words, it is better (in the sense that it
maximizes the total carrying capacity of the spectrum) to use a chain
of many closely-spaced low power repeaters to carry your data than to
use a few widely-spaced high power repeaters. Even though there are
more transmitters in the former case, the total RF energy required
(summed across all the repeaters) would be much less because of the
smaller path loss between stations.  More precisely, although the
number of transmitters goes up inversely linearly as the repeater
spacing is decreased, the RF propagation path loss goes down with at
least the square of the repeater spacing, or perhaps even the cube or
the fourth power of the distance given real-world paths with
obstructions. This more than compensates for the extra transmissions.

As a result, "collateral RF pollution" to stations not in the
immediate path of the packet would be greatly minimized, thereby
allowing stations in those other areas to carry traffic at the same
time.

Phil

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

Date: 11 Jun 91 21:06:08 GMT
From: usc!zaphod.mps.ohio-state.edu!wuarchive!emory!wa4mei!ke4zv![e-mail]
To: [e-mail]

References <[e-mail]>, <[e-mail]>, <[e-mail]>,
Reply-To : [e-mail] (Gary Coffman)
Subject : Re: Converting modem to TNC

In article <[e-mail]> [e-mail] (Mike Young) writes:
>In article <[e-mail]> [e-mail] (Giovanni Moretti) writes:
>>
>>If, on the other hand, all you want to do is USE the modem to give you
>>a packet station, then this should be possible, if you have either a
>>PC or a C64 computer.  There are two programs for a PC that will do
>>all the packetising and de-packetising for you, all you need is a
>>dumb modem and a radio.
>
>       Does anybody have the straight scoop on how to go about interfacing
>a dumb (or Hayes-compatible, for that matter) 1200 baud modem to one's
>HT and PC, for use by PMP or baycom? I have a PC and the PMP code, and what
>I believe is a working 1200 baud modem (flea market special, don'cha know:-),
>but lashing them all together seems to leave a lot of mental loose ends.
>Particularly on the modem <-> radio side, since the modem expects to see Ma
>Bell out there...
>
>       Any tips gladly appreciated. Followups to this group.

Hayes, and other, telephone modems use Bell 212 tones for 1200 baud. Packet
uses Bell 202 tones. They are *not* the same. That helpful little Z8 in the
modem gets in your way too. Smartmodems are only smart for telephone use.
They try to be stupidly helpful on packet and screw up the works. Forget
about trying to use your phone modem and build or buy a Bell 202 modem.
The standard TAPR circuit using two Exar chips works fine.

Gary KE4ZV

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

Date: 12 Jun 91 15:19:35 GMT
From: usc!cs.utexas.edu!wuarchive!emory!wa4mei!ke4zv![e-mail]
To: [e-mail]

References 21:, 32.BST.#[e-mail]>, <[e-mail]>
Reply-To : [e-mail] (Gary Coffman)
Subject : Re: The 'hidden transmitter' problem.

In article <[e-mail]> [e-mail] (Dana H. Myers) writes:
>In article <06.Jun.91.10:21:32.BST.#[e-mail]>,
>[e-mail],
>(Pete Lucas, NCS-TLC, Holbrook House, Swindon) writes:
>
>>The 'hidden transmitter' problem will be with us forever; in a classic
>>client-server system, something like Hubmaster is a way to solve some
>>of the grosser deficiencies; but in a true peer-to-peer system its no
>>help.
>
>  Why is the hidden transmitter problem with us forever? There are
>topologies where there are no hidden transmitters to be concerned with.
>
>  A better approach is to make the entire topology visible to all
>nodes; you can do this by taking a standard voice repeater (on a 600kHz)
>split, and transmitting through it. No digipeating, mind you; there's
>no need since everyone in the topology can hear you. This also means
>that all nodes in the topology can willfully defer when the channel is
>busy. A better approach is to hook a modem in between the receiver and
>transmitter to regenerate the data; the next thing is to use a coherent
>DCD to trigger the COR. This arrangement works perfectly with existing
>hardware and is relatively simple by itself.
>
>   The N6GPP duplex repeater is one such configuration; the only
>thing that causes collisions there on a practical basis are radios
>with slow transmit delays; between the time a radio is keyed up and
>RF is emitted, one is exposed to a collision. I enjoyed reliable,
>efficient coverage to a very large area using GPP.
>
>  The point of enhancements is not to make things more complicated
>because you can; the point is to get enhanced or additional functionality
>with the least overall additional complication.

The system is even better if you operate cross-band full duplex. No
duplexers are required so even the home user can run full duplex. Then
true collision detection as well as collision avoidance can be practiced.
On an active 56kb system this is a real plus. With the long frame times
of typical 1200 baud systems, it's even better. Bit regenerators are
not much help at 1200 baud in most cases. Since there is typically a
one bit time delay through the regenerator, the opportunity for collisions
increases. If the signal is strong enough to be decoded at the repeater,
the repeated signal is apt to be good enough to decode at the destination
as well. The disadvantage of the one bit time delay usually outweighs the
small advantage of bit regeneration. Bit regeneration is usually worthwhile
at 56kb since a linear transponder would be needed to pass the signal
transparently. The best repeaters use long hang times so keyup delays
at the repeater are minimized. An adaptive level one protocol is needed
to allow the user to take advantage of this. He needs a fairly long Txd
to bring up the quiescent repeater, but then needs a shorter Txd as long
as the machine remains active.

Gary KE4ZV

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

Date: 12 Jun 91 16:11:41 GMT
From: sdd.hp.com!cs.utexas.edu!wuarchive!emory!wa4mei!ke4zv![e-mail]
To: [e-mail]

References 32.BST.#[e-mail]>, <[e-mail]>, <[e-mail]>'
Reply-To : [e-mail] (Gary Coffman)
Subject : Re: The 'hidden transmitter' problem.

In article <[e-mail]> [e-mail] (Kim Elmore) writes:
>
>> from Dana H. Myers KK6JQ
> stuff deleted...
>
>>  A better approach is to make the entire topology visible to all
>>nodes; you can do this by taking a standard voice repeater (on a 600kHz)
>>split, and transmitting through it. No digipeating, mind you; there's
>>no need since everyone in the topology can hear you. This also means
>
> stuff deleted...
>
>       Is this really true?  I ask the question in all sincerity because
>I wonder about stations on the repeater fringe that communicate with stations
>*beyond* the repeater fringe.  What about that case?  Isn't there then still a
>hidden transmitter?  I understand that there will be *fewer* hidden
>transmitters, but they won't really go away, will they?  I'm no networking
>topologist, just curious.

If this occurs, it means you haven't done your job in coordinating LAN/MAN
frequency use. There shouldn't be two LAN/MAN systems that share a common
fringe coverage area on the same frequency pair.

>       I also see situations where this could make things *worse* instead
>of better: two stations with limited range that can hear each other fine
>but don't need the repeater.  It's the old saw of "QSY if you can work
>direct" but voice users seldom do this (around Boulder, anyway) so why
>should packet users be any better?  In this case, two stations who don't
>need the repeater wind up using it regardless.

This is simply poor operating practice. One should never use simplex
on a duplex channel, voice or digital. The users should always go
through the repeater, or move to another frequency. As long as they
go through the repeater, the advantage to the network of collision
avoidance remains. If they do move off frequency, then the load on
the system decreases. Either is acceptable practice. Trying to work
simplex on the duplex pair however is *never* good practice.

>       Aside from avoiding the store-and-foreward delay, will such a system
>be significantly faster?  Why not just up the speed, aside from the fact that
>the world is currently locked into 1200 bps?

Yes the *system* is significantly faster though individual user pairs may
experience a slightly slower channel. Each individual user pair experiences
a slight slowdown due to the additional keyup delay time of the repeater,
but the overall system experiences a major speedup due to avoidance of
collisions. A collision costs an entire packet frame time while the repeater
delay costs only a few bit times. This advantage is always true regardless
of basic channel baud rate.

>       I ask these questions because there has been some suggestions locally
>that duplex repeaters are the way to avoid the hazards of NET/ROM or TheNet
>or whatever is used at the network level.  Also, these have been suggested as
>a "better" way to utilize the duplex channels than are voice repeaters.  I
>really don't know if that's true or not, but all of the voice pairs are
>taken on the Front Range.  Wouldn't it be smarter to have nodes
>ingest the slow data and be linked on a different band zipping along at some
>significantly higher rate, like 56k bps?  Or is there something I'm missing
>here?

There is a major difference between user LAN/MANs and backbone trunks.
Duplex operation is almost always a major win for LAN/MAN operations.
Proper point to point links and non-contending frequencies are the best
methods of managing backbones. Full duplex gives thruput advantages to
a backbone channel since data can be flowing in both directions between
switches simultaneously, but properly designed backbones never have problems
with collisions because frequencies are coordinated so that no more than
one pair of backbone sites can hear each other on the same frequency.
The scheme we use is:

LAN-146mhz-switch-430mhz-switch-222mhz-switch-430mhz-switch-145mhz-LAN

>       I sort of think it's smarter technically and politically to move the
>packet up in both speed and frequency, but many folks locally feel that the
>cost would be prohibitive.  I wonder... Duplex repeaters aren't cheap, either,
>and I'm not sure that such an approach would be classed as "advancing the
>state of the art" or as "bending over backwards to maintain the status quo".
>
>       Somebody educate me!

Moving a large user population up in speed and frequency *is* expensive.
Moving backbones up in speed and frequency is a good idea. Using *one*
expensive repeater to service *many* user stations is a good idea since
the costs can be shared and work out to much less than the cost of upgrading
each and every user individually. In packet, you always have to think in
terms of total system thruput and total system cost rather than individual
thruput and individual cost.

56 kb is a natural for backbones and, as your users put more sophisticated
demands on the network, it becomes very attractive for users as well.
However, for the casual BBS user, or keyboard chatter, 1200 baud is often
sufficient, and if more performance is needed, 9600 baud is often a cheap
upgrade path. 56kb systems are often cheaper than 1200 baud systems if
they must be purchased from scratch, but 1200 and 9600 baud systems can
take advantage of radios already owned by the user and cost him a smaller
*incremental cost*. A cost breakdown that I have done shows 56kb to cost
around $550 while a ground up 1200 baud system costs around $650. But
the existing radio of the 1200 baud user can bring his incremental cost
down to $120. Going to 9600 baud only adds $99 to his incremental cost.

Gary KE4ZV

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

End of Packet-Radio Digest
******************************
Date: Fri, 14 Jun 91 04:30:04 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Junk
Subject: Packet-Radio Digest V91 #150
To: packet-radio


Packet-Radio Digest         Fri, 14 Jun 91       Volume 91 : Issue 150

Today's Topics:
            AMTOR and PC/XT/AT programmes?
           Information on R95 file format required
              KA9Q under MAC-TCP
          Looking for software to work U5MIR
             MBL SOFTWARE - NEWEST VER. ?
            PK-88 birdie on 145.01
                  PK232 Mods
          The 'hidden transmitter' problem.

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

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

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

Date: 7 Jun 91 22:05:30 GMT
From: mcsun!news.funet.fi!ousrvr.oulu.fi!ousrvr![e-mail]
Subject: AMTOR and PC/XT/AT programmes?
To: [e-mail]

Are there any programme awailable for using PC/XT/AT serial port on
amtor mode? It should be possible to use handshake pins as TxD and RxD.
Baycom does that on packet, and only on packet.
I should like to use my rtty modem on amtor.

--


 ------------------------------------------------------------------------
    Marko Wirtanen                     E-mail: [e-mail]
 Rakentajantie 5C 406                  Phone: [phone]
    SF-90570 Oulu                      Ham Radio Call: OH8WM / OH3MMW
      FINLAND

      "Once you are in communications, you will never be out of it"
 ------------------------------------------------------------------------

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

Date: 12 Jun 91 01:45:06 GMT
From: lll-winken!sun-barr!ccut!wnoc-tyo-news!astemgw!kuis!hugw!grape!humpty![e-mail]
Subject: Information on R95 file format required
To: [e-mail]

Hi,

I am working on packet for more than two years in Japan.  Files
outside Japan are coming through DU or YB.  Recently, encoded files
(in R95 format) are coming very often.  Here in Japan, we use the
ish.exe (a Japan originated freeware convert program) to create
encoded files.  The program is so popular here both in wireless
and in wired communication societies, that it is extremely difficult to find
the program that decode R95 format files.

Could anyone give me information on how I can get the utility program that
handles R95 format files?  If it is a freeware or a shareware program,
could anyone upload it in this newsgroup?

   de Kou, JA4MCI @ JG4IVE.JNET4.JPN.AS
       KA2SHO
       [e-mail]



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

Date: 13 Jun 91 19:02:52 GMT
From: cleo.cs.wisc.edu![e-mail]
Subject: KA9Q under MAC-TCP
To: [e-mail]

Is there a version of the KA9Q software that cooperates with MAC-TCP?
The idea is to use AX25 and SL/IP capabilities of the KA9Q package
from the MAC-TCP, so macintosh applications (like terminal emulators, news
readers, etc) can access the packet radio net.

thanks in advance

--mt
+-------------------------------+----------------------------------------------+
|Manolis M. Tsangaris           |Email: [e-mail], pn=Manolis.Tsangaris   |
|Computer Sciences Department   |       /ou=cs/o=uw-madison/p=xnren/a=/c=us    |
|University of Wisconsin-Madison|Phone: [phone]                          |
+-------------------------------+----------------------------------------------+

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

Date: 13 Jun 91 16:40:34 GMT
From: sdd.hp.com!swrinde!elroy.jpl.nasa.gov!ncar!asuvax!anasaz!qip![e-mail]
Subject: Looking for software to work U5MIR
To: [e-mail]

I have a UNIX system (Interactive UNIX on 386) connected to my TNC.
I have been noticing on the kermit logs that U5MIR has been occasionally
present. Does anyone have software that can work unattended on UNIX
that I can use to "work" his BBS?

Thanks

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

Date: 13 Jun 91 13:34:29 GMT
From: [e-mail]
Subject: MBL SOFTWARE - NEWEST VER. ?
To: [e-mail]

I am using MBL 5.14 software at the BBS on 4Z4SV.
Can someone fill me in on what the latest version of this program is and
when it was written ?
Also - has anyone ever made a comparative chart on various BBS software ?
i.e. RLI, MBL, AIZ  etc. ? I'd be curious to see the pluses and minuses of
each of them.
73,
Rich

[e-mail]

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

Date: 13 Jun 91 13:47:04 GMT
From: sdd.hp.com!uakari.primate.wisc.edu!crdgw1![e-mail]
Subject: PK-88 birdie on 145.01
To: [e-mail]

In article <[e-mail]>, Gary.Box@f510 (Gary Box) writes:
>
>Yes Jerry! I too have noticed a birdie on 145.01 fron the PK88. I
>took the easy way out and switched operation to 145.05 which is used
>extensively here in Minnesota. Unfortunately, I don't have any
>suggestions for you at this time, but if you come up with anything
>i'd appreciate it if you'd pass it on.
>Gary [e-mail]

My PK88 doesn't have the problem, but the standard fix is to twiddle with
the trimmer cap on the crystal inside the TNC.  That will move the birdie
to another frequency.

-don perley - ke2tp
[e-mail]

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

Date: 13 Jun 91 17:40:59 GMT
From: uswnvg![e-mail]
Subject: PK232 Mods
To: [e-mail]

I have a PK232, and I'm just starting to get into packet in a big
way, with the KA9Q stuff.  I understand that there are a number of
mods that can be made to the PK232 to make it more reliable, etc.

Are these mods archived (uucp, I don't have ftp right now) somewhere, or
can someone send 'em to me?

Thanks!
--
Clay Jackson - N7QNM
US WEST NewVector Group, Inc
[e-mail] | ...uunet!uswnvg!cjackso

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

Date: 13 Jun 91 13:33:04 GMT
From: uupsi!uhasun!arrlhq![e-mail]
Subject: The 'hidden transmitter' problem.
To: [e-mail]

In rec.radio.amateur.packet, [e-mail] (Brian Kantor) writes:
>Yes, a "full duplex' (i.e., real-time) repeater will allow stations
>within its service range to avoid hidden terminal, thus nearly
>completely avoiding collisions, so you can run maxframe back up to 7.
>Also, if the carrier can be kept on between transmissions, you can
>completely avoid squelch opening delays, so you can cut 'way down on
>TXD and speed up the whole channel.

Do you mean to keep the transmitter on continuously even in the absence
of input?  Or if not, isn't there still a squelch-delay problem at the
beginning of a sequence of transmissions?

>If the repeater is built using a K9NG modem as an FSK regenerator
>in the repeat path going from repeater receiver demodulator to its
>transmitter modulator, voice won't pass through the repeater without
>extreme distortion, so it won't get taken over by the local old farts,
>but it will pass BOTH 1200 AFSK and 9600 bps FSK, so it can be shared
>between the two groups.

Interesting.  I don't quite see how that works, but as I'm in the
process of putting together a 440-MHz regenerative repeater, I'd
be interested in the details.  Why isn't the 1200-baud AFSK also
distorted?

>My hope would be to place repeaters like this in each community, and
>then link them together on some other band using some intelligent
>routing scheme.  A person would connect to the repeater's node for all
>his network services, and with one in each community, few people would
>ever be out of range.
>
>I think it's a good way to go.

So do I.  Although I appreciate (and encourage) the Hubmaster idea,
I think there will always be a place for omnidirectional systems.
At a minimum, they are needed to serve the portable/mobile station.
And for the present, they are the easiest and most effective answer
to making a large improvement in network throughput.
-----
Jon Bloom, KE3Z                     |  [e-mail]
American Radio Relay League         |  uhasun!arrlhq!jbloom
225 Main St.                        |
Newington, CT  06111                |  "This mind intentionally left blank."

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

Date: 13 Jun 91 15:50:46 GMT
From: sdd.hp.com!uakari.primate.wisc.edu!caen!sol.ctr.columbia.edu!cunixf.cc.columbia.edu!cunixb.cc.columbia.edu![e-mail]
To: [e-mail]

References <[e-mail]>, <[e-mail]>, <[e-mail]>
Reply-To : [e-mail] (Meir)
Subject : Re: The 'hidden transmitter' problem.

In article <[e-mail]> [e-mail] (Gary Coffman) writes:
>>      I ask these questions because there has been some suggestions locally
>>that duplex repeaters are the way to avoid the hazards of NET/ROM or TheNet
>>or whatever is used at the network level.  Also, these have been suggested as
>>a "better" way to utilize the duplex channels than are voice repeaters.  I
>>really don't know if that's true or not, but all of the voice pairs are
>>taken on the Front Range.  Wouldn't it be smarter to have nodes
>>ingest the slow data and be linked on a different band zipping along at some
>>significantly higher rate, like 56k bps?  Or is there something I'm missing
>>here?
>
>56 kb is a natural for backbones and, as your users put more sophisticated
>demands on the network, it becomes very attractive for users as well.
>However, for the casual BBS user, or keyboard chatter, 1200 baud is often
>sufficient, and if more performance is needed, 9600 baud is often a cheap
>upgrade path. 56kb systems are often cheaper than 1200 baud systems if
>they must be purchased from scratch, but 1200 and 9600 baud systems can
>take advantage of radios already owned by the user and cost him a smaller
>*incremental cost*. A cost breakdown that I have done shows 56kb to cost
>around $550 while a ground up 1200 baud system costs around $650. But
>the existing radio of the 1200 baud user can bring his incremental cost
>down to $120. Going to 9600 baud only adds $99 to his incremental cost.
>
>Gary KE4ZV

What kind of 9600 bps system can one get for $120 + $99?  Are people using
any kind of data compression like on the newer 9600 bps telephone modems?

Where does the future of full featured packet networking lie?  Do you think
a modified TCP/IP system will take over?  I am interested in the following:
1) Text message store and forward to Amateurs and 3rd parties
2) Large file transfer capabilities
3) Internet mail connection
4) Internet access

What system is my best bet?  I really would prefer radio over telephone since
I want to help advance Amateur Radio, need frequent network access, and a
second telephone line is impractical.

* * * * * *  ====================== Meir Green
 * * * * * * ====================== (Internet) [e-mail]
* * * * * *  ====================== [e-mail]  [e-mail]
 * * * * * * ====================== (Amateur Radio) N2JPG

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

End of Packet-Radio Digest
******************************
Date: Sat, 15 Jun 91 04:30:02 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Junk
Subject: Packet-Radio Digest V91 #151
To: packet-radio


Packet-Radio Digest         Sat, 15 Jun 91       Volume 91 : Issue 151

Today's Topics:
            ** Inexpensive PK-64 Wanted **
            ftp PMP/Baycom wanted
               I aplogize to the net!!
                mods database
            NOS for Xenix anybody?
                Packet Cluster
                  PK232 Mods
          The 'hidden transmitter' problem.
                 Transverters

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

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

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

Date: 15 Jun 91 02:38:32 GMT
From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!mips!apple!portal!cup.portal.com![e-mail]
Subject: ** Inexpensive PK-64 Wanted **
To: [e-mail]

I have a Commodore 64 and would like to hook it up to my hf rig for
possible packet.  If possible, I'd like to try it on 2 meters as
well.  I've never seen packet; and I'm a grad student on a budget;
but if anyone has an old unwanted PK-64 with software, etc., I'd
like to buy it at a reasonable price.  Please email at the Internet
address below.  Thanks.
de WA4FJF
Randy Padawer
Internet email:  [e-mail]

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

Date: 14 Jun 91 12:47:12 GMT
From: sdd.hp.com!zaphod.mps.ohio-state.edu!rphroy!cfctech![e-mail]
Subject: ftp PMP/Baycom wanted
To: [e-mail]

In article <[e-mail]> [e-mail] (James Dorian Sandoz) writes:
>
>Can someone email me the site(s) for ftp'ing the PMP and Baycom apps?
>Also, are these just "drivers" ie can I use them "underneath" another
>app, say NOS on a pc?  Or are they stand-alone comm programs?  I'm
>looking for a cheap KISS modem, in effect, since NOS will do all of
>protocol bundling for tcp/ip.  So I don't need ax.25 or ROMS or much
>at all.
>
>73,  Jim N2MPT
>

 Me too, I have an old uds bell 202 modem just perfect for this, I have
the pc, I have the radio, I have the call, all I need is an ftp site
for the code

        73, Joel Lessenberry

    WB8RHG

 Joel Lessenberry, Distributed Systems | [phone]
 [e-mail]                     | Chrysler Financial Corp.
 [e-mail] | MIS, Technical Services
 {sharkey|mailrus}!cfctech!joel        | 2777 Franklin, Sfld, MI

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

Date: 12 Jun 91 22:58:07 GMT
From: nuchat!farwest![e-mail]
Subject: I aplogize to the net!!
To: [e-mail]

Hello Everyone!

    You may know me as the person that has won the 10th broken mailer
award! I am truly sorry for all the trouble that has been caused! I have
just been made aware of the problem that was being caused in this
newsgroup and have taken steps to correct the situation by stopping the
gatewaying of this newsgroup until a solution has been found. I have
notified the sysop of 106/88 that he is looping mail back through my
system. Until I receive a reply from him, his system is no longer allowed
to connect with mine. The reason that postmaster never received any mail
was due a bug in that gateway code. Now that I have switched to a fully
USENET-compatible BBS package, ALL OF THE POSTMASTER messages came
flooding in! I was appalled and ashamed at the mess that this one message
has caused! I truly apologize to the entire net for all the grief that my
system has caused. This was worse than keying the mike on a repeater
frequency and then going on vacation! I only hope that at least some of
you on the newsgroup can find it in your hearts to forgive me. Had I been
aware of the problem, I would have taken care of it immediately. If
anyone would like for me to apologize to them in person, please send mail
to [e-mail] and I will graciously apologize!

--
[e-mail] (Postmaster Account)
The Far West BBS -- [phone]

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

Date: 14 Jun 91 14:53:38 GMT
From: orca!javelin.sim.es.com!omega.sim.es.com![e-mail]
Subject: mods database
To: [e-mail]

Could someone point me in the direction of a node that has
the database of radio modifications available???

            Mike

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

Date: 14 Jun 91 12:07:28 GMT
From: amdcad!dgcad!dg-rtp!aquila![e-mail]
Subject: NOS for Xenix anybody?
To: [e-mail]

    Has anybody ported NOS to Xenix? I specifically have Xenix 2.2.3
    for a 286, but anything close would be great. If not, would the
    latest KA9Q NOS sources be my starting point, or is there a better
    reference port for UNIX systems available? I'm ignorant but interested
    on this  subject. Thanks for any help.

regards,
--

Mike Harris - KM4UL                      [e-mail]
Data General Corporation                 {world}!mcnc!rti!dg-rtp!harrism
Research Triangle Park, NC

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

Date: 14 Jun 91 22:51:00 GMT
From: [e-mail]
Subject: Packet Cluster
To: [e-mail]

Date sent:  14-JUN-1991 22:25:28

Hi!

I am trying to get a Packet Cluster going locally.
What I want is some basic info

1) What software is needed to run Packet-Cluster

2) Is the software available for different platforms,
   besides PC e.g. Amiga, C64, Mac etc.

3) I read somewhere that the Packet Cluster software uses its
   own protocol. If this is true, does it mean it will be
   incompatible with AX25 and TCPIP as the are at the moment.

I would be grateful for any hints/tips or pointers as to
where to get this info (magazine articles etc.)


John

______________________________
John Barry EI7DNB,
University of Limerick
Rep. of Ireland
[e-mail]

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

Date: 14 Jun 91 11:09:14 GMT
From: mcsun!ukc!warwick!covpoly!cch.cov.ac.uk![e-mail]
Subject: PK232 Mods
To: [e-mail]

Hello there,
I want to use a IBM compatible PC to run packet radio, Is there software
available to run a packet station using a PC interfaced to the transceiver
via a FSK modem chip. If so where can I get a copy of the software?
(Public domain or shareware would be preferable). The software will need to
handle all the packetising and depacketising and the protocols.
If there are any good reference books with the packet protocols contained
could you list them for me.

I can be emailed at [e-mail]-relay

Many thanks in advance.

Brevan Miles: G6VDU
Coventry Polytechnic Radio and Electronics Club (G0NCP)
Department of electrical and electronic engineering.

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

Date: 14 Jun 91 18:39:58 GMT
From: [e-mail]
Subject: The 'hidden transmitter' problem.
To: [e-mail]

In article <[e-mail]> [e-mail] (Jon Bloom) writes:
>Do you mean to keep the transmitter on continuously even in the absence
>of input?  Or if not, isn't there still a squelch-delay problem at the
>beginning of a sequence of transmissions?

The MITREK I'm using has a VERY quick response time; it gets on the air
in just a few milliseconds.  There is a delay, but not much.

On the other hand, the latest rules rewrite omitted the 5-second max
delayed dropout timer spec, so you could have the repeater DDO set up
around a minute or even longer - the first packet through would key it up
and might have to be retried, but all subsequent would work.  I'm
leaning towards real fast keyup and no DDO as the right way to go.

>Why isn't the 1200-baud AFSK also distorted?

It's just going to hard-limit the AFSK tones.  Since a lot of demodulators
do that anyway, no problem.  But it makes voice unpleasant enough people
don't want to talk through it.

Understand that 1200bps performance is secondary - my purpose is to
encourage 9600 bps operation, which is why the repeater's node is
only accessable at 9600.  The 1200 bps users still get some repeater
usage, which is a whole lot better than the nothing they had before.
    - Brian

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

Date: 14 Jun 91 13:11:50 GMT
From: [e-mail]
Subject: Transverters
To: [e-mail]


       Can anyone recommend a transverter for use on 440 or 2meters ? Many
manufacturers have stopped production. A phone and address would be greatly
appreciated.

       Cap

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

End of Packet-Radio Digest
******************************
Date: Sun, 16 Jun 91 04:30:02 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Junk
Subject: Packet-Radio Digest V91 #152
To: packet-radio


Packet-Radio Digest         Sun, 16 Jun 91       Volume 91 : Issue 152

Today's Topics:
            ftp PMP/Baycom wanted
          GRAPES - how do I get in contact?
               Help with TheNet TN11-I
             MBL SOFTWARE - NEWEST VER. ?
         Packet posts without your callsign (2 msgs)

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

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

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

Date: 15 Jun 91 13:27:14 GMT
From: swrinde!cs.utexas.edu!helios![e-mail]
Subject: ftp PMP/Baycom wanted
To: [e-mail]

The Baycom manual & code are available for anonymous ftp from
csseq.cs.tamu.edu.  Hopefully, I'll get the PMP stuff there today or
Monday.
Cheers,
 Willis n5szf

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

Date: 15 Jun 91 13:41:24 GMT
From: swrinde!mips!spool.mu.edu!munnari.oz.au!bunyip.cc.uq.oz.au!marlin.jcu.edu.au![e-mail]
Subject: GRAPES - how do I get in contact?
To: [e-mail]

Hi, I have a friend who wants me to post this message from him.
He has email access to the net, but cannot send or receive news.

===== MESSAGE STARTS =====

From: [e-mail] (Wayne Amisano,GBRMPA,0861,077818861)

ken here is the mail I got re the 56kb modems!

    From [e-mail] Fri Jun  7 10:05:43 1991
    Apparently-From: [e-mail]
    Message-Id: <[e-mail]>
    Date:        6 Jun 91 20:04:00 EDT
    To: [e-mail]
    From: Marcus (M.D.) Leech <[e-mail]>
    Subject:    56 kb packet hardware
    Sender: Marcus (M.D.) Leech <[e-mail]>

    We're not selling 56kb RF modems, the GRAPES boys are doing that.

    What we *are* selling is a high-speed -low-cost interface for the PC
      that connects to these modems.

    For more info on our interface board, contact:
    [e-mail]

    An e-mail address for GRAPES can be had by posting a query to
      rec.radio.amateur.packet.

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

could you post saying:

hi,

I rxed an e-mail msg de [e-mail] advising me to post to
this net to ask fer an e-mail address for GRAPES to find out info
about their 56kb packet modems

 I would appreaciate any feedback you could possibly give.

 Wayne Amisano                    TARC Inc.
 [e-mail]              P.O. Box 964
 VK4JCU@VK4AFS.#NQ.QLD.AUS.OC     Townsville, QLD, 4810
                  AUSTRALIA

===== MESSAGE ENDS =====

Please email all replies to [e-mail] or [e-mail]
(both go to the same person).

Thanks for your help.

Ken Dwyer.

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

Date: 15 Jun 91 22:24:05 GMT
From: [e-mail]
Subject: Help with TheNet TN11-I
To: [e-mail]

Does anyone have the documentation and programming software (or programming
instructions) for TheNet TN-11-I?  This is the limited access backbone
version that allows no level 2 connects except for the Node callsign holder
and 4 other users.   Any help in obtaining same would be appreciated.

Mark Bitterlich
[e-mail]
[e-mail]

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

Date: 15 Jun 91 16:15:08 GMT
From: swrinde!zaphod.mps.ohio-state.edu!rpi!uupsi!netfs.dnd.ca!dgbt![e-mail]
Subject: MBL SOFTWARE - NEWEST VER. ?
To: [e-mail]



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

Date: 15 Jun 91 22:37:01 GMT
From: swrinde!zaphod.mps.ohio-state.edu!think.com!yale.edu!ox.com!umich!sharkey!nstar!towers![e-mail]
Subject: Packet posts without your callsign
To: [e-mail]

Hi there, I run a Fidnet BBS in Indiana (231/30) and have been grabbing the
solar warnings off usenet and cross posting them in the HAM echo.  A couple of
weeks ago I got a call from a friend and he wanted to know when I got my
packet gear set up. (I have no access to packet at this time)  I was pretty
puzzled over this as I have never been on a packet system before.  He said he
saw a message from me addressed to ALL@USA regarding the solar flare warnings.
I asked he to capture it for me and after I looked at it. it was clear that
someone had taken the Fidonet post and posted it on a packet system in Abilene
Texas.  The system was the NG5QH system but no where in the path and message
header information was there an indentifying line to show who had actually
posted the message.  The from line showed : >KB9BVN@NG5QH

I started inquirying in the echo about this and N5PCA admitted that he had
posted it but had violated no rules by doing so, he claims that he was logged
in to the packet system with his own callsign....but the thing that bothers me
is that now I am getting netmail asking why I do not respond to messages
people are leaving me on packet. (GREAT)

Also a friend of mine K9ML checked the white pages on packet to see if I was
listed there and sure enough, it shows my home BBS as being the NG5QH system
in Texas.  (I live in Indiana).

Is this all legal?? If so, then packet radio has a VERY LARGE HOLE in it.
What is to keep someone from logging on under their call sign, and posting
using another callsign.  If the message content was illegal then the FCC is
going to come after the BBS op and more than likely the callsign indicated in
the FROM line.  If the BBSOP doesn't have his logs to prove who posted the
message than an innocent person could get into some real shit with the FCC.

N5PCA and a few others keep telling me that they didn't violate any rules, I
disagree with them, but since I do not use packet yet I am not 100% up to
snuff on the rules.  I know that on my landline BBS that I am legally
responsible for the posts and information contained therein, if an imposter
posts something illegal I'm up the creek (I voice validate everyone and use
some other security measures) without a paddle.

So what's the deal?



--
=======================================================================
: Brian Murrey - KB9BVN - QTH Indpls : Fidonet: 1:231/30 317-535-9097 :
: UUCP:..towers!brian                : Login:Ham Radio  Password:Yagi :
=======================================================================

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

Date: 16 Jun 91 06:17:23 GMT
From: swrinde!zaphod.mps.ohio-state.edu!maverick.ksu.ksu.edu!ux1.cso.uiuc.edu![e-mail]
Subject: Packet posts without your callsign
To: [e-mail]

[e-mail] (Brian Murrey) writes:

>N5PCA and a few others keep telling me that they didn't violate any rules, I
>disagree with them, but since I do not use packet yet I am not 100% up to
>snuff on the rules.  I know that on my landline BBS that I am legally
>responsible for the posts and information contained therein, if an imposter
>posts something illegal I'm up the creek (I voice validate everyone and use
>some other security measures) without a paddle.

There may well be a rule being violated here.  If the packet posting
appears to be from you, and you did not send it (as opposed to being
originally from you which is not true either since you are getting it
from usenet) then the violation is something called "FRAUD".  But
whether this case is such a violation is conditional.  Being "From:"
you is technical correct from a perspective of where N5PCA got it.
Who it is from and who posted it are two different things.

The problem is that the identify of WHO POSTED IT as opposed to who
wrote it, etc (which is not you anyway) is not appearing in the packet
posting.

I, like you, and not yet active on packet.  Given the mess it sounds like
I'm not so sure I want to be.

What you might do is a little editing when you crossfeed the postings
into the Fido HAM echo.  Add a few lines at the top identifying yourself,
where you got the posting, and a statement saying something like:
"This material may be copied provided that full identification of
the person making the copy be provided with the copy".
--
 /***************************************************************************\
/ Phil Howard -- KA9WGN -- [e-mail]   |  Guns don't aim guns at  \
\ Lietuva laisva -- Brivu Latviju -- Eesti vabaks  |  people; CRIMINALS do!!  /
 \***************************************************************************/

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

Date: (null)
From: (null)
The latest version is (and always will be, it seems) 5.14C, and it came out
in February 1990.

> Also - has anyone ever made a comparative chart on various BBS software ?
> i.e. RLI, MBL, AIZ  etc. ? I'd be curious to see the pluses and minuses of
> each of them.

Not to my knowledge.  It would be a daunting task, since there are at least
a dozen PBBS programs around, and some aren't very well documented.  It
would be interesting to see though...

Barry VE3JF (*still* running MBL after all these years :-))))
--
Barry McLarnon                  |  Internet: [e-mail]
Communications Research Centre  |  PBBS: [e-mail]
Ottawa, Canada  K2H 8S2         |  AMPRnet: [e-mail]

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

End of Packet-Radio Digest
******************************
Date: Mon, 17 Jun 91 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Junk
Subject: Packet-Radio Digest V91 #153
To: packet-radio


Packet-Radio Digest         Mon, 17 Jun 91       Volume 91 : Issue 153

Today's Topics:
              ATV - High Speed Digital ?
            Looking for 64kbps pt-pt link
                Packet Cluster
            PK-64 INFO NEEDED; PK-64 !!!!
          The 'hidden transmitter' problem.
          WIRELESS: Weekly digest available

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

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

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

Date: 16 Jun 91 20:09:40 GMT
From: swrinde!sdd.hp.com!hp-col!winfree![e-mail]
Subject: ATV - High Speed Digital ?
To: [e-mail]

[e-mail] (Mark Zenier) writes:
> Has anyone tried to use ATV equipment to send high speed
> digital information, along the lines of the "back up
> your computer disk on your VCR", by making a modem that
> outputs something that looks like a standard TV signal?

Yes, sort of.  Some folks in Japan were experimenting with ATV tx and rx gear
lashed up to a 10Ghz link built around a pair of Gunn units and lots of
plumbing about two years ago.  I don't know how far they got, they were trying
to do 10Mbit/sec, and the ATV-derived modulators weren't that fast.

Bdale

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

Date: 16 Jun 91 15:36:33 GMT
From: swrinde!cs.utexas.edu!asuvax!anasaz!qip![e-mail]
Subject: Looking for 64kbps pt-pt link
To: [e-mail]

We are interested in setting up some point to point links running
64kbps (for digitized audio). Does anyone know what is available for
this?

If we could get wide-band radio equip (don't have time to learn and
build GHz range equip), the rest could be done. Alternatively,
high bit rate modems over narrow band would be okay. Has anyone
done work on high bit rate modems using techniques that assume a
very good SNR?

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

Date: 16 Jun 91 21:21:58 GMT
From: usc!apple![e-mail]
Subject: Packet Cluster
To: [e-mail]

Well, since no one else has taken a crack at answering this yet, I'll
throw in what I know.

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

>1) What software is needed to run Packet-Cluster

Software of the same name from Pavilion Software. Since I'm not a sysop,
I haven't paid attention to their address, the cost of the package, etc.
Perhaps someone else out there can supply you with the necessary details.


>2) Is the software available for different platforms,
>   besides PC e.g. Amiga, C64, Mac etc.

I'm sure that the BBS software itself is only available for MS-DOS
machines, so sysops would need that. Users, however, can use any
normal packet-radio software. (I use the KA9Q package on my Macintosh,
for instance.)

I believe there's also a special user program called "Cluster Companion"
available for MS-DOS machines that gives you a few additional features.
But it's entirely optional. Regular packet programs work just fine.


>3) I read somewhere that the Packet Cluster software uses its
>   own protocol. If this is true, does it mean it will be
>   incompatible with AX25 and TCPIP as the are at the moment.

You've been told incorrectly. It's regular AX.25.


>I would be grateful for any hints/tips or pointers as to
>where to get this info (magazine articles etc.)

I know the DX Magazine has done stories on it, and I think Gateway
(now incorporated into QEX, both from the ARRL) has also.


Patty
(Now officially a dual U.S./Irish citizen! Wave hi to County Limerick
for me, John!)

--
===============================================================================
Patty Winter N6BIS                      What do they got? A lot of sand!
INTERNET: [e-mail]              We got a hot crustacean band!
UUCP: {decwrl,nsc,sun}!apple!winter     We got no troubles, life is de bubbles
AMPR.ORG: [44.4.0.44]                   Under the sea.
===============================================================================

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

Date: 17 Jun 91 02:00:38 GMT
From: sdd.hp.com!mips!apple!portal!cup.portal.com![e-mail]
Subject: PK-64 INFO NEEDED; PK-64 !!!!
To: [e-mail]

Who here has used the PK-64 with a Commodore 64 on packet???
I'm interested in knowing if this is something worthwhile.  I've
never been on packet before.  Any information would be appreciated.
Randy Padawer, WA4FJF
[e-mail]

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

Date: 16 Jun 91 20:04:16 GMT
From: sdd.hp.com!hp-col!winfree![e-mail]
Subject: The 'hidden transmitter' problem.
To: [e-mail]

[e-mail] (Gary Coffman) writes:
> The system is even better if you operate cross-band full duplex. No
> duplexers are required so even the home user can run full duplex. Then
> true collision detection as well as collision avoidance can be practiced.

Very much agreed, but how do you convince users to deal with two antennas, and
two feedlines, and so forth?  I'm finding this enough of a roadblock that we
are seriously considering going inband for our 56kb repeater, and punting the
/CD entirely...

Bdale, N3EUA
(gosh, seems like ages since I've had time to get caught up here... will be
 around a little more regularly from now on...)

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

Date: 17 Jun 91 01:05:13 GMT
From: pacbell.com!tandem![e-mail]
Subject: WIRELESS: Weekly digest available
To: [e-mail]

The WIRELESS mailing list is for techical discussion on all aspects of
wireless LANs such as...

    Propagation
    Media access and control
    RF technology
    Specialized protocols
    .....



==============================================================================
Weekly digest for WIRELESS mailing list

Week ENDING June 15, 1991

This digest (or back issues) can be obtained by anonymous FTP to tandem.com
from the wireless directory.

The file wireless/wireless explains the purpose of the mailing list and
describes how to subscribe and post.

To subscribe to the mailing list, send a mail message to
'[e-mail]' with the following line in the body:

    add <your e-mail address> wireless

for example:

    add [e-mail] wireless

The e-mail address *must* be fully qualified with the full domain name.

The WIRELESS mailing list is moderated by Stuart Phillips and Kevin Rowett.
==============================================================================

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

End of Packet-Radio Digest
******************************
Date: Tue, 18 Jun 91 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Junk
Subject: Packet-Radio Digest V91 #154
To: packet-radio


Packet-Radio Digest         Tue, 18 Jun 91       Volume 91 : Issue 154

Today's Topics:
     Anyone else looked into porting KA9Q's TCP/IP stuff
            Deep cycle batteries (2 msgs)
            ftp PMP/Baycom wanted
          Kantronics KPC2 question (2 msgs)
             Online packet maps?
               PK-87 man needed
          The 'hidden transmitter' problem.
            The Case for a Network
               Unix Packet Help Needed
             Value of Ham Radio?
           Value of Ham Radio while biking?

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

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

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

Date: 17 Jun 91 22:37:05 GMT
From: intran![e-mail]
Subject: Anyone else looked into porting KA9Q's TCP/IP stuff
To: [e-mail]

I have been working on porting the KA9Q TCP/IP networking stuff to Coherent.

I was wondering if anyone else has succeeded, and/or what Makefile should I
start with.

I have *most* of it compiling, but none of it working (yea, I know!!??)

I am running into weird problems, and bizzarre crashing.  I am trying to
talk to a DOS system running the same code (well the dos version of the
same code TCP/IP Plug and Play version).

I am almost stuck, but not giving up.  Any hints would be appreciated.

Thanks

Tom Brusehaver

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

Date: 18 Jun 91 05:03:50 GMT
From: vi.ri.cmu.edu![e-mail]
Subject: Deep cycle batteries
To: [e-mail]

Car starting batteries are designed to provide a large current
(hundreds of amps) for a few seconds, and then be recharged fully. They
are optimized for very low series resistance, not for long discharge periods.

Deep cycle batteries are designed to provide a steady current for hours.
Pound for pound, a deep cycle battery will provide a lot more usable
amp-hours than a starting battery of the same size. The "9 volt" number
quoted on the net refers to the fact that deep cycle batteries can take
more abuse than starting batteries and still perform. The amp-hour rating
assumes a load that will discharge the battery in 20 hours, with discharge
being defined as the loaded voltage dropping to 10.5 volts.

Deep cycle batteries come in two flavors. Liquid electrolyte batteries,
including "maintenance free", must be charged by a complex cycle if their
full amp-hour potential is to be realized. This cycle includes charging
at 13.8 volts, with a brief overcharge period of 14.4 volts. The deliberate
overcharging produces gas generation which helps to clear the plates of
sulfate crystals.

A more expensive type of deep cycle battery is the immobilized electrolyte, or
"gell cell" type. This type has the following advantages:

    1) Easier charging. A constant voltage charge at 13.8 volts
       will charge a gell cell to its full amp-hour capacity.

    2) Protection from abuse. A gell cell stands up to abuse better
       than a liquid electrolyte battery (see below).

    2) Operation in any position. Gell cells can be operated in any
       position, including upside-down. People like me who sail small
       boats appreciate this property.

There are 2 things that can kill any lead acid battery. The first is
to let the liquid in a non-sealed battery drop below the tops of the plates.
The second is to discharge the battery below 10.5 volts and leave it that
way. Gell cells are a little more immune, but should be recharged within
a month of use.

Source:         "Living on 12 Volts with Ample Power"
         David Smead & Ruth Ishihara
         International Marine Publishing Company

    This book is an excellent reference on the properties of lead
    acid batteries and alternate energy systems. It is written
    by and for cruising sailors, who need to get every amp-hour per
    pound out of their batteries. The author has done extensive testing
    of different types of batteries.

-  Bob   N3EMO
[e-mail]
N3EMO @ KA3JSD.PA

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

Date: 18 Jun 91 06:01:36 GMT
From: epic![e-mail]
Subject: Deep cycle batteries
To: [e-mail]

In article <[e-mail]>, [e-mail] (Bob Berger) writes:
|> A more expensive type of deep cycle battery is the immobilized electrolyte, or
|> "gell cell" type. This type has the following advantages:

One thing that will definitely kill a Gel Cell is overcharging, since
you can't add water. If you boil it off, you ruin the cell.

Phil

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

Date: 17 Jun 91 17:50:13 GMT
From: news-server.csri.toronto.edu!utgpu!utzoo!mnetor!ghp![e-mail]
Subject: ftp PMP/Baycom wanted
To: [e-mail]

Joel Lessenberry writes:
> James Dorian Sandoz writes:

>>Can someone email me the site(s) for ftp'ing the PMP and Baycom apps?

> Me too, I have an old uds bell 202 modem just perfect for this, I have
>the pc, I have the radio, I have the call, all I need is an ftp site
>for the code

Ditto, I tried many times using the mail servers to get the code,
but no luck.  It looked like something was working, but I never got
the code.  I was going to try one or two more experiments, but then
I saw other people with the same trouble.

I hope I haven't been overflowing somebodies bit-bucket in where-ever-land :-)

tnx, 73/jim
--
Jim Stewart, VE3SRJ
UUCP:  [e-mail]
BELL:  [phone]

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

Date: 17 Jun 91 20:48:45 GMT
From: vi.ri.cmu.edu![e-mail]
Subject: Kantronics KPC2 question
To: [e-mail]

Does the KPC2 have the hardware time-out timer needed for unattended operation?

I like the kantronics stuff, and realize a timer would be easy to add, but
it's even easier to spend $30 less for a TNC2 clone if Kantronics is still
too cheap to build in a timer.

-Bob,  N3EMO

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

Date: 18 Jun 91 01:02:11 GMT
From: pacbell.com!mips!samsung!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!cbfsb!cbnewsb.cb.att.com![e-mail]
Subject: Kantronics KPC2 question
To: [e-mail]

In article <[e-mail]>, [e-mail] (Bob Berger) writes:
>
>Does the KPC2 have hardware time-out timer needed for unattended operation?

I have a KPC2 and I can say from experience that it doesn't have a hardware
timer.  I once came home to find the TNC in a wierd state, continuously
making the radio transmit a single tone  "beeeeeeeeeeeeeeeeeeeeeeeeep".
The radio took it no problem, but I'm sure that the other users of the freq
in my area were less than thrilled with this tone jamming the channel.
Only happened once in a year's time.

73 de WA2ISE
If I had authority to speak for my company, I wouldn't have time to read
newsgroups anyway!

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

Date: 17 Jun 91 08:41:47 GMT
From: vi.ri.cmu.edu![e-mail]
Subject: Online packet maps?
To: [e-mail]

Are there any packet maps/pbbs lists available online?

A friend of mine will be driving across the country this summer and
we would like to stay in touch via packet. Getting messages back here to
Pittsburgh is the easy part; he can log into PBBS's along the way and send
the mail.

The problem is getting messages to him. With 2 drivers they plan to be
driving most of the time, and I will need to predict what PBBS's he will be
at in advance.

Robert Berger, N3EMO
[e-mail]

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

Date: 17 Jun 91 19:03:40 GMT
From: europa.asd.contel.com!wlbr!lonex.radc.af.mil![e-mail]
Subject: PK-87 man needed
To: [e-mail]

I need the manual for a PK-87 TNC.  I picked one up at a hamfest and it didn't
have a manual.  Especially needed is the command list so I can use the darn thing.
I was told it would be "just like my MFJ" but found out otherwise when I got home.

Thanks
Buzz [e-mail]
[e-mail]

(Box 74a RFD#2, Boonville, NY 13309...315-942-2799)

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

Date: 17 Jun 91 18:53:49 GMT
From: epic![e-mail]
Subject: The 'hidden transmitter' problem.
To: [e-mail]

In article <[e-mail]>, [e-mail] (Bdale Garbee) writes:
|> Very much agreed, but how do you convince users to deal with two antennas, and
|> two feedlines, and so forth?  I'm finding this enough of a roadblock that we
|> are seriously considering going inband for our 56kb repeater, and punting the
|> /CD entirely...

There are quite a few multi-band antennas on the market, and you can get
crossband splitters to go with them. You still need two radios (unless you
use one of the newer duplex dual-band radios) but at least they can
share one feedline and one antenna.

Phil

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

Date: 18 Jun 91 05:39:09 GMT
From: epic.bellcore.com![e-mail]
Subject: The Case for a Network
To: [e-mail]

Rumor has it that the "powers that be" in the FCC are uncomfortable
with what they perceive as the building of a "common carrier" network
on the ham bands -- in the form of the packet BBS system (and other
related packet systems).

Indeed, the situation is starting to look very much like that of about
20 years ago, when one A. Prose Walker, W4BW, decided he did not like
FM repeaters and pushed through highly restrictive rules. For those of
you who were not around, these rules required the special licensing of
repeaters (with WR callsigns). Ordinary stations were not allowed to
do anything that looked like repeating.  Applications for repeater
licenses required highly detailed system diagrams, with designated
"control points", designated control operators (who had to hold
special "control" licenses) and the like. The linking of repeaters was
prohibited, as was crossband operation and a whole slew of other
potentially useful activities.

After a few years Mr. Walker retired from the FCC and the draconian
rules were lifted, but not until after quite a bit of damage had been
done.

Now we seem to face a replay of history with respect to today's
leading-edge amateur technology, packet networking. We've seen the
opening shot in the form of the infamous "900 number" citation and the
FCC's apparent intransigence on holding every licensee in an automatic
network responsible for message content.

I thought it might be useful to draft a "white paper" to argue the
case for a highly capable amateur packet radio network, because the
FCC Private Radio Bureau appears unable or unwilling to appreciate the
fact that packet networking is just as much (or more) in keeping with
the Basis and Purpose of the Amateur Service as are more traditional
activities such as ragchewing, DXing, contesting, building
transmitters, etc. To me, building the biggest, fastest and most
reliable and efficient packet network we can is amateur radio's
"manifest destiny".  It's so obviously the right thing to do that it's
hard to exhaustively list all the reasons why.  One might as well try
listing all the arguments in favor of motherhood and apple pie.

Therefore I would like to solicit items for this white paper. At the
moment, I am looking for BRIEF points that I can expand into full
sections in my paper. All should support these two basic ideas: 1)
building an amateur packet radio network is entirely consistent with
the charter of the Amateur Service, and 2) even a fully automatic,
operational amateur packet radio network would not be a "common
carrier" by the standard meaning of the term.

To get things started, I thought I'd put out a few points myself.

1. The "leading edge" of radio communications technology no longer
deals entirely with the design of radio transceivers. It now deals
instead mainly with the problems of organizing those transceivers into
cooperating networks. If amateur radio is to stay current with the
field of radio communications and produce technicians and engineers
who understand today's communications systems, it too must do
networking.

2. A "common carrier" is defined as a commercial entity that must
provide its communications or transportation services to anyone
willing to pay its tariffed rates.  Since amateurs are a) volunteers
who are free not to provide their services and b) cannot by law accept
compensation, it is impossible for amateurs to create a "common
carrier" network even if the amateur technology were otherwise
identical with that used by common carriers.

3. By replacing a single pair of stations with a network of several
stations between the same two points (among others), it becomes
physically possible to use higher frequencies (e.g., line of sight
links using VHF, UHF or microwave instead of ionospheric routes
requiring HF) and lower powers (because of the smaller inter-station
separations and higher antenna gains). This promotes the more
efficient and effective use of RF spectrum, particularly through
spatial reuse. Given the scarcity of the spectrum and the amateur's
mandate to experiment, the development of amateur networks as a means
of promoting more efficient use of the spectrum is clearly justified.

4. Automatic networks, particularly operating on line-of-sight paths
at VHF and above, are much more reliable than point-to-point HF links,
making amateur facilities much more useful in event of emergency.

5. The network itself has proven extremely useful in support of other,
more traditional amateur activities by disseminating bulletins,
coordinating the efforts of like-minded amateurs at some distance from
each other, and promoting the broader discussion of policy topics of
interest to amateurs.

Those are just a few of the possible points I could make. Any others?


Phil

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

Date: 13 Jun 91 07:26:31 GMT
From: usc!samsung!emory!wa4mei!ke4zv![e-mail]
Subject: Unix Packet Help Needed
To: [e-mail]

In article <[e-mail]> [e-mail] writes:
>
>       I have several goals:
>
>               1) Use simple, inexpensive, TNC if possible.

The cheapest TNC on the market has a list price of $129. The best TNC on
the market has a list price of $129. You can't lose.

>               2) Use outboard TNC if possible.

Sure, no device drivers to write. Let the little Z80 do the hard work.

>               3) Use PC for processing horsepower.

Not much processing left to do, the Z80 did all the work. All you have
to contend with is a ASCII stream coming in the serial port.

>               4) Use XENIX for the operating environment. I use
>                  XENIX the most and the packet software could be
>                  monitoring the port full time while I did other
>                  work.

Again sure, Unix likes to deal with streams of bytes.

>               a) XENIX would mandate code that  was written in C or
>                  assembler but that used standard i/o functions
>                  (although I suppose I could write a device driver).
>                  Sources would probably need to be available.

You could just use cu -l tty00. Should work as good as any dumb terminal.
No programming required.

>               5) Have the PC be a "private node" or "BBS" so that
>                  messages were delivered to my PC instead of having
>                  to connect as a terminal to read them. I'm not sure
>                  if my terminology is quite correct here.

Ah, you want a personal mailbox. This feature is already available in the
current release TNC code. Again you can let the Z80 do the work. The TNC
can hold up to about 10k of mail before overflowing.

>                  If I can run the software under XENIX then I can
>                  leave the machine up in the same environment full time
>                  so message delivery won't be a problem.
>
>               6) To minimize system loading, it would be nice if the
>                  TNC could be configured to pass only traffic for
>                  me. I would appreciate knowing how this affects the
>                  price class of the TNC.

As long as you leave monitor mode turned off in your TNC this is automatic.
No extra charge.

>       So, Is this possible? How much of it is? Thanks very much for
>       your help. I hope to be making a racket with packet soon!

What you want to do requires no programming and is built in to the
cheapest TNC on the market. By enabling KISS mode in the TNC and
running the KA9Q TCP/IP code for Unix, you can do much more advanced
things. But save that for later. Just hook up a regular TNC and use
cu to talk to it until you get a better feel for packet.

Gary KE4ZV

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

Date: 17 Jun 91 14:52:04 GMT
From: sdd.hp.com!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!src.honeywell.com!msi.umn.edu!cs.umn.edu!uc!noc.MR.NET!news.stolaf.edu!agnes.acc.stolaf.edu![e-mail]
Subject: Value of Ham Radio?
To: [e-mail]

Hello!

I am interested in getting my Ham Radio liscense, however, before I do so,
I need to know if it would be worth getting before I take a long trip to
the Southwest or after I do.  What is the Ham "population density" in the
southwest and Mexico?  I will be travelling by bike so most likely I will
only be able to operate a 2 meter rig.  (Unless there are other _really_
portable units available for 10 meters &c.  Are there?)  I would like to get
my liscense before I go if I can be assured that it would be worth it and
that I won't be hauling around extra pounds of gear with no one to talk to.

How about repeaters in the southwest?  Are there many?  One of the reasons
I would like to have a 2m rig because then I can communicate via packet
radio with a computer at home.  (I will have a notebook computer with me.)  Is this possible?  How about Internet access while I'm on the road?

What kind of problems (if any) pop up when travelling across the border
into mexico?  Do I need to prearrange something?

One of the greatest need that a radio would fulfil is communication.
(Obvious, no?)  I will be on the road with a friend for about 9 months.
During this time I'd hate to have a problem like a broken leg and have to
_ride_ 60 miles to find a desert pay phone.  Another reason is because it
would be really nice to have "contacts" on the way.

However, if the population of hams is faily low, I think that I will wait
until sometime after the trip to make the expenditure.

Jonathan Bucki
St. Olaf College


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

Date: 17 Jun 91 18:36:20 GMT
From: ucselx!sol.ctr.columbia.edu!src.honeywell.com!msi.umn.edu!noc.MR.NET!news.stolaf.edu!thor.acc.stolaf.edu![e-mail]
Subject: Value of Ham Radio while biking?
To: [e-mail]

Greetings,

I'm interested in getting my amateur radio license.  I'm going to be taking
a year off from college and riding my bicycle in the southwestern U.S. and
Mexico.  I'm interested in taking a radio with me for many reasons.  First
of all it would be a good safety measure.  Secondly I have always wanted to
get a license.  Thirdly it would be nice to have local contacts in the
areas I want to visit to direct me to places to see, things to do &c.
Fourthly, riding bike for 8-10 hours a day often gets monotonous in
deserts, plain states &c.  And number five is because I would like to
maintain my connection to the Internet if possible so that I can relay some
of my projects that I'm working on without having to use phone lines.
(We will be carrying a notebook computer.)

I have several questions that I have to address.  First of all, are there
many hams in that area?  How about repeaters and gateways?  Can I rely on a
good two meter setup, or should I look for something else?  How portable
can I be?  Has anyone else done this?  How do I mount an antenna on a bike
with some degree of stability?  What about crossing into Mexico and other
south american countries?  What type of arrangements must be made?  Can I
somehow go solar powered without much modification to equipment?


If you have answers to these questions or have something that I might use,
PLEASE drop me a line.  Thanks much.


Jonathan Bucki
St. Olaf College



P.S.  If anyone living west of the Mississippi and north of Panama has any
available back yard space for two, poor college students on bikes, drop me a
line.  We do windows!

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

End of Packet-Radio Digest
******************************
Date: Wed, 19 Jun 91 04:30:06 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Junk
Subject: Packet-Radio Digest V91 #155
To: packet-radio


Packet-Radio Digest         Wed, 19 Jun 91       Volume 91 : Issue 155

Today's Topics:
              "The White Pages "
             9600 BPS FAX modem on packet
                 CDMA
                  CDMA info
             Deep cycle batteries
           Field Day vhf packet info needed
          Kantronics KPC2 question (3 msgs)
    NOS->Real OS (Was: memory problems with nos_0531.exe)
           Paccom PSK1, Heath HK232 and PG program
                Packet Cluster
         Packet posts without your callsign (2 msgs)
               Received R95.EXE

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

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

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

Date: 18 Jun 91 13:36:34 GMT
From: [e-mail]
Subject: "The White Pages "
To: [e-mail]

I believe there was a rather long list of all known Amateurs on packet
along with their home BBS's called the "White Pages".
Is this file available somewhere via the Internet ?
Any info on the subject would be greatly appreciated.
- Richard Harel
My E-Mail address is:

[e-mail]

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

Date: 15 Aug 90 15:18:29 GMT
From: [e-mail] (Jim Grubs)
Subject: 9600 BPS FAX modem on packet
 * Forwarded from "PACKET - 13"
 * Originally from Jeff King
 * Originally dated 08-12-90 22:25

 @MSGID: 1:120/216 150cb329


         9600 BAUD (BPS) FAX TEST RESULTS


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

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


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


RADIO EQUIPMENT:


WA8OOH                                    WB8WKA
Livonia MI                                Farmington MI

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

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

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

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


THROUGHPUT:

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

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

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


GENERAL IMPRESSIONS:

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

IMPROVEMENTS:

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

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


THOUGHTS:

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

WHATS NEXT:

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

Jeff King WB8WKA
22816 Maple Ave
Farmington, MI 48336.

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

BETA TEST:

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



73's

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

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

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

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

Date: 18 Jun 91 17:59:59 GMT
From: pacbell.com!mips!zaphod.mps.ohio-state.edu!think.com!bbn.com!ulowell!plover.ULowell.EDU![e-mail]
Subject: CDMA
To: [e-mail]

I am looking for pointers to an elementary description of how
CDMA works in practice;  I have seen simple example descriptions,
I have no idea, for example how many chips/bit occur in practice,
whate actual bandwidth is in the real world.

TNX,
    ...Wex

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

Date: 19 Jun 91 05:22:27 GMT
From: walter!gizmo![e-mail]
Subject: CDMA info
To: [e-mail]

(chomp chomp)

a good start is...

Dixon, Spread Spectrum Communications, 2nd Edition.

good stuff.

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

Date: 19 Jun 91 03:48:18 GMT
From: vi.ri.cmu.edu![e-mail]
Subject: Deep cycle batteries
To: [e-mail]

In article <[e-mail]>, [e-mail] (Phil R. Karn) writes:
> In article <[e-mail]>, [e-mail] (Bob Berger) writes:

> One thing that will definitely kill a Gel Cell is overcharging, since
> you can't add water. If you boil it off, you ruin the cell.

That may be true, but the ease of charging of gell cells makes it somewhat
irrelevant. Gell cells can be charged to 100% of their capacity by connecting
to them a constant 13.8 volts, and can be left floated at that voltage
indefinitely without damage.

So, as long as you don't exceed 13.8 volts, you will do no damage.

I charge small gell cells using an LM317 voltage regulator chip set to 13.8 V.
They can also be floated across an existing power supply to provide automatic
backup capability. A diode should be placed in series with the supply output
to prevent the gell cell from shoving current back into the supply if the AC
power fails. A Schottky diode is best due to its lower forward voltage drop;
they are available from Digi-Key.

Serious users of UPS systems for computers replace their batteries on a
very conservative schedule, to insure extremely high reliability.
Since the UPS batteries are kept on a continual float charge they are usually
in great shape. I recently picked up two Yasua 38 amp-hour immobilized
electrolyte batteries for $25 at a hamfest. I always carry a voltmeter to
hamfests to check the conditions of any batteries before I buy.

-Bob,  N3EMO

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

Date: 19 Jun 91 01:04:51 GMT
From: sequent!muncher.sequent.com![e-mail]
Subject: Field Day vhf packet info needed
To: [e-mail]

I just borrowed a pk232 to use on field day (got to get all the points
I can ). I have hooked it up and connected to a few sites, had some
short QSO's etc, HOWEVER....

I'm unclear as to how contest packet QSO's are handle. Do I actually
'CONNECT' to each site that I want to work, or can I just
monitor traffic/call cq and 'monitor' responses.

Yes, I know I should probably just monitor on FD and do what every one else
does, but I'd like to be ready.

Any and all comments welcome....

jim KG7HH 1-503-578-3171

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

Date: 18 Jun 91 16:16:13 GMT
From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!mips!altos!gumby![e-mail]
Subject: Kantronics KPC2 question
To: [e-mail]

In article <[e-mail]> [e-mail] (Bob Berger) writes:
>Does the KPC2 have the hardware time-out timer needed for unattended operation?


No.  It's an extra-cost option.

>I like the kantronics stuff, and realize a timer would be easy to add, but
>it's even easier to spend $30 less for a TNC2 clone if Kantronics is still
>too cheap to build in a timer.

Most people don't need the timer so Kantronics justifibly doesn't build it
in.

--
Jerry Gardner, NJ6A                                     Altos Computer Systems
UUCP: {sun|pyramid|sco|amdahl|uunet}!altos!jerry        2641 Orchard Parkway
Internet: [e-mail]                               San Jose, CA  95134
Help stamp out vi in our lifetime.                      [phone]

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

Date: 19 Jun 91 08:07:37 GMT
From: elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!hobbes.physics.uiowa.edu!maverick.ksu.ksu.edu!matt.ksu.ksu.edu![e-mail]
Subject: Kantronics KPC2 question
To: [e-mail]

[e-mail] (Bob Berger) writes:

>I like the kantronics stuff, and realize a timer would be easy to add, but
>it's even easier to spend $30 less for a TNC2 clone if Kantronics is still
>too cheap to build in a timer.

Even though there is not a hardware timer in the Kantronics KPC2, I
believe their 6809 clone CPU has a on-chip watchdog timer so if goes
crazy, it will reset itself.

In practice, I have never seen a Kantronics product hang a transmitter
or go into an odd mode.  Currently, we are running about 20 Kantronics
boxes around the Manhattan area, and we have never had any trouble with
them.

For my money, Kantronics have good functionality and extra features
that are nice to have.

-Steve Schallehn, KB0AGD
 Kansas State University

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

Date: 19 Jun 91 02:53:42 GMT
From: hpl-opus!hpnmdla![e-mail]
Subject: Kantronics KPC2 question
To: [e-mail]

In rec.radio.amateur.packet, [e-mail] (robert.f.casey) writes:

>In article <[e-mail]>, [e-mail] (Bob Berger) writes:
>>
>>Does the KPC2 have hardware time-out timer needed for unattended operation?

>I have a KPC2 and I can say from experience that it doesn't have a hardware
>timer.  I once came home to find the TNC in a wierd state, continuously
>making the radio transmit a single tone  "beeeeeeeeeeeeeeeeeeeeeeeeep".
>The radio took it no problem, but I'm sure that the other users of the freq
>in my area were less than thrilled with this tone jamming the channel.
>Only happened once in a year's time.

You're lucky.  My KPC-2 did the same thing, and I came home to find
my radio no longer functional.

Grrr.

AL N1AL

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

Date: 19 Jun 91 07:58:42 GMT
From: news.arc.nasa.gov!lll-winken!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!hobbes.physics.uiowa.edu!maverick.ksu.ksu.edu!matt.ksu.ksu.edu![e-mail]
Subject: NOS->Real OS (Was: memory problems with nos_0531.exe)
To: [e-mail]

[e-mail] (Phil R. Karn) writes:
>Yes, NOS is getting far too large for MS-DOS. This is particularly
>true with some of the "value added" versions that have extra features
>not in my "base" code.
>There are two longer-term solutions for this problem: move to UNIX for
>the fancy, large applications (this has the advantage that many of the
>applications are already freely available in the Internet/Usenet world
>and do not have to be reinvented for NOS), and recompiling NOS to run
>under a DOS extender on 386 class machines.

Have you considered changing NOS to a REAL Network OS?
It would be nice to be able to dynamically load each network service
as required.  I can imagine NOS being a full network OS where each
network service can be programmed as individual programs and NOS would
provide low level system services.  This would allow the "value added"
features to be added without changing the NOS kernel, and be
distributed as separate programs.

-Steve Schallehn, KB0AGD

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

Date: 18 Jun 91 02:09:45 GMT
From: unisoft!hoptoad!wet![e-mail]
Subject: Paccom PSK1, Heath HK232 and PG program
To: [e-mail]

A friend of mine (without usenet access) has asked me to post this
for him. He has a Paccom PSK1 and Heath HK232 connected in a tandem
arrangement for accessing the microsats. He is using a program
called PG which was written by some guys at the University of Surrey
in England. He has implemented the various TAPR modifications
necessary for connecting the two units together but he has not been
able to get the program to work with the system. The error message
that he gets is:

    Sending a Break Signal to get TNC into command mode
    TNC is not responding
    Connect indication or RS232 DCD pin is stuck on
    Abnormal Program Termination

Can someone suggest what might be causing the problem?

Also, someone mentioned that there was an article in '73 or QST in the
last 4 months about connecting the PSK1 and HK232 together. However, I
haven't been able to find it and I was wondering whether anyone knew
the correct reference.

Cheers,
-Graham ([e-mail] or wet![e-mail])

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

Date: 18 Jun 91 17:45:59 GMT
From: pacbell.com!mips!sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!crdgw1![e-mail]
Subject: Packet Cluster
To: [e-mail]

In article <[e-mail]>, winter@Apple (Patty Winter) writes:
>
>In article <[e-mail]> [e-mail] (John Barry EI7DNB) writes:
>
>>1) What software is needed to run Packet-Cluster
>
>Software of the same name from Pavilion Software. Since I'm not a sysop,
>I haven't paid attention to their address, the cost of the package, etc.
>Perhaps someone else out there can supply you with the necessary details.


Pavillion Software, PO BOX 803, Hudson MA  01749.

I got the address off the user manual.  I don't know the price of the software.

>Patty
>(Now officially a dual U.S./Irish citizen! Wave hi to County Limerick
>for me, John!)

Did you get your tax form yet?

don perley - ke2tp(@wa2umx.ny)

--
[e-mail]

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

Date: 18 Jun 91 17:42:42 GMT
From: pacbell.com!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!rpi!crdgw1![e-mail]
Subject: Packet posts without your callsign
To: [e-mail]

In article <[e-mail]>, brian@towers (Brian Murrey) writes:
>
>Also a friend of mine K9ML checked the white pages on packet to see if I was
>listed there and sure enough, it shows my home BBS as being the NG5QH system
>in Texas.  (I live in Indiana).
>
>Is this all legal?? If so, then packet radio has a VERY LARGE HOLE in it.
>What is to keep someone from logging on under their call sign, and posting
>using another callsign.

Just honesty, really... Nothing more than what stops someone from getting
on HF sideband using someone elses call.

don perley - ke2tp
--
[e-mail]

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

Date: 18 Jun 91 18:22:22 GMT
From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!cunixf.cc.columbia.edu!cunixb.cc.columbia.edu![e-mail]
Subject: Packet posts without your callsign
To: [e-mail]

In article <[e-mail]> perley@trub (Donald P Perley) writes:
>In article <[e-mail]>, brian@towers (Brian Murrey) writes:
>>
>>Also a friend of mine K9ML checked the white pages on packet to see if I was
>>listed there and sure enough, it shows my home BBS as being the NG5QH system
>>in Texas.  (I live in Indiana).
>>
>>Is this all legal?? If so, then packet radio has a VERY LARGE HOLE in it.
>>What is to keep someone from logging on under their call sign, and posting
>>using another callsign.
>
>Just honesty, really... Nothing more than what stops someone from getting
>on HF sideband using someone elses call.
True, but his voice will give him away.
* * * * * *  ====================== Meir Green
 * * * * * * ====================== (Internet) [e-mail]
* * * * * *  ====================== [e-mail]  [e-mail]
 * * * * * * ====================== (Amateur Radio) N2JPG

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

Date: 17 Jun 91 05:48:40 GMT
From: lll-winken!sun-barr!ccut!wnoc-tyo-news!astemgw!kuis!hugw!grape!humpty![e-mail]
Subject: Received R95.EXE
To: [e-mail]

Corresponding to my request for R95 file handling utility, I have
already received personally enough information and the R95.exe program
itself from a couple of people.  Thank you for paying attention to my
article.  Special thanks to ZL2BOI, N6TQS and G1XRL.

   de Kou, JA4MCI @ JG4IVE.JNET4.JPN.AS
       KA2SHO
       [e-mail]



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

Date: 18 Jun 91 13:22:07 GMT
From: mcsun!ukc!pyrltd!root44!praxis!praxis![e-mail]
To: [e-mail]

References <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject : Cheap 'n' Fast (was Re:The 'hidden transmitter' problem.)

>>>>> Regarding Re: The 'hidden transmitter' problem.; [e-mail] (Meir) adds:
Meir> Nntp-Posting-Host: cunixb.cc.columbia.edu

Meir> In article <[e-mail]> [e-mail] (Gary Coffman) writes:

    [loads of stuff about 56kbps deleted]

Meir> What kind of 9600 bps system can one get for $120 + $99? Are people using
Meir> any kind of data compression like on the newer 9600 bps telephone modems?

Well, this brings to mind something I heard about nearly a year
ago. Some US and Canadian hams were developing a 9k6bps beast based
on a Yamaha 7901 FAX modem chip. I believe it used some sort of
stellar coding but it worked over radio.  More to the point, it
required *NO* radio mods. I tried writing to the developers but
never heard anything.

Anyone else know about the status of this modem ?

Here's the original message.....

Mike - G6DHU

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

End of Packet-Radio Digest
******************************
Date: Thu, 20 Jun 91 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Junk
Subject: Packet-Radio Digest V91 #156
To: packet-radio


Packet-Radio Digest         Thu, 20 Jun 91       Volume 91 : Issue 156

Today's Topics:
                 CDMA
         DSP-12 by Grace Communications info needed.
            ftp PMP/Baycom wanted
              G1EMM NOS Ver 1.6 (113090)
               Kantronics KPC2 question
               Kantronics timer results
           Paccom PSK1, Heath HK232 and PG program
          The 'hidden transmitter' problem.

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

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

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

Date: 19 Jun 91 23:05:25 GMT
From: fluke!ssc-vax![e-mail]
Subject: CDMA
To: [e-mail]

In article <[e-mail]> [e-mail] writes:
>I am looking for pointers to an elementary description of how
>CDMA works in practice;  I have seen simple example descriptions,
>I have no idea, for example how many chips/bit occur in practice,
>whate actual bandwidth is in the real world.

    This will be difficult to find in the open press. A typical case
might be 500 chips/bit, and bandwidth between first nulls on the order of
10^8 Hz.

    You might want to check the latest issue of the IEEE Transactions
on Vehicular Technology, where Klein Gilhousen and other members of the
technical staff at Qualcomm, Inc. talk about their CDMA cellular system
(I haven't read my copy yet.)



--
Jeff Carroll            [e-mail]

"...and of their daughters it is written, 'Cursed be he who lies with
any manner of animal.'" - Talmud

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

Date: 19 Jun 91 00:39:07 GMT
From: comp.vuw.ac.nz!matai.vuw.ac.nz!ctl.co.nz!mof.govt.nz![e-mail]
Subject: DSP-12 by Grace Communications info needed.
To: [e-mail]

Hello everyone,
           Can someone provide me with info on a Grace Communications
DSP-12 as seen in Amsat Journal. What are this devices capabilities,
specifications, price, availability etc. I hope someone can help, thanks
in advance.

Charles Tetenburg (ZL1BQJ)            Internet: [e-mail]
Ministry of Forestry Computer Centre  Bitnet  : [e-mail]
Sala St.                              Phone   : [phone]
Rotorua
New Zealand

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

Date: 19 Jun 91 15:06:18 GMT
From: swrinde!sdd.hp.com!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!bgsuvax![e-mail]
Subject: ftp PMP/Baycom wanted
To: [e-mail]



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

Date: 19 Jun 91 15:59:00 GMT
From: [e-mail]
Subject: G1EMM NOS Ver 1.6 (113090)
To: [e-mail]

I am using version 113016 of G1EMM's implementation of TCPIP.
How do I make the program recognize nicknames in the domain.txt file?

My domain.txt has among other entries the following:
w9lzq-3.ampr.org                IN      A       [44.92.3.3]
kent                            IN      CNAME   w9lzq-3.ampr.org

It is my understanding from the available documentation that the domain.txt
shoul relate the canonical name with the IP address. This does not seem to
happen. I keep getting "Resolving kent...unknown host...". What am I doing
wrong?


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

Date: 19 Jun 91 17:19:30 GMT
From: [e-mail]
Subject: Kantronics KPC2 question
To: [e-mail]

The local electro-junk store has lots of normally-closed thermal
switches that can handle lots of amps - typically for around $1 or less
each.  Yours may too.  It takes only a moment to epoxy one to the
heatsink on your radio and wire it in series with the power lead.  That
way, if your TNC sticks on or the cat sits on the microphone, the radio
won't burn up.

You can also add a simple 555 timer into the TNC, but that would require
you to be able to solder on a circuit board without cooking it, a task
that but few of today's amateurs are capable of.
    - Brian

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

Date: 20 Jun 91 02:10:13 GMT
From: vi.ri.cmu.edu![e-mail]
Subject: Kantronics timer results
To: [e-mail]

The Kantronics KPC2 does not have a timer. I have heard several reports
of networks being jammed for long periods of time because someone left
a Kantronics unit on while unattended.

An automatic station without a timer is not just a bad idea; it's a violation
of the FCC rules.

So, I have ordered an MFJ 1270 instead. It is $30 cheaper than the Kantronics,
has a timer, and has an external modem interface that might be useful later.

-Bob N3EMO

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

Date: 20 Jun 91 03:43:32 GMT
From: swrinde!mips!spool.mu.edu!rex!rouge!pc.usl.edu![e-mail]
Subject: Paccom PSK1, Heath HK232 and PG program
To: [e-mail]

In article <[e-mail]> [e-mail] (Graham Brand) writes:
>A friend of mine (without usenet access) has asked me to post this
>for him. He has a Paccom PSK1 and Heath HK232 connected in a tandem
>arrangement for accessing the microsats. He is using a program
>called PG which was written by some guys at the University of Surrey
>in England. He has implemented the various TAPR modifications
>necessary for connecting the two units together but he has not been
>able to get the program to work with the system. The error message
>that he gets is:
>
>       Sending a Break Signal to get TNC into command mode
>       TNC is not responding
>       Connect indication or RS232 DCD pin is stuck on
>       Abnormal Program Termination

I'm not sure PG will work with a TNC that doesn't support the TAPR
command names ... the docs mention that hardware handshaking is used,
hence pins 2,3,4,5,6,7 should be wired without jumpers, and that DCD
should indicate the connected state of the tnc.  PG.TNC contains commands
to be sent to the tnc in addition to those hardwired into PG, and PGDONE.TNC
contains tnc command to be sent upon exiting PG; perhaps these files could
be modified for PK232 commands?

73
--James
N5KNX
--
-- James Dugal, N5KNX           Internet: [e-mail]
Associate Director              Ham packet: n5knx@k5arh
Computing Center                US Mail: PO Box 42770  Lafayette, LA  70504
University of Southwestern LA.  Tel. [phone]       U.S.A.

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

Date: 19 Jun 91 23:34:26 GMT
From: swrinde!sdd.hp.com!hp-col!winfree![e-mail]
Subject: The 'hidden transmitter' problem.
To: [e-mail]

[e-mail] (Phil R. Karn) writes:
> There are quite a few multi-band antennas on the market, and you can get
> crossband splitters to go with them. You still need two radios (unless you
> use one of the newer duplex dual-band radios) but at least they can
> share one feedline and one antenna.

This is quite true for vertical omni's, but not for directional gain antennas.
This works at the repeater site, but we'd been planning on yagi's at user
sites aimed at the repeater... and I haven't seen any great dual band
directional antennas?  Am sure we could beat the dual feedline problem...

Bdale

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

Date: 19 Jun 91 12:48:53 GMT
From: pa.dec.com!nntpd.lkg.dec.com!ryn.mro4.dec.com!ultnix![e-mail]
To: [e-mail]

References <[e-mail]>, <[e-mail]>, <[e-mail]>
Reply-To : [e-mail] (Patrick St. Joseph Teahan Taber)
Subject : Re: Packet posts without your callsign

In article <[e-mail]>, [e-mail] (Meir) writes:
|>In article <[e-mail]> perley@trub (Donald P Perley) writes:
|>>In article <[e-mail]>, brian@towers (Brian Murrey) writes:
|>>>Is this all legal?? If so, then packet radio has a VERY LARGE HOLE in it.
|>>>What is to keep someone from logging on under their call sign, and posting
|>>>using another callsign.
|>>
|>>Just honesty, really... Nothing more than what stops someone from getting
|>>on HF sideband using someone elses call.
|>True, but his voice will give him away.

You're saying that your voice is so well-known that every ham in the world is going to know it?  Wow.  For most of us, there'd be no way to tell if someone got on the air with a phoney call.  The fact that it's a rare event is either a tribute to hams in general or is an indicator that in ordinary situations the vast majority of people prefer to Do The Right Thing.

My first instinct in this is that there's no reason why packet should have to solve problems that the other modes don't.  If you can't verify identity in any other mode, then it seems pointless to get into baroque security schemes for packet.

The only ambivalence I have about it is that packet causes one problem that (most) other modes don't -- packet messages "linger."  If someone scoops your call on sideband to do some Bad Thing then some people hear it but it's over as soon as the transmission is over.  If someone forges a packet message, it can be cached in thousands of places around the world for an untold length of time.

The badness here has to be weighed against the goodness of being able to get into a packet system with no prior arrangements.  It's all well and good to talk about security with encrypted passwords etc. but if you pull into a new town with a portable setup and want to work a little packet, you'd be SOL.  Not to mention the chilling effect on people who want to try packet, but would be put off by having to "register."

There are schemes that would get around both problems to some extent, but I'm not sure it's worth the effort of implementing them at present.

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

Give a man a fish and you've fed him for a day.
Teach a man to fish and you're an unemployed fisherman.

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

Date: 20 Jun 91 02:29:24 GMT
From: epic![e-mail]
To: [e-mail]

References <[e-mail]>, <[e-mail]>, <[e-mail]>
w
Reply-To : [e-mail]
Subject : Re: Kantronics KPC2 question

In article <[e-mail]>, [e-mail] (Brian Kantor) writes:
|> You can also add a simple 555 timer into the TNC, but that would require
|> you to be able to solder on a circuit board without cooking it, a task
|> that but few of today's amateurs are capable of.

Actually, you can make a simple but highly effective watchdog timer
with even less effort than that. Just put an RC hipass filter
consisting of an electrolytic capacitor and a resistor in the keying
line, followed by a schmitt trigger (or gate of a mosfet used as a
switch). A diode is also needed to discharge the cap quickly when the
transmitter is unkeyed.

This is the circuit used in the original TNC-2 design. It is so simple
(and the effects of a stuck transmitter so serious) that I think its
omission on ANY TNC is simply inexcusable.

Phil

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

Date: 20 Jun 91 02:24:34 GMT
From: epic![e-mail]
To: [e-mail]

References <[e-mail]>, <[e-mail]>, <[e-mail]>
Reply-To : [e-mail]
Subject : Re: NOS->Real OS (Was: memory problems with nos_0531.exe)

In article <[e-mail]>, [e-mail] (Steve Schallehn) writes:
|> Have you considered changing NOS to a REAL Network OS?

Yes, indeed I have. And when you're done you end up with something
that looks an AWFUL lot like Berkeley UNIX. And since it already
exists, why reinvent it?

I understand that 4.4BSD UNIX for the 386 is already in beta test. The
only open issue is apparently whether the kernel will be totally free
of AT&T code. If it is, the entire system will be freely
distributable.

Much of my original advocacy of TCP/IP for amateur radio was due to
its existence as a de-facto industry standard. There's no reason why
we have to build everything ourselves just because we're hams. NOS was
a way of getting things started until regular off-the-shelf TCP/IP
hosts were within reach of the average ham. This is just about to
happen.

I would like NOS to continue doing what it does best: handling the
radio-specific tasks in the network (IP-to-AX.25 encapsulation, radio
channel access and routing, etc, as well as low-end MS-DOS clients).
I've also found it a convenient vehicle for experiments with TCP and
IP congestion control algorithms. But run the big TCP/IP applications
on the UNIX systems where free and widely supported application code
already exists (e.g., sendmail, BIND, etc).

Phil

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

Date: (null)
From: (null)
also available from nic.funet.fi (I think :-)  pub/ham/rats/baycom

bobb


*************************************************************************
*  Bob Fyfe                                                             *
*  c/o Computer Services                                                *
*  Rm. 241 Math-Scieince Building    "This world is not my home...      *
*  Bowling Green State University       ...I'm just-a passing through"  *
*  Bowling Green, Ohio 43403                                            *
*************************************************************************
*  Phone:    [phone]                                             *
*  Bitnet:   BFYFE@TRAPPER  -or-  FYFE@BGSUOPIE                         *
*  Internet: [e-mail]  -or-  [e-mail]           *
*************************************************************************

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

Date: 19 Jun 91 21:24:31 GMT
From: swrinde!zaphod.mps.ohio-state.edu!caen!umich!gumby!wmu-coyote![e-mail]
To: [e-mail]

References <[e-mail]>, <[e-mail]>, <[e-mail]>
Reply-To : [e-mail]
Subject : Re: NOS->Real OS (Was: memory problems with nos_0531.exe)

Don't quote me on this, but I believe I once saw a version of NOS floating
around that was supposed to be totally integrated into Desqview. This would
make sense because Desqview has no problems allowing you to have multiple
programs running with some sort of shared module.

Doing it on a PD basis, someone should marry it to Ctask, which would handle
the necessary problems.

Another way is that with the new Turbo C, if you can actually get it to compile
under it, use the -Y option to crank DOWN the memory requirement and let it
do overlays.

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

End of Packet-Radio Digest
******************************
Date: Fri, 21 Jun 91 04:30:04 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Junk
Subject: Packet-Radio Digest V91 #157
To: packet-radio


Packet-Radio Digest         Fri, 21 Jun 91       Volume 91 : Issue 157

Today's Topics:
          9600 BPS FAX MODEMS on radio links
         Deep-cycle batteries? (was Portable Packet)
              G1EMM NOS Ver 1.6 (113090)
                Help!
             Value of Ham Radio?

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

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

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

Date: 20 Jun 91 11:22:00 GMT
From: [e-mail]
Subject: 9600 BPS FAX MODEMS on radio links
To: [e-mail]

There are some comments on:

>             9600 BAUD (BPS) FAX TEST RESULTS

>At WB8WKA, tests were also run at power levels less then 160 watts with
>excellent results, but due to the sharing of the radio with one of the
>Detroit/Windsor TCP/IP lan's, running lower power full time was not practical.

Now... using 160 W for few miles QRB ?? Just to block everybody around ?
Is THAT the way HAM network works ?? You were testing new modes, which
are not compatibile with old one, so if you stay on same QRG, this is
intentional QRM. Or it is too hard to make QSY ?

>MSYS and/or our TNC's not being able to go beyond 9600 baud. The tnc's where
>modified for 19200 baud operations but we experienced dropped characters. In
>any type of KISS operation, it is important for maximum throughput, that your
>DATA link (async link) be at least twice as fast as your radio link. As we
>where not able to achieve this, then our hope is that much faster throughput
>can be obtained.

Hints for everybody with same trouble:
1. Use N2WX or WA8DED EPROMs to unload RS-232 interface
   (They are quite usable up to 19200 bd on HDLC port).
2. Use normal level 2 digis few times, so any date send from PC
   is send several times over radio path.
  (C YU3FK via YU3FK YT3A YU3FK YT3A YU3FK YT3A )
  Then multiply number of bytes transferred with number of hops
  they took. If test is done on CLEAR QRG (160 W for 5 miles..)
  retries are not likely.
3. Put 9.8 MHz XTAL to TNC-2. With CMOS SIO-B and Z80 H it works !
  (NET/ROM, N2WX and WA8DED can operate 38400 bd on HDLC port)
4. If you HAVE to use KISS TNCs, then check again PC sw. Use FAST PC.
   HAMs run 56kb over KISS - so 9600 bd is not so fast.

>GENERAL IMPRESSIONS:

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

TXDELAY: time to stabilize TX PLL + time to get maximum power +
 time to get signal over RX + sinhronization of RX modem. Only last
 point is dependent of modem, all the rest is fixed for given RIGs.
 If TXDELAY is  200 ms on 9600 bits/sec links then a lot of bandwith is wasted.
 Anyhow, I heard of even longer times from HAMs testing Rockwell chips.
 BTW: what is normal TXDELAY for G3RUH 9600 /HAPN 4800 etc modems ?

Radio links are NOT telephone links. Their characteristics are
definitely different. I never heard of echo canceler on HAM packet link;
also I wonder about behaviour of landline FAX modem chips on real VHF/UHF
links, with a lot of phase distorsion because of reflections.
I think noise characteristics are also different.
Smetimes I wonder how our modems work, when I look what is comming out
from RX output. I would love to hear on any comparations between
1200 bd FSK and 9600 bits/sec Yamaha chip on average radio links with
reflections etc.

>73's
>
>Jeff King WB8WKA

 73 Iztok, YU3FK

[e-mail]

YU3FK @YT3A.YUG.EU

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

Date: 19 Jun 91 23:58:38 GMT
From: hpl-opus!hpspdra![e-mail]
Subject: Deep-cycle batteries? (was Portable Packet)
To: [e-mail]

|>All this stuff runs on 12 volts so any car battery will do. A deep
|>cycle marine battery is better, but not necessary....
|                      ^^ ^^^^^^
|Probably not!  Deep-cycle batteries get their two-part name
|for good reason:
|  * Deep - 'cause their "acceptable" (according to the manufacturer)
|          output voltage drops to about NINE volts or so.
|  * Cycle - 'cause it can be discharged so deeply and then recharged
|           more times than can a "regular" battery.
|
|But can YOUR 12-volt equipment run on 9 volts?  Mine can't!

Most lead-acid batteries, including gelled types and
automotive batteries, do not take kindly to the voltage going less than
12 volts.  It generally shortens the life of the battery severely.

The deep cycle battery probably won't have much current left when the
voltage drops below 12, BUT you can expect to recharge the battery and
not have to buy a new one.
73, Paul AA6PZ

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

Date: 20 Jun 91 09:22:10 GMT
From: mcsun!ukc!mucs!mccuts![e-mail]
Subject: G1EMM NOS Ver 1.6 (113090)
To: [e-mail]

You need a '.' at the end of each name, i.e:


g1yyh.            IN CNAME  g1yyh.ampr.org.
g1yyh.ampr.org.   IN A      44.131.1.8


Cheers, John.

       John Heaton                      [e-mail] (QTHR)
     * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - *
     |                      NRS Central Administrator                      |
     | MCC Network Unit, The University, Oxford Road, Manchester,  M13-9PL |
     |           Phone: [phone], FAX: [phone]          |
     * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - *

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

Date: 20 Jun 91 21:30:00 GMT
From: [e-mail]
Subject: Help!
To: [e-mail]

Now, I am trying to get G1EMM's 113016 version of software to talk to
MSYS (packet bbs) using TCPIP. The connections seem very erratic and
the transmission speed varies greatly.

Has anyone ever tried to use Nos with MSYS. If so, can you please tell me
what the parameters in the setup file(s) for both pieces of software should
be. I think MSYS communicates using Datagrams and I have set my ip mode to
datagram. Communication with MSYS is virtually impossible using VC.

Can one also digi to another IP station via an AX25 digipeat?

What does one need to do in order to make the SMTP mail forward in MSYS to
work and talk to a station running the above mentioned version of NOS?

Any and all help would be appreciated...I am coming to the end of the rope!
73,
Feroz, wu9n


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

Date: 19 Jun 91 23:49:22 GMT
From: hpl-opus!hpspdra![e-mail]
Subject: Value of Ham Radio?
To: [e-mail]

By all means get your license and a two-meter HT.  You might want to add
a solar panel to the bike to recharge the batteries.  You will be able
to meet a lot of hams on your trip, and probably get lots of good
suggestions regarding places to visit or routes to avoid.
Just be prepared to wait ~7 weeks for the FCC to process the license.

73 Paul AA6PZ

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

Date: 18 Jun 91 13:53:30 GMT
From: sdd.hp.com!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!wa4mei!ke4zv![e-mail]
To: [e-mail]

References <[e-mail]>, <[e-mail]>, <[e-mail]>7
Reply-To : [e-mail] (Gary Coffman)
Subject : Re: The 'hidden transmitter' problem.

In article <[e-mail]> [e-mail] (Meir) writes:
>What kind of 9600 bps system can one get for $120 + $99?  Are people using
>any kind of data compression like on the newer 9600 bps telephone modems?

The Pac-Comm Tiny 2 TNC and the Pac-Comm G3RUH modem meet those price criteria.
I have a pair of the systems in operation here. Those were Dayton show
prices, retail is slightly higher. You will probably have to modify your
radio to make 9600 baud work. It's not strictly plug and play because of
the limitations of the voice circuitry in typical radios. Data compression
is not used on amateur radio for several reasons right now, mostly regulatory.

>Where does the future of full featured packet networking lie?  Do you think
>a modified TCP/IP system will take over?  I am interested in the following:
>1) Text message store and forward to Amateurs and 3rd parties
>2) Large file transfer capabilities
>3) Internet mail connection
>4) Internet access
>
>What system is my best bet?  I really would prefer radio over telephone since
>I want to help advance Amateur Radio, need frequent network access, and a
>second telephone line is impractical.

Well *I* like TCP/IP for those applications. The non-commercial
limitations on amateur radio limit it's usefulness for Internet access,
but the functionality is there for file transfer and mail as well as a
good telnet implimentation. The KA9Q software, and it's various enchanced
spinoffs, are an attractive way to operate packet. I recently went to
the Gracilis internal plugin board in place of a TNC and use their
enhanced KA9Q code to drive a 56kb modem and their 9600 baud modem and
radio. I still use a TNC and voice grade radio at 1200 baud. I plan
to bring up an ethernet link to my Unix boxes in the near future so people
can log in to them via the radio.

Ultimately, I'm interested in distributed computing and hope to see a
network architecture that will allow me to play interactive real time
games with other stations and to try for the "ultimate supercomputer"
consisting of multiple machines working on the same problem in parallel
linked by the packet network. To do that, I need a fast transparant
network and I believe that the TCP/IP protocol working over 56kb or
faster links will eventually give it to me. Right now we don't have
a good dynamic routing system and the 56 kb network is still mostly
limited to interconnecting slow speed LANS where users continue to
run 1200 and occasionally 9600 baud. But progress is being made and
I can see a glimmer of light at the end of the tunnel.

I also have great hopes for Coherent as the multitasking OS to replace
DOS on our packet machines. Multitasking is necessary for my ultimate
goals and Desqview just isn't good enough. I don't even want to talk
about Windows.

Gary KE4ZV

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

End of Packet-Radio Digest
******************************
Date: Sat, 22 Jun 91 04:30:04 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Bulk
Subject: Packet-Radio Digest V91 #158
To: packet-radio


Packet-Radio Digest         Sat, 22 Jun 91       Volume 91 : Issue 158

Today's Topics:
              G1EMM NOS Ver 1.6 (113090)
         Gonetz = E-mail via Soviet Satellite
             Hamfest - Northeast.
            PA0GRI 0604 ax25 bug??
           Paccom PSK1, Heath HK232 and PG program
             Value of Ham Radio?

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

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

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

Date: 21 Jun 91 15:29:06 GMT
From: swrinde!dptspd!dptspd!lcz, Date:@ucsd.edu, [e-mail], [e-mail],
Subject: G1EMM NOS Ver 1.6 (113090)
To: [e-mail]

[e-mail] (John Heaton - G1YYH) writes:

>You need a '.' at the end of each name, i.e:
>
>g1yyh.            IN CNAME  g1yyh.ampr.org.
>g1yyh.ampr.org.   IN A      44.131.1.8

The trailing period is needed for a fully qualified name (or nickname).
However, you shouldn't need a CNAME for "g1yyh." if "g1yyh.ampr.org." is in
the file.  If you set your domain suffix in NOS to "ampr.org." (using the
"domain suffix" command), then the domain server should append this to any
host name that does not contain periods before doing a lookup.

The PA0GRI version actually extends this to handle names that include periods
but are subdomains within the default domain.  For example, if
"mac.n5lyt.ampr.org." is in my domain file, and my domain suffix is
"ampr.org.", then I can use "mac.n5lyt" in NOS and the domain lookup will find
"mac.n5lyt.ampr.org.".  This doesn't seem to match the behaviour of other DNS
systems I've seen, but it sure is nice to use!

73/Lee, N5LYT

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

Date: 21 Jun 91 19:02:04 GMT
From: usc!apple!well![e-mail]
Subject: Gonetz = E-mail via Soviet Satellite
To: [e-mail]


Last week I posted a query about "Gonetz," a store-and-forward
packet radio data network based on constellations of low earth
orbit satellites that the USSR plans to implement.

Jane's Defence Weekly had a brief passage about it in their 1
June 1991 issue.  It is apparently based on an existing
military/security system called Sextet, which Jane's described
as "the only truly operational lightsat system in the world."
(Gonetz is a Russian word meaning "messenger.")

Thanks to the magic of Usenet, Ed O'Grady ([e-mail])
saw my query and replied by email.  His company, DYJ Technologies,
was misidentified by Jane's as providing marketing services for
Gonetz.  They are in fact consulting on the project, but not
marketing it.  Anyway, he provided more detail about Gonetz, and
put me in touch with Vern Riportella, whose company is marketing
Gonetz services in North America.  Vern is well-known to ham
radio operators for his involvement in AMSAT-NA and hamsat
technology generally.

To summarize a series of phonecalls with both men, the idea to
market this technology outside the Soviet Union came from
Soyuzmedinform (the All-Union Medical Informatics bureau of the
USSR health ministry).  They originally saw it as a way to send
critical health information to and from areas not served by
conventional electronic communications, especially in rural
areas and developing countries.  But recognizing that this
application might not generate enough money or traffic to pay
for the system, they began thinking in more general terms.  They
organized a "Consortium of Small Satellite Constructors and
Service Providers (COSSCASP) to adapt the Sextet technology and
make it available worldwide.  In addition to Soyuzmedinform, the
current members of COSSCASP are:

  NPO Precision Instruments:  a Moscow-based organization that
  designs scientific equipment.  They will design Gonetz's space
  and terrestrial segments, and develop functional compatibility
  standards for user terminals produced by others.

  NPO Applied Mechanics:  a large production facility based in
  Krasnayarsk, they build most of the Soviet Union's satellites.
  (By the way, NPO is a Russian acryonym for "scientific
  production organization.")

  Network Services International:  NSI is Riportella's company
  (see below for address).

Many aspects of the system have yet to be defined.  They expect
the orbital configuration ultimately to involve 5 or 6 orbital
planes with 6 satellites in each plane.  (Sextets are launched 6
at a time on one rocket.)  That way, users anywhere in the world
would not have to wait more than 20 minutes for a satellite to
came into "view."

Gonetz is expected to serve both fixed and mobile terminals with
a variety of digital modes, primarily email, but also fax and
maybe voicemail.  Apparently the digital links in the USSR's
phone system use continuously variable slope delta modulation,
so they are thinking of using that for voice in the Gonetz
system.  Riportella is arguing for linear predictive coding, as
that requires much lower data rates.  But they are still unsure
what applications will be most attractive to users, and are
assuming the basic service will be email.

It is also unclear what radio bands will be used, or whether a
new international allocation is needed.  Gonetz was originally
planned for the 200-400 MHz range, but that presents some
coordination problems with US military systems.  The Sextet
framework is apparently flexible enough that the radio issues
don't have to be nailed down just yet.  O'Grady said they will
probably go along with whatever WARC-92 decides.

They hope to launch the first batch of satellites in the fourth
quarter of 1993.  Initially, all messages will be processed
through ground stations to reach end users.  The process will be
fully automated.  A computer will read the destination address
and determine which satellite provides the fastest delivery
route.  By 1995, they hope to have narrowband inter-satellite
links working.  That will eliminate the ground link in many
cases, speeding delivery and supporting two-way real-time
interactive channels.  They anticipate that handheld terminals
will communicate at 9600 baud, fixed terminals at 56KB.

Recognizing that the USSR has problems with quality control for
consumer goods, they will encourage third parties to design and
manufacture equipment for end users.  All of the handheld units
will be built outside the USSR.

No price schedule or rate card has been devised yet.  Because
the satellite technology is already mature, and Soviet launch
services are relatively inexpensive, they expect the entire
system to be built for around a billion ruples.  Pick your
favorite conversion ratio to figure that in dollars, but it
should be less than half the cost of Iridium, and the user fees
will hopefully be competitive with Orbcomm's.

For more information about Gonetz, contact:

    Vern Riportella
    COSSCASP VP for Marketing
    Network Services International
    P.O. Box 357
    Warwick, NY 10990 USA
    voice: 1-914-986-6904
    fax: [phone]
    email: rip@cdp   <also>   sfmt: rip
    mcimail: 324-7389

            ---Robert Horvitz
               Internews Radio Consultant
               Independent Electronic Media Program
                  for East & Central Europe
               1122-1/2  E Street, SE
               Washington, DC 20003-2232 USA
               email:  [e-mail]
                   rhorvitz@uunet!capital.com

(follow-ups to sci.space, please)
--
!.|.!.|.!.|.!.|.!.|.!.|.!.|.!.|.!.|.!.|.!.|.!.|.!.|.!.|.!.|.!.|.!.|.!.|
Robert Horvitz    1122-1/2 E St. SE    Washington, DC 20003-2232    USA
              uucp:  ...uunet!capital!rhorvitz

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

Date: 21 Jun 91 19:26:59 GMT
From: [e-mail]
Subject: Hamfest - Northeast.
To: [e-mail]

*************************************************************************
*                     ANNOUNCING THE 13th ANNUAL        >  TALK IN:     *
*              SUSSEX COUNTY AMATEUR RADIO CLUB HAMFEST > 147.30/90     *
*                         AUGUSTA, NEW JERSEY           > 222.90/224.50 *
*                 BUYERS: $4,  Spouse  &  Kids  FREE!   > 146.52 Simplx *
*                 Best Value in the NY/NJ/CT/PA area.   ^^^^^^^^^^^^^^^^*
*                 DATE:   JULY 14, 1991   (Sunday)                      *
*                 PLACE:  SUSSEX COUNTY FAIR GROUNDS                    *
*                 AUGUSTA, NEW JERSEY. (Plains Rd off RT 206)           *
*   A SHORT DRIVE FROM THE NEW YORK METROPOLITAN AREA IN THE BEAUTIFUL  *
*            AND  SCENIC  SKYLANDS  OF  NORTH  WEST  NEW  JERSEY        *
*     WIN AT THE DOOR: 3RD PRIZE; $100 BILL; 2ND PRIZE: ICOM 2SAT HT    *
*            !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!         *
*            >>>   1ST PRIZE:    ICOM 229A 2m TRANSCEIVER   <<<         *
*            !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!         *
*               A full day of FUN - rain or shine - For ALL.            *
* Vendors: Large indoor selling area in Fairgrounds Exhibition Bldg.    *
* $8 at dorr per space. Acres of Unlimited Tailgate Space, $6 at door.  *
* Food & Refreshments. Comodious Facilities. Register in advance & save.*
* Contact:  K2OX, 185 Weldon Rd, Lk Hopatcong, NJ 07849.  201-663-0677  *
*************************************************************************

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

Date: 21 Jun 91 19:49:33 GMT
From: swrinde!sdd.hp.com!zaphod.mps.ohio-state.edu!hobbes.physics.uiowa.edu!maverick.ksu.ksu.edu!ux1.cso.uiuc.edu![e-mail]
Subject: PA0GRI 0604 ax25 bug??
To: [e-mail]

Hi, there are 2 of us here in the Springfield, IL area running the new gri
NOS.  Both of us are having the same problem.  When someone connects via ax25
and then initiates a "chat", no data packets go from the local operator back
to the ax25 user.  What I mean is, I can keep typing but the rig never keys up
and what I type never goes to the other guy.  Also, in the session listing,
the send-Q shows a value of 0 bytes.  So is this a bug? Is there a new parameterI'm not setting or an old one that needs to be set?
Thanks in advance, Jay

--
*************************************************************************
* 73 de Jay, WT9S     Internet: [e-mail]                *
*                     Packet:   [e-mail]                    *
*************************************************************************

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

Date: 21 Jun 91 14:05:52 GMT
From: fernwood!uupsi!uhasun!arrlhq![e-mail]
Subject: Paccom PSK1, Heath HK232 and PG program
To: [e-mail]

In rec.radio.amateur.packet, [e-mail] (Graham Brand) writes:
>A friend of mine (without usenet access) has asked me to post this
>for him. He has a Paccom PSK1 and Heath HK232 connected in a tandem
>arrangement for accessing the microsats. He is using a program
>called PG which was written by some guys at the University of Surrey
>in England. He has implemented the various TAPR modifications
>necessary for connecting the two units together but he has not been
>able to get the program to work with the system. The error message
>that he gets is:
>
>       Sending a Break Signal to get TNC into command mode
>       TNC is not responding
>       Connect indication or RS232 DCD pin is stuck on
>       Abnormal Program Termination
>
>Can someone suggest what might be causing the problem?

Try adding the line:

DCDCONN ON

to the PG.TNC file.  Also, make sure that pin 8 of the TNC's RS-232
is wired to pin 8 of the computer's.
-----
Jon Bloom, KE3Z                     |  [e-mail]
American Radio Relay League         |  uhasun!arrlhq!jbloom
225 Main St.                        |
Newington, CT  06111                |  "This mind intentionally left blank."

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

Date: 21 Jun 91 12:49:59 GMT
From: swrinde!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!cwsys3![e-mail]
Subject: Value of Ham Radio?
To: [e-mail]

In article <[e-mail]> [e-mail] (Paul Zander) writes:
>By all means get your license and a two-meter HT.  You might want to add
>a solar panel to the bike to recharge the batteries.  You will be able
>to meet a lot of hams on your trip, and probably get lots of good
>suggestions regarding places to visit or routes to avoid.
>Just be prepared to wait ~7 weeks for the FCC to process the license.
>
>73 Paul AA6PZ


I missed the original--is someone starting up with bicycle mobile?
It's great fun, by all means give it a try.  My wife and I go 2-meter
bicycle mobile daily on our work commutes, and use cross-band full
duplex for long rides together.  There is also a national bicycle
hamming group including some who do HF mobile.  No CW that I know of :-).
There has been one documented bicycle-to-bicycle HF, from Wisconsin
to Florida.

Lots of fun.  Listen for us on the 146.79 machine in Cleveland...

-David, AD8Y

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

Date: 21 Jun 91 22:09:08 GMT
From: epic![e-mail]
To: [e-mail]

References <[e-mail]>, <[e-mail]>, <[e-mail]>
Reply-To : [e-mail]
Subject : Re: The 'hidden transmitter' problem.

In article <[e-mail]>, [e-mail] (Gary Coffman) writes:
|> Data compression
|> is not used on amateur radio for several reasons right now, mostly regulatory.

Eh? I ship PKZIP and .Z (compressed) files over the air all the time.
As far as I'm concerned, I'm using a coding scheme the purpose of which is
to facilitate communication (by reducing the number of bits by 60% or so),
not to hide the meaning of the communications (the algorithms are public
and widely available). This makes it perfectly legal.

Phil

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

Date: 21 Jun 91 22:21:54 GMT
From: rosevax!bert.Rosemount.COM![e-mail]
To: [e-mail]

References <[e-mail]>, <[e-mail]>, <[e-mail]>
Reply-To : [e-mail] (Michael Foerster)
Subject : Re: Deep cycle batteries


We have used gell cells a lot in the past for backup of computer
systems.

Some gell cells will go to a high impedence state, where they
will no longer charge.   Try to charge them and they will only
take a few mills.

The manufacturer recommends that you then REVERSE charge them with
a current limiting supply (for a 5 amp hour battery) at .5 amps
MAXIMUM for 30 minutes.  Then forward charge them at about .5
amps and they will recover much of their power, though not all.

We never sent a battery back to customers after they went hight
impedence, but they made great batteries for home projects.

Mikef

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

End of Packet-Radio Digest
******************************
Date: Sun, 23 Jun 91 04:30:04 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Bulk
Subject: Packet-Radio Digest V91 #159
To: packet-radio


Packet-Radio Digest         Sun, 23 Jun 91       Volume 91 : Issue 159

Today's Topics:
          Packet posts without your callsign

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

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

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

Date: 21 Jun 91 03:53:08 GMT
From: sdd.hp.com!swrinde!emory!wa4mei!ke4zv![e-mail]
Subject: Packet posts without your callsign
To: [e-mail]

In article <[e-mail]> [e-mail] (Brian Murrey) writes:
>
[Re: Fidonet postings relayed on packet]

>I started inquirying in the echo about this and N5PCA admitted that he had
>posted it but had violated no rules by doing so, he claims that he was logged
>in to the packet system with his own callsign....but the thing that bothers me
>is that now I am getting netmail asking why I do not respond to messages
>people are leaving me on packet. (GREAT)
>
>Also a friend of mine K9ML checked the white pages on packet to see if I was
>listed there and sure enough, it shows my home BBS as being the NG5QH system
>in Texas.  (I live in Indiana).
>
>Is this all legal?? If so, then packet radio has a VERY LARGE HOLE in it.
>What is to keep someone from logging on under their call sign, and posting
>using another callsign.  If the message content was illegal then the FCC is
>going to come after the BBS op and more than likely the callsign indicated in
>the FROM line.  If the BBSOP doesn't have his logs to prove who posted the
>message than an innocent person could get into some real shit with the FCC.
>
>N5PCA and a few others keep telling me that they didn't violate any rules, I
>disagree with them, but since I do not use packet yet I am not 100% up to
>snuff on the rules.  I know that on my landline BBS that I am legally
>responsible for the posts and information contained therein, if an imposter
>posts something illegal I'm up the creek (I voice validate everyone and use
>some other security measures) without a paddle.

He didn't violate any amateur rules, and yes the packet BBS system has many
large holes in it security wise. It seems that you may have inadvertently
committed plagarism by indicating *your* amateur station's callsign as the
source of the material from Usenet that you reposted through use of a From:
line with your amateur station's callsign in your Fidonet posting. That's
what's being picked up by the packet BBS software. The call N5PCA is considered
merely a relay BBS by the software. The innermost From: line in the message is
picked up as the originating station and will be shown as such in the source
field. This is due to the way forwarding is done in the BBS network. It is a
nasty security hole, but not the only one by far.

You could stop the problem by not identifying your postings to Fidonet
with your amateur station's callsign.

Gary KE4ZV

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

End of Packet-Radio Digest
******************************
Date: Mon, 24 Jun 91 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Bulk
Subject: Packet-Radio Digest V91 #160
To: packet-radio


Packet-Radio Digest         Mon, 24 Jun 91       Volume 91 : Issue 160

Today's Topics:
                Help!
             Sensitivity of Am7910 modem
        WANTED: 8530 SCC PC interface circuit & driver

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

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

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

Date: 23 Jun 91 10:40:33 GMT
From: munnari.oz.au!manuel!csc.canberra.edu.au!echo![e-mail]
Subject: Help!
To: [e-mail]

In <[e-mail]> [e-mail] (Feroz Ghouse 4S7FG/WU9N) writes:

>Now, I am trying to get G1EMM's 113016 version of software to talk to
>MSYS (packet bbs) using TCPIP. The connections seem very erratic and
>the transmission speed varies greatly.

>Has anyone ever tried to use Nos with MSYS. If so, can you please tell me
>what the parameters in the setup file(s) for both pieces of software should
>be. I think MSYS communicates using Datagrams and I have set my ip mode to
>datagram. Communication with MSYS is virtually impossible using VC.

I run a three computer LAN here MSYS<->890421.1 NET under XENIX <->PC running
G1EMM 901130/1.4.  The whole thing runs at 4800 baud (MSYS has a hernia trying
to run faster than 9600 baud on any of the 3 ports on the XT. :-) and works
reasonably well.  Make sure you have told MSYS that the serial link is
FULL Duplex and make your link timers very short.  Other than that it should
work fine.  Oh...  I'm still encapsulating the IP in AX25 over the serial
line as (1) I can't make MSYS talk SLIP and (2) it allows me to run an internal
NET/ROM network that effectively gives me a TNC attached to every Computer!

MSYS also can't handle VC mode.  You *must* use Datagram mode.

>Can one also digi to another IP station via an AX25 digipeat?

Yes, It's the *major* way of routing around here at the moment.  In MSYS
you spell out the digipeater path ie;
ARP ADD VK1KCM-1 0 44.136.0.5 VK2RPT-5
    ^ Call
         ^ MSYS Port
              ^ IP address
                 ^ Digipeater.  You can use more if needed.

>What does one need to do in order to make the SMTP mail forward in MSYS to
>work and talk to a station running the above mentioned version of NOS?

MSYS supports SMTP for personal mail and also for the one-way transmission
of Bulletins. It's documented in the manual however I think the syntax in the
forwarding file is;
-----
44 136 0 5 VK1KCM
VK1KCM
-----
Note the spaces.

Carl

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

Date: 21 Jun 91 01:33:00 GMT
From: usc!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!turnkey!orchard.la.locus.com!devnet.la.locus.com![e-mail]
Subject: Sensitivity of Am7910 modem
To: [e-mail]

   The other night, I was playing packet when a local station (AA6JQ!)
connected to me. I noticed it sometimes required several retries to
get traffic through to him; this shouldn't be the case, since he lives
3 miles from me

   [Yes, it is true. Two days after moving into my Lancaster QTH, I
    discover that AA6JQ lives three miles from me, KK6JQ. His name
    is Harlan. Yes, I've been called Harlan on the air several times. ]

  Harlan is wondering what is wrong with his TNC; he cannot connect to
most of the nodes he normally can. He thinks his audio is too low, so
I put a whip on my HT and listen. When my station transmits, it sounds
fine. I hear a blank carrier reply. Huh? About 80% of the time, my
TNC fishes a valid frame out of the (as far as my ear is concerned)
dead carrier.

   The Am7910 is specified to require some small signal, like 10mV,
to operate. Since we're so close, the S/N ratio was low enough to
detect his inaudible tones!

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

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

Date: 24 Jun 91 05:55:07 GMT
From: usc!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!wuarchive!waikato.ac.nz!comp.vuw.ac.nz!cc-server4.massey.ac.nz![e-mail]
Subject: WANTED: 8530 SCC PC interface circuit & driver
To: [e-mail]

Hi

Yesterday I saw a demo of NOS16 (the network O/S) and it was very
impressive.


SCC CIRCUIT

Unfortunately I don't have a TNC (I've been using PMP - a software TNC)
but I do however have a couple of spare 8530 SCCs and a prototyping card
for the PC.  Does anyone have a circuit that I could use?  Eventually I
could dream one up myself but I've had the SCC and the prototyping card
for the last 2 years - it's a pending project :-)


GENERIC SCC DRIVER

Also, in the NOS 16 documentation it made reference to a GENERIC 8530 SCC
DRIVER - where can I get a copy of this to act as a device driver for the
card once I get it built?


POSTSCRIPT VERSION OF KA9QBGN.ZIP

Is there a postscript version of the beginners notes for this software
so I get bold ...

Thanks
Giovanni - ZL2BOI


--
------------------------------------------------------------------------------
Giovanni Moretti, Computer Science Dept, Massey University, Palmerston North,
Mail: Internet: [e-mail], Pkt-Radio: ZL2BOI@ZL2TCA | New Zealand
Ph 64 63 69099 x8694,FAX [phone] | QUITTERS NEVER WIN, WINNERS NEVER QUIT
------------------------------------------------------------------------------

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

End of Packet-Radio Digest
******************************
Date: Tue, 25 Jun 91 04:30:04 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Bulk
Subject: Packet-Radio Digest V91 #161
To: packet-radio


Packet-Radio Digest         Tue, 25 Jun 91       Volume 91 : Issue 161

Today's Topics:
            Help needed with HP9816 system
               help PK-87 info
          The 'hidden transmitter' problem. (2 msgs)

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

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

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

Date: 24 Jun 91 20:31:26 GMT
From: sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!uupsi!uhasun!arrlhq![e-mail]
Subject: Help needed with HP9816 system
To: [e-mail]

I've received a plea for help from a school radio club in Warminster, PA.
They've received an HP-9816 computer system as a donation and would
like to use it for packet and for tutorial purposes.  But they are
having trouble getting it all to work.  They really need an "Elmer" to
guide them.  Is there anyone who can help them get their system working,
particularly the serial interface to a packet TNC?

Please email me, I'll put you in direct contact with the school's
club advisor (a ham).

Thanks.
-----
Jon Bloom, KE3Z                     |  [e-mail]
American Radio Relay League         |  uhasun!arrlhq!jbloom
225 Main St.                        |
Newington, CT  06111                |  "This mind intentionally left blank."

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

Date: 24 Jun 91 12:57:39 GMT
From: europa.asd.contel.com!wlbr!lonex.radc.af.mil![e-mail]
Subject: help PK-87 info
To: [e-mail]

I got a PK-87 at a hamfest (used) and it came with no docs.  would someone
be kind enough to send me a copy, or at least a copy of the commands with
syntax so that I can use this unit.

thanks
Buzz Szarek
Box74a RFD#2
Boonville, NY 13309
[e-mail]

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

Date: 24 Jun 91 16:44:18 GMT
From: mvb.saic.com!unogate!orion.oac.uci.edu!usc!rpi!uupsi!uhasun!arrlhq![e-mail]
Subject: The 'hidden transmitter' problem.
To: [e-mail]

In rec.radio.amateur.packet, [e-mail] (Phil R. Karn) writes:
>In article <[e-mail]>, [e-mail] (Gary Coffman) writes:
>|> Data compression
>|> is not used on amateur radio for several reasons right now, mostly regulatory.
>
>Eh? I ship PKZIP and .Z (compressed) files over the air all the time.
>As far as I'm concerned, I'm using a coding scheme the purpose of which is
>to facilitate communication (by reducing the number of bits by 60% or so),
>not to hide the meaning of the communications (the algorithms are public
>and widely available). This makes it perfectly legal.

Not to pick nits, but please note that this is legal only above 30 MHz.
Below that frequency you must be using Baudot (in its regular or AMTOR
flavors) or ASCII.  You can't legally code your information any other
way.  I think this is a dumb rule, but it's a rule none the less.
-----
Jon Bloom, KE3Z                     |  [e-mail]
American Radio Relay League         |  uhasun!arrlhq!jbloom
225 Main St.                        |
Newington, CT  06111                |  "This mind intentionally left blank."

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

Date: 24 Jun 91 21:50:53 GMT
From: mvb.saic.com!unogate!orion.oac.uci.edu!usc!rpi!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!boingo.med.jhu.edu!haven.umd.edu!ni.umd.edu!sayshell.umd.edu![e-mail]
Subject: The 'hidden transmitter' problem.
To: [e-mail]

In article <[e-mail]> [e-mail] (Jon Bloom) writes:

>Not to pick nits, but please note that this is legal only above 30 MHz.
>Below that frequency you must be using Baudot (in its regular or AMTOR
>flavors) or ASCII.  You can't legally code your information any other
>way.  I think this is a dumb rule, but it's a rule none the less.

Who's to say that .ZIP files are not represented as "ASCII"?  Are .EXE
files in "ASCII" format, and thus legal to transmit below 30MHz?  If
not, how about if I uuencode the .EXE (or .ZIP file), and then
transmit the "ASCII" version below 30MHz?

Are we having fun yet?

louie
WA3YMH

"I don't have to worry about this problem, I don't use the `DC' bands."

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

End of Packet-Radio Digest
******************************
Date: Wed, 26 Jun 91 04:30:04 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Bulk
Subject: Packet-Radio Digest V91 #162
To: packet-radio


Packet-Radio Digest         Wed, 26 Jun 91       Volume 91 : Issue 162

Today's Topics:
          The 'hidden transmitter' problem.
        WANTED: 8530 SCC PC interface circuit & driver

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

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

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

Date: 25 Jun 91 11:42:33 GMT
From: wshb![e-mail]
Subject: The 'hidden transmitter' problem.
To: [e-mail]

In article <[e-mail]> [e-mail] (Louis A. Mamakos) writes:
+>Not to pick nits, but please note that this is legal only above 30 MHz.
+>Below that frequency you must be using Baudot (in its regular or AMTOR
+>flavors) or ASCII.  You can't legally code your information any other
+>way.  I think this is a dumb rule, but it's a rule none the less.
+Who's to say that .ZIP files are not represented as "ASCII"?  Are .EXE
+files in "ASCII" format, and thus legal to transmit below 30MHz?  If
+not, how about if I uuencode the .EXE (or .ZIP file), and then
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+transmit the "ASCII" version below 30MHz?


Yes, you can uuencode the file and ship it as ASCII. The problem is that
"ASCII" is only 7 bits.


Michael
--
Michael Batchelor--Systems/Operations Engineer #compliments and complaints
WSHB - An International Broadcast Station of   #   [e-mail]
 The Christian Science Monitor Syndicate, Inc. #technical questions and reports
[e-mail]         [phone] #   [e-mail]

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

Date: 25 Jun 91 17:15:57 GMT
From: mcsun!hp4nl!nikhefk![e-mail]
Subject: WANTED: 8530 SCC PC interface circuit & driver
To: [e-mail]

In article <[e-mail]> [e-mail] (Giovanni Moretti) writes:

>SCC CIRCUIT

>Unfortunately I don't have a TNC (I've been using PMP - a software TNC)
>but I do however have a couple of spare 8530 SCCs and a prototyping card
>for the PC.  Does anyone have a circuit that I could use?  Eventually I
>could dream one up myself but I've had the SCC and the prototyping card
>for the last 2 years - it's a pending project :-)
Look in the proceedings of the 8th Computer Networking Conference (1). You find
the description and schematics of the OptoPcScc board. This is a short IBMPC
interface bord with 2 times 8530. With driver software results this in 4
ports (TNCs)for a single board. You can chain multiple boards to create
a big packet node. All the standard rs232 ports are free for other use.

At many places you could find the file "sccprint.arc" version 5. In this file
is more information and also the schematics in epson format. You could order
printed circuit boards or component packets. (Ask for the current list).

The boards are curent in use with 1200 bauds v202 AFSK modems, 4800 baud HAPN
modems and 9600 baud G3RUH modems. The G3RUH interface isn't yet in the
sccprint.arc file. DD8ED is runing the board at 19200 baud with a modified
G3RUH modem.

>GENERIC SCC DRIVER

>Also, in the NOS 16 documentation it made reference to a GENERIC 8530 SCC
>DRIVER - where can I get a copy of this to act as a device driver for the
>card once I get it built?
PE1CHL has written a very universal SCC driver. You coald find this driver
in his version of NET and in NOS. In the attach you could configurate this
driver for nearly any 8530 board. With PE1CHL version of net, a OptoPcScc
board and a G3RUH modem you could work the Oscar 14 at 9600 baud broadcast.

>Giovanni - ZL2BOI

Henk, PA0HZP, [e-mail]

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

End of Packet-Radio Digest
******************************
Date: Thu, 27 Jun 91 04:30:04 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Bulk
Subject: Packet-Radio Digest V91 #163
To: packet-radio


Packet-Radio Digest         Thu, 27 Jun 91       Volume 91 : Issue 163

Today's Topics:
                 CDMA
      Cheap 'n' Fast (was Re:The 'hidden transmitter' problem.)
            Help needed with HP9816 system
     Internet-AX.25 connections - an available solution (5 msgs)
               PA0GRI NOS version 0604

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

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

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

Date: 25 Jun 91 23:20:39 GMT
From: usc!cs.utexas.edu!asuvax!mcdphx!hrc!gtephx![e-mail]
Subject: CDMA
To: [e-mail]

In article <[e-mail]>, [e-mail] (Paul Wexelblat) writes:
> I am looking for pointers to an elementary description of how
> CDMA works in practice;  I have seen simple example descriptions,

Two references presented at Globecom 90:

  W.C. Y. Lee, "Overview of Cellular CDMA"; also in May 1991 IEEE Transactions
  on Vehicular Technology.

  Gilhousen, Jacobs, Padovani, Viterbi, Weaver, Wheatley: "The Capacity of a Cellular
  CDMA System", also in May 1991 IEEE Trans. on Vehicular Tech. (and Globecom 90).

You may also want to check Lee's book "Mobile Cellular Telecommunications Systems".
I'm not sure if he covers CDMA.

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

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

Date: 26 Jun 91 18:43:02 GMT
From: hpl-opus!hpnmdla![e-mail]
Subject: Cheap 'n' Fast (was Re:The 'hidden transmitter' problem.)
To: [e-mail]

In rec.radio.amateur.packet, [e-mail] (Louis A. Mamakos) writes:

>In article <[e-mail]> [e-mail] (Jon Bloom) writes:

>>Not to pick nits, but please note that this is legal only above 30 MHz.
>>Below that frequency you must be using Baudot (in its regular or AMTOR
>>flavors) or ASCII.  You can't legally code your information any other
>>way.  I think this is a dumb rule, but it's a rule none the less.

>Who's to say that .ZIP files are not represented as "ASCII"?  Are .EXE
>files in "ASCII" format, and thus legal to transmit below 30MHz?  If
>not, how about if I uuencode the .EXE (or .ZIP file), and then
>transmit the "ASCII" version below 30MHz?

You could always convert your .COM or .EXE file to hexadecimal ASCII
characters and send it that way.  It's only a factor of 2 or 3 expansion
in the file size.  :=)

AL N1AL

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

Date: 26 Jun 91 11:23:05 GMT
From: haven.umd.edu!uflorida![e-mail]
Subject: Help needed with HP9816 system
To: [e-mail]

Dear John:
What is an "ELMER"?
Thank you,

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

Date: 26 Jun 91 02:15:30 GMT
From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!samsung!spool.mu.edu!munnari.oz.au!manuel!ccadfa!rodos2![e-mail]
Subject: Internet-AX.25 connections - an available solution
To: [e-mail]

I think I may have found a solution for providing an Internet to local
AX.25 gateway, using nos.

Imagine a nos box with an interface to the Internet (ec0) and ec0
address a.b.c.d, and an interface to a TNC (ax0). Assume that the local
AX.25 IP network is 44.x.y.0, and the nos box also has address 44.x.y.z.

If we do:

    route add 44.x.y/24 ax0
    route add 44/8 ec0

then packets destined to 44.x.y.0 will be passed along ax0, packets
destined for 44.any.thing.else will be sent via ec0, and all other
packets will be dropped, thus ensuring non-Amateurs cannot transmit
via ax0.

The problem is, of course, to route the 44.any.thing.else packets
correctly over the Internet. To do this, we need to know about other
Internet-AX.25 gateways. If there is a remote nos box i.j.k.l gatewaying
stuff to 44.r.s.0, then we add the line

    route add 44.r.s/24 ec0 i.j.k.l

Thus:

    ============== Internet ==============
       |                               |
    a.b.c.d                         i.j.k.l
      and                             and
    44.x.y.z                        44.r.s.t
       |                               |
       V                               V
    44.x.y.0                        44.r.s.0

will each have routes

    route add 44.x.y/24 ax0             route add 44.r.s/24 ax0
    route add 44.r.s/24 ec0 i.j.k.l     route add 44.x.y/24 ec0 a.b.c.d


Comments, criticisms, suggestions to this newsgroup. People interested
in trying this out on a weekend please email me, to exchange the routing
needed as above.

Cheers, Warren vk1xwt

       Warren Toomey VK1XWT, slow kermiting.
      Deep in the bowels of ADFA Comp Science.
  `The key that I thought opened the door doesn't'

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

Date: 26 Jun 91 20:13:21 GMT
From: epic![e-mail]
Subject: Internet-AX.25 connections - an available solution
To: [e-mail]

In article <[e-mail]>, [e-mail] (Warren Toomey) writes:
|> I think I may have found a solution for providing an Internet to local
|> AX.25 gateway, using nos.

Actually, your scheme won't work as proposed because the "real"
Internet doesn't have network 44 in its routing tables.

But never fear; there's a new feature (a couple of months old) called
"ip encapsulation". It can do just what you want.

As the name implies, IP encapsulation places IP datagrams inside other
IP datagrams. For example, I can take an IP datagram between two
network 44 hosts and place that inside an IP datagram with addresses
corresponding to two routers on the "real" internet. This builds a
virtual link in the AMPRNET that consists of a specific path in the
real internet.

Incoming packets addressed to the local host that contain encapsulated
IP datagrams are automatically extracted and rerouted. Outgoing
packets are directed to a "pseudo interface" called "encap". You
specify the de-encapsulation router in the gateway field.

E.g.,

route add [44.64]/16 encap 128.96.160.2

says to take any packets destined for addresses in Northern New Jersey
(44.64) and encapsulate them inside IP datagrams addressed to 128.96.160.2
(my router at home, which sits on both a packet radio channel and the
"real" internet).  Of course, for this to work, my router has to have
a reply path, e.g.,

route add [44.62]/16 encap 192.100.76.2

which encapsulates packets addressed to the Central Virginia segment
of AMPRNET in IP datagrams to emperor.handheld.com (WA4ONG's machine).

This scheme has been working quite well. As more sites appear that have
both radio and Internet connectivity, the Internet could well become
the ultimate packet radio "wormhole".

Phil

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

Date: 26 Jun 91 21:20:33 GMT
From: photon![e-mail]
Subject: Internet-AX.25 connections - an available solution
To: [e-mail]

In article <[e-mail]>, [e-mail] (Phil R. Karn) writes:
[stuff deleted]
|> But never fear; there's a new feature (a couple of months old) called
|> "ip encapsulation". It can do just what you want.
|>

Which version is the "oldest" recommended?  Any of the April versions, or just
May/June?

[details about IP encapsulation deleted]
|> This scheme has been working quite well. As more sites appear that have
|> both radio and Internet connectivity, the Internet could well become
|> the ultimate packet radio "wormhole".
|>
|> Phil

Since (for now) the routing info would have to be static, any thought to
publicizing a list?  I'd be glad to maintain one on an anonymous ftp site.

Willis n5szf
{still waiting on an antenna on our building to get 9600 to the Internet. 8-)}

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

Date: 27 Jun 91 05:26:54 GMT
From: o.gp.cs.cmu.edu!andrew.cmu.edu!<[e-mail]>[e-mail]
Subject: Internet-AX.25 connections - an available solution
To: [e-mail]

I recently wrote some code that makes it possible to encapsulate AX.25
frames in IP (according to RFC-1226) and tunnel them across the Internet
to some other site where they may be sent out on the radio channel again.

In a way, this is actually a superset of the 'encap' feature since by
encapsulating IP datagrams in AX.25 frames, and then encapsulate those
frames in IP one would be able to tunnel IP datagrams between RFC-1226
conformant hosts.

I have included my original message describing this feature below.

Anders  W3/SM0RGV

---------- Forwarded message begins here ----------
Date: Mon, 24 Jun 91 05:42:40 -0400 (EDT)
From: [e-mail]
To: [e-mail]
Subject: AX.25 on top of IP

I have implemented Brians RFC-1226 for transmitting AX.25 frames over
IP in NOS. Apparently nobody else has done it for NOS yet? The code is
pretty simple since parts of it was already there. For instance, the
code for calculating the HDLC checksum was already in the file ppp.c.
(Although I am not perfectly sure that I am generating the right FCS.)

To make the AX.25/IP code more useful I also added a tiny piece of code
that implements crossband digipeating.

Here is how to use it.
Suppose that I am running NOS with the callsign SK0WE-2 on the radio
interface. I want to setup a wormhole with w1xxx.foo.com. I will then
have to type:

    attach axip ai0 256 w1xxx.foo.com sk0we-3

where "ai0" is the name of my new 'wormhole' interface.
"256" is the MTU for AX.25.
"w1xxx.foo.com" is the hostname of my peer.
"sk0we-3" is an optional callsign of this new interface. The crossband
digipeating to my radio interface would not work if I did not specify a
callsign (other than sk0we-2.)

That is all. Assuming that w1xxx has done a corresponding setup, I can
now type
    connect ai0 w1zyx w1xxx-2
and the AX.25 frames will be sent to w1xxx.foo.com, where he will
digipeat them on the w1xxx-2 interface, which hopefully is the 2m port.

As long as both I and w1xxx use different callsigns on the radio and
wormhole ports crossband digipeating is supported.
One of the local TNC users will then be able to type
    Connect w1zyx Via sk0we-3, w1xxx-2

There is also a sequrity feature: The code will ignore AX.25 frames
received from IP hosts that have not previously been enabled with the
"attach axip" command.

The changed source files are available at ucsd.edu as
hamradio/ka9q/incoming/axip.arc.

73, Anders

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

Date: 27 Jun 91 01:15:45 GMT
From: munnari.oz.au!manuel!ccadfa![e-mail]
Subject: Internet-AX.25 connections - an available solution
To: [e-mail]

In aticle <[e-mail]>, by me (Warren Toomey):
> The problem is, of course, to route the 44.any.thing.else packets
> correctly over the Internet.

Which is more of a problem than I thought. I assumed nos, when given

    route add network interface gateway

would use source routing. After playing with it yesterday, it doesn't.

However, Jim KB3KJ mailed me a solution. The latest nos has an encapsulation
function that encapsulates one IP packet in another. Doing

    route add 44.x.y.0/24 encap real.inter.net.host

will wrap all IP packets in another IP packet, with destination
real.inter.net.host. This host must be another nos box, for it to
unwrap the `real' IP packet.

Your gateway/44-address details by email please, I can't wait to try this!

Cheers,
    Warren vk1xwt


       Warren Toomey VK1XWT, slow kermiting.
      Deep in the bowels of ADFA Comp Science.
  `The key that I thought opened the door doesn't'

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

Date: 27 Jun 91 08:40:05 GMT
From: [e-mail]
Subject: PA0GRI NOS version 0604
To: [e-mail]

Hello out there, there are some more problems with the GRI NOS,
When someone is connected to the MBOX, and uses the "G" command, he will
never receive anything untill he breaks with a "^X" !
The same goes for the Net/Rom connect command ?

Let's hope, that Gerard creates a new version, because the GRI NOS version
can do more and is nicer to work with then the G1EMM version 1.6, witch I am
using now.

Bye Bye and greetings from Holland
--
     All the best,
           Ron.
           +----------------------------------+
           | Ron Bakker PA0BAK [44.137.28.21] |
           | Cureestraat 7                    |
           | 4697BT Sint-Annaland (Tholen)    |
           | Tel. [phone]                  |
           +----------------------------------+

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

End of Packet-Radio Digest
******************************
Date: Fri, 28 Jun 91 04:30:04 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Bulk
Subject: Packet-Radio Digest V91 #164
To: packet-radio


Packet-Radio Digest         Fri, 28 Jun 91       Volume 91 : Issue 164

Today's Topics:
            Help: Traveling Packet/Routing
           packet<->internet gateway usage
                Sites needed.
        WANTED: 8530 SCC PC interface circuit & driver

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

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

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

Date: 27 Jun 91 14:53:17 GMT
From: hpcc05!hpcuhb!hpindda![e-mail]
Subject: Help: Traveling Packet/Routing
To: [e-mail]

I am leaving for the east coast in 2 days, and know I should have posted
this question sooner, but... here goes:

In San Jose here, I am registered at N6LDL as my home BBS.

I travel with a HandiPacket configured as AA6IY-10.
This weekend I will be away and would like to exchange mail with friends
back here, so I am planning to 'find' a BBS I can hit in New York and
route mail back to N6LDL.CA.

Question: What addresss can I forward to my friends to route mail back to me?

If they use [e-mail], will they get to me?
Will I need to register at that guest BBS telling it my home BBS is that
   guest's BBS? Do I need to un-register at N6LDL (though I don't
   know how to do that)?
If I tell the guest BBS that my home BBS is N6LDL.CA will mail be turned
around back to CA before I get it?

Any help would be appreciated.
Tnx,
Gene

+----------------------------------------------------------------------------+
|Gene Marshall                        /-/-/          email: [e-mail] |
|Hewlett Packard Co., MS 43L9           |                  Tel: [phone] |
|Information Networks Division          |                  Fax: [phone] |
|19420 Homestead Road.                  |              [e-mail] |
|Cupertino, CA 95014                   /|\       Bay Area: 147.39+ / 223.96- |
+----------------------------------------------------------------------------+

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

Date: 27 Jun 91 15:46:57 GMT
From: agate!spool.mu.edu!caen!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!pitt!w2xo![e-mail]
Subject: packet<->internet gateway usage
To: [e-mail]

For those of you using my packet<->internet/uucp gateway, a few
little things...(grouch, complain, whimper, whine 8-)  ).

1. Please include the packet bbs style "Hierarchial address" when
mailing. My data base is limited and since accessing a nework
database at 1200 baud is no treat, this isn't practical. If you
are not familiar with the "H addressing" concept, it is just
plain old source routing (source specs the route). A typical
first line of the message would look like:

SP [e-mail]<K2ZZZ

Where:
    k7XXX is the destination station or address
    K7YYY is the destination bbs
    ".AZ.USA.NA" means "Arizona, USA, North America".
    K2ZZZ is the originating station.

However 8-) ... the way my stuff parses, you can't mail to
just ".AZ" . If you are going to shorten the address and
assume "USA and North America", that's fine, but I parse
for ".AZ." for reasons of possible conflicts with other names,
so you have to put on the trailing "dot".

3. If you would like your mail delivered *from* packet radio to
your internet account, then please e-mail me with your
internet address. The only way I have to do this is to build
a table of "MX Records", so to speak, and I need your address
to do this.

I will post my list of ham call->internet addresses on here when
I get a few more of them for others that might want the list.

4. My apologies for the non-lightning speed of the service.
I have to scan all the mail going out since the big
brew-ha-ha about the FCC holding packet bbses liable for mail
*content*, so sometimes I get tied up in other things....and
so it goes. I usually do this twice a day, so it's not internet
speed, but it's usable..

73
Jim, W2XO

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

Date: 28 Jun 91 05:23:46 GMT
From: [e-mail]
Subject: Sites needed.
To: [e-mail]

Greetings -
I run a fairly successful wormhole from Southern California to
the Chicago area.  It's carried on a 9600 baud async statistical
mux channel used by my company, MICOM.  The data communications
link is provided by the computer room manager (me!).
The western end is linked to the 6m, 4800 baud trunk that runs
from Ventura County east to the Arizona/New Mexico border.
The eastern end emerges on a 1.2 GHZ/9600 baud trunk that
in turn links to the CAPRA Packeten packet switch.
I run data comm links to other cities, and am interested in
setting up wormholes to one or more of those sites.
Those possible sites are:
Newton, Mass
Marietta, Georgia
St. Louis Missouri
Hackensack, New Jersey
Santa Clara, California

Equipment requirements are : some TNC/modem combination capable
of running at a moderately high data rate on the RF link.  The
radio should run at AT LEAST 2meters or higher frequency.  This is
because the antenna will probably need to be an indoor or window
antenna, and is necessarily limited in size.

The node on that end would be linked to a G8BPQ packet switch in
Southern California, which would allow communications between all
the linked nodes ("wormnodes"? "nodeholes"?).

If you or your group think you can provide equipment that meets
the requirements, please let me know, and I can provide a contact
name in the office closest to your area.  You can then arrange
for a site survey to determine if our office is suitable as an
RF site.  (That's the caveat: I have never visited the
offices, and don't know how inconvenient they are for antennae.)

I've been trying to get interest in this project for several years,
and CAPRA is the only group that's come through so far.

Looking forward to hearing from someone!

73, Orv  WB6WEY @ W8AKF   44.6.0.128

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

Date: 26 Jun 91 16:26:33 GMT
From: elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!convex!mic!letni!rwsys!kf5iw!k5qwb![e-mail]
Subject: WANTED: 8530 SCC PC interface circuit & driver
To: [e-mail]

[e-mail] (Henk Peek) writes:

> At many places you could find the file "sccprint.arc" version 5. In this file
> is more information and also the schematics in epson format. You could order
> printed circuit boards or component packets. (Ask for the current list).

I'm interested in this info too. Ftp is difficult from here. Anyone who
could help me please e-mail.

Thanks in advance,


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

73,              [e-mail]
Lyn Kennedy      K5QWB @ N5LDD.#NTX.TX.US.NA
         P.O. Box 5133, Ovilla, TX, USA 75154

-------------- "We have met the enemy and he is us."  Pogo --------------

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

End of Packet-Radio Digest
******************************
Date: Sat, 29 Jun 91 04:30:02 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Bulk
Subject: Packet-Radio Digest V91 #165
To: packet-radio


Packet-Radio Digest         Sat, 29 Jun 91       Volume 91 : Issue 165

Today's Topics:
          INFO wanted on 9600 baud + packet
             Packet in *my* city?
              z8530 SunOS driver wanted

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

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

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

Date: 28 Jun 91 23:19:58 GMT
From: infopiz!lupine!hansen![e-mail]
Subject: INFO wanted on 9600 baud + packet
To: [e-mail]

We are putting together a new network on 1.2 GHz and one of the things we
want to do is to run high speed packet.

We have just completed a group buy of Yeasu FT-912R (1.2 GHz) and we would like to put them on high speed packet.  So I have the following questions:

    - What modems are available for 9600 baud packet?

    - What is good bad about each of these modems?

    - What do we have to do to the radio to make it work at 9600 baud
        (specific instructions would be great! :-)


Thanks in advance for your help!


DE KJ6NN

Phil


EMAIL:  [e-mail]
PACKET: KJ6NN @ N6IIU-1
    & Northern California DX packet cluster
Phone:  [phone]  <-- 24 hour line, w/ answer machine

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

Date: 29 Jun 91 03:27:01 GMT
From: swrinde!sdd.hp.com!caen!kuhub.cc.ukans.edu![e-mail]
Subject: Packet in *my* city?
To: [e-mail]

What's the easiest way to tell if there is enough packet traffic
in my area to warrant getting involved in it?  I live about
45 miles from Kansas City, which should have atleast some packet
users.  Am I close enough to be able to link with them?  What
would kind of power would I need from a 2 meter radio to get to
them?

Thanks for any help,
Chris


==============================================================================
 [e-mail]              Chris Whittenburg, Univ. of Kansas
 [e-mail]                        Electrical Engineering
==============================================================================

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

Date: 28 Jun 91 21:24:29 GMT
From: usc!cs.utexas.edu!utgpu!cunews!bnrgate!bigsur![e-mail]
Subject: z8530 SunOS driver wanted
To: [e-mail]

I would like to use the serial ports on the back of a
sparcStation to connect to some equipment that expects
a proprietary protocol on top of SDLC.

In an ideal world, I would open a file descriptor on /dev/sdlc
and read or write sdlc 'frames'.

SunOS does not provide such a low-level facility (even under
sunLink X.25) so I am looking for kernel code which either
implements the above or gives me enough information to attempt
my own driver.

Any help would be appreciated,

...Maarten


--
//include1 pgm=disclaimer,parm='my opinions only'
Maarten Koning | Internet:  [e-mail]        | Phone: [phone]
BNR Ltd.       |     UUCP:  [e-mail]   | FAX:   [phone]

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

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