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

Text File | 1993-12-31 | 221.0 KB | 5,511 lines

Sun,  1 Dec 91 04:30:06 PST
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 #311
To: packet-radio


Packet-Radio Digest         Sun,  1 Dec 91       Volume 91 : Issue 311

Today's Topics:
         Mac's, PMP, Baycom, SoftPC ! Any idea's ??!!
               Ottawa PI Board
                 packet radio
                 UNSUBSCRIBE
 Why is the AX.25 address field needed for TCP/IP networks? (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: 30 Nov 91 16:34:17 GMT
From: swrinde!cs.utexas.edu!wupost!darwin.sura.net!Sirius.dfn.de!ira.uka.de!smurf.sub.org![e-mail]
Subject: Mac's, PMP, Baycom, SoftPC ! Any idea's ??!!
To: [e-mail]

In rec.radio.amateur.packet, article <[e-mail]>,
  [e-mail] (Bill Coleman) writes:
< In article <[e-mail]>, [e-mail] (Rob Mayfield, vk5xxx@vk5xip.#sa.aus.oc) writes:
< > This query origionated from VK5GU, but it got me thinking ....
< >
< > Is there any software in existance that provides Baycom/PMP facilities on
< > the mac ?? I realise that the mac serial port may not lend itself to this
< > sort of software as well as the pc ......
<
< Actually, that's not entirely true. Unlike the PC, the Mac has a USART
< chip used for serial I/O. The PC uses UART chips, which are restricted to
< running asynchronously. The Mac 8530 serial chip can run synchronously,
< and could conceivably run the AX.25 HDLC directly from the chip.
<
It can. I wrote some pieces of code to play with that stuff some time ago.
However..:

< Unfortunately, also unlike the PC, the Mac has a built in serial driver
< that does not speak synchronous. You can do synchronous, but only if you
< write your own driver and bypass the build-in serial driver. This is
< considered exceedinly bad form in the Macintosh community, and it won't
< work correctly on Macintosh IIfx or Quadra 900 computers without disabling
< the serial port IOPs (I/O Processors).
<
"Bad form"? Make that "severe compatibility problems". Besides the IOP
problem, there's no longer a really standardized way to make sure that the
serial port in question is free, or how to mark it as busy.
On the other hand, the previously semi-documented ways to do this might still
work for the foreseeable future, so it might be worth looking into.

Where can I get documentation for the AX.25 stuff? FTP anywhence?

< > Also, has ayone played with running the above pc packages on a mac using
< > SoftPC ??
<
< Interesting idea. There's no telling how complete the SoftPC hardware emulation
< is. The only way to know if this will work is simply to try it.
<
The emulation should work. However, there's no good way to get the packets
back to the Mac side and in to MacTCP (for instance).

--
Matthias Urlichs  --  [e-mail] -- [e-mail]   /(o\
Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- Germany  --  [phone]     \o)/

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

Date: 1 Dec 91 03:42:17 GMT
From: mcdhup!wb2sjz![e-mail]
Subject: Ottawa PI Board
To: [e-mail]

I'm using an Ottawa PI board with a GRAPES 56k modem and a 33MHZ 386.
Everything works fine when the 386 is running at 16MHZ. At 33MHZ incomming
data appears garbled. Looks like a timing problem. Has anyone else
experienced this problems ?  Wonder if replacing the 8530 with a 85C30
would help ? Anyone have any ideas ? Would appreciate any help.

Thanks, George WB2SJZ
--
          /////////
         (  o   o )        POLI (Packeteers of Long Island)
       ---uuu-----u----uuu---

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

Date: 30 Nov 91 06:25:55 GMT
From: dog.ee.lbl.gov!pasteur!agate!spool.mu.edu!sol.ctr.columbia.edu!hamblin.math.byu.edu![e-mail]
Subject: packet radio
To: [e-mail]

I would like to start a packet radio w/ using a dummy term, vt100 or
ADDS or...something.
Could anyone tell me what exactly needorder to run?
Pretend that I don't nothing since I don't wanna miss athing.

Thanks
--
                     _   /|
Tatsuya                                  \'o.O'
[e-mail]             =(___)=
EMT:901006  Ham: N7UQJ                      U

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

Date: 1 Dec 91 04:10:21 GMT
From: [e-mail]
Subject: UNSUBSCRIBE
To: [e-mail]

UNSUBSCRIBE

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

Date: 30 Nov 91 08:19:49 GMT
From: qualcom.qualcomm.com!chicago.qualcomm.com![e-mail]
Subject: Why is the AX.25 address field needed for TCP/IP networks?
To: [e-mail]

In article <ssw.691355995@ogre> [e-mail] (Steve Wallace) writes:
>Just reading the AX.25 standard and I see that there is a
>variable length address field to include all hops the packet was
>routed to.  Is this field used when encapsulating tcp/ip?  If so,
>why?  It seem to me that you could leave these field blank when
>using tcp/ip or am I missing something.

The AX.25 level addressing serves a separate and necessary function
even when carrying TCP/IP packets. It's directly analogous to the
Ethernet level addressing that's used on LANs even when carrying
TCP/IP packets.  The Ethernet or AX.25 level addressing is for the
link layer; it is used by link layer devices. The IP level addressing
is for the Internet layer; it is used by Internet routers and hosts.
As an IP datagram propagates through the Internet it may temporarily
be encapsulated in a wide variety of link level protocols, possibly
(but not necessarily) including AX.25 or Ethernet. But the IP header's
addresses remain the same until the datagram reaches its ultimate
destination.

Phil

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

Date: 30 Nov 91 23:48:28 GMT
From: [e-mail]
Subject: Why is the AX.25 address field needed for TCP/IP networks?
To: [e-mail]

The 'from' and 'to' fields in the AX.25 packet are the "hardware" or
"link" level address, similar to the 6-byte Ethernet address.  The
optional 'digipeater' fields aren't needed if you're not routing via
digipeaters (essentially, a digipeater is a link-level store-and-forward
packet regenerating relay), and are required if you are.

The hardware address (station callsign and SSID) is often the same as the
hostname, which can be confusing.  They are in fact different entities
that are only coincidently the same string of bytes.

Regrettably, the AX.25 packet protocol is required by some
unenlightened governments.
    - Brian

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

Date: 27 Nov 91 18:20:55 GMT
From: qualcom.qualcomm.com!qualcom.qualcomm.com![e-mail]
To: [e-mail]

References <[e-mail]>, <[e-mail]>, <[e-mail]>
Reply-To : [e-mail]
Subject : Re: Digital Packet Repeater Info Wanted

In article <[e-mail]>, [e-mail] (Gary Coffman) writes:
|> I think you missed the point. The "metric" is going to require knowledge
|> of the number of stations captured by "each" hop of a proposed path.
|> Knowing only the cost of the first hop is insufficient. [...]

All this is true, but it is also true for ANY routing algorithm,
regardless of the metric chosen. The choice of routing algorithm and
the choice of a metric for that algorithm are separate issues.  All I
am advocating is the use of the "captured receiver count" as the
metric at each hop instead of fixed values (e.g., 1).

NET/WRONG and RIP are both examples of "distance-vector" routing algorithms
where the metrics for the downstream links are folded into a composite
metric for each destination in a given node's routing table. The problem
with distance-vector algorithms is that they often form loops when links
change (particularly when they disappear or the metrics increase rapidly).

Link-state algorithms (e.g., RSPF) are much better at adapting to rapid
network changes. I would recommend their use in amateur packet radio
even if the metrics were not based on a "captured receiver count".

Similarly, even if a distance-vector routing algorithm is used, I would
recommend using the "captured receiver count" as the metric for each link.
Nothing *requires* you to update this count every second; to keep the
network overhead within limits, you could easily say that you'll do
updates every, say, 10 minutes. This would be less optimal (in terms of
choosing the routes with the least impact on active stations) but it *would*
take care of the common case where nodes become and remain idle for long
periods (> 10 minutes).

Phil

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

Date: 1 Dec 91 04:08:25 GMT
From: sdd.hp.com!news.cs.indiana.edu!cica!ogre![e-mail]
To: [e-mail]

References <ssw.691355995@ogre>, <[e-mail]>, <[e-mail]>

Subject : Re: Why is the AX.25 address field needed for TCP/IP networks?

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

>The 'from' and 'to' fields in the AX.25 packet are the "hardware" or
>"link" level address, similar to the 6-byte Ethernet address.  The
>optional 'digipeater' fields aren't needed if you're not routing via
>digipeaters (essentially, a digipeater is a link-level store-and-forward
>packet regenerating relay), and are required if you are.

That's the piece I was missing (I didn't know about digipeaters).
Why not use spanning tree?

--
====================================================================
Steven Wallace                |  [e-mail] (internet)
Manager Network Operations    |  wallaces@iubacs          (bitnet)
Indiana University            |  (812) 855 - 0960         (voice)
====================================================================

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

Date: 30 Nov 91 08:09:17 GMT
From: qualcom.qualcomm.com!chicago.qualcomm.com![e-mail]
To: [e-mail]

References <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject : Re: Digital Packet Repeater Info Wanted

In article <[e-mail]> [e-mail] (Gary Coffman) writes:
>I'm calling a "passive" station one that currently doesn't have any
>traffic for the net.

Correct. The best way to predict those stations that will not have any
traffic for the net in the near future is to look at those stations that
have not had any traffic for the net in the recent past. This is a
time-honored technique in computer science (e.g., page replacement
algorithms in virtual memory systems).

I am proposing a similar technique in my implicit collision-avoidance
channel access technique. If the channel has been idle for "some"
period of time (i.e., you haven't heard anyone sending data or returning
ACKs to anyone else), then you can assume it is going to remain idle
(and available for your use) long enough for you to send your traffic.

Remember that in all these situations it is not necessary to be
correct all the time. It is sufficient to be correct only 'most' of
the time. All you lose by being wrong is performance, and hopefully
you gain more than you lose by being right more often than wrong.

Phil

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

End of Packet-Radio Digest V91 #311
******************************
Date: Mon,  2 Dec 91 04:30:03 PST
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 #312
To: packet-radio


Packet-Radio Digest         Mon,  2 Dec 91       Volume 91 : Issue 312

Today's Topics:
               Ottawa PI Board

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

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

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

Date: 2 Dec 91 04:03:04 GMT
From: mcdhup!wb2sjc![e-mail]
Subject: Ottawa PI Board
To: [e-mail]

I'm using an Ottawa PI board with a GRAPES 56k modem and a 33MHZ 386.
Everything works fine when the 386 is running at 16MHZ. At 33MHZ incomming
data appears garbled. Looks like a timing problem. Has anyone else
experienced this problems ?  Wonder if replacing the 8530 with a 85C30
would help ? Anyone have any ideas ? Would appreciate any help.

Thanks, George

          /////////
         (  o   o )        Long Island Amateur TCP/IP Packet Radio Network
       ---uuu-----u----uuu---

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

End of Packet-Radio Digest V91 #312
******************************
Date: Tue,  3 Dec 91 04:30:05 PST
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 #313
To: packet-radio


Packet-Radio Digest         Tue,  3 Dec 91       Volume 91 : Issue 313

Today's Topics:
              BBS Authentication
           Help connecting TH 215 to TNC 1
                 Info needed
              Packet radio FAQ?

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

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

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

Date: 2 Dec 91 16:32:13 GMT
From: pa.dec.com!jrdzzz.jrd.dec.com!tkou02.enet.dec.com!nntpd.lkg.dec.com![e-mail]
Subject: BBS Authentication
To: [e-mail]

In article <[e-mail]>, [e-mail] (Roy Engehausen) writes:
|>
|>I am experimenting with various ways of BBS to BBS authentication.
|>Best thing I have come up with is that "A" sends a random number, "B"
|>does an arithmetic operation on the result and send the result back,
|>"A" then compares the distant answer with the local answer.  This
|>exchange is carried out encrypted using a key that both stations have
|>agreed on.  The bad this is that this has to occur both ways.
|>
|>Anyone with ideas is welcome to send them to me.
|>
|>Roy, AA4RE
|>enge @ almaden.ibm.com
|>

That sound plausible.  Whether it's actually ok depends on detail you
haven't stated:
1. The probability that A reuses its "random number" (thus allowing "replay"
   attack).
2. The means by which the key is agreed on.  What you're actually doing is
   verifying that B holds the same key as A.  That may or may not have
   anything to do with authenticating B -- it depends on whether nodes other
   than B could succeed in participating in the key agreement process.

    paul, ni1d

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

Date: 2 Dec 91 18:11:52 GMT
From: elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!malgudi.oar.net!yfn.ysu.edu!ysub![e-mail]
Subject: Help connecting TH 215 to TNC 1
To: [e-mail]

I have a Tuscon Tapr Tnc 1 / Tnc 2 that I want to put on the air with a
Kenwood TH 215. Question: I have 3 wirs from the tnc one for ptt one for
audio amd one for ground. The mic jack on the kenwood has two one for
ptt and one for audio. What if anything do I do with the ground wire???
any light on the matter would be apprecated......
73
de N8LGV sk

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

Date: 2 Dec 91 13:39:08 GMT
From: elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!rpi!ghost.dsi.unimi.it!sabrina!alessia![e-mail]
Subject: Info needed
To: [e-mail]

Hi,

I'm interesterd in packet radio and I'm going to buy a
tranceiver, particularly the YAESU FT480R.
Does someone use this tranceiver or know something
about its affidability (both in positive or negative).

Thanx in advance.

            Gianluca Moro
            [e-mail]

P.S. E-mail preferred.

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

Date: 3 Dec 91 03:03:21 GMT
From: elroy.jpl.nasa.gov!sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!sarah!newserve!bingvaxu.cc.binghamton.edu![e-mail]
Subject: Packet radio FAQ?
To: [e-mail]

...is there an faq for packet-radio questions?  ...i'm a former ham
who's now involved w/computers in the field of archaeology...someone
asked me to consult on a project involving linking computers hundreds
of miles apart in Mexico (he's since left the project), & i think
packet radio's the answer, but i know next to nothing about it...

...so if there is no FAQ posting, how `bout someone providing a short
description of what's involved...?...   ...tnx...

--
***************************************************************************
"There is nothing either good or bad,  |  allen h. lutins
but thinking makes it so."           |  [e-mail]
        Shakespeare (Hamlet II:2)  |  [e-mail]

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

End of Packet-Radio Digest V91 #313
******************************
Date: Wed,  4 Dec 91 04:30:03 PST
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 #314
To: packet-radio


Packet-Radio Digest         Wed,  4 Dec 91       Volume 91 : Issue 314

Today's Topics:
            Packet with Palmtop ?

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 Dec 91 07:21:30 GMT
From: elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!wupost!darwin.sura.net!haven.umd.edu!wam.umd.edu![e-mail]
Subject: Packet with Palmtop ?
To: [e-mail]

I have been using an HP48SX as a terminal for portable packet radio
operations.  It has a built in RS-232 port, and terminal software
is available via anonymous ftp.

All I need to do now is find a good gell-cell and build a charger
(buying 2 lantern batteries every time I use the system is too costly).

-Tom N3HAU
member W3EAX University of Maryland Amateur Radio Association

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

End of Packet-Radio Digest V91 #314
******************************
Date: Thu,  5 Dec 91 04:30:04 PST
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 #315
To: packet-radio


Packet-Radio Digest         Thu,  5 Dec 91       Volume 91 : Issue 315

Today's Topics:
              BBS Authentication
    Microsat Hams in the San Francisco Bay Area -- are there any?
           QSL inf 4 u5mir packet contact request.

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 Dec 91 00:11:58 GMT
From: qualcom.qualcomm.com!qualcom.qualcomm.com![e-mail]
Subject: BBS Authentication
To: [e-mail]

In article <[e-mail]>, [e-mail] (Paul Koning) writes:
|>
|> In article <[e-mail]>, [e-mail] (Roy Engehausen) writes:
|> |>
|> |>I am experimenting with various ways of BBS to BBS authentication.
|> |>Best thing I have come up with is that "A" sends a random number, "B"
|> |>does an arithmetic operation on the result and send the result back,
|> |>"A" then compares the distant answer with the local answer.  [...]
|> That sound plausible.  Whether it's actually ok depends on detail you
|> haven't stated:
|> 1. The probability that A reuses its "random number" (thus allowing "replay"
|>    attack).
|> 2. The means by which the key is agreed on.  What you're actually doing is
|>    verifying that B holds the same key as A.  That may or may not have
|>    anything to do with authenticating B -- it depends on whether nodes other
|>    than B could succeed in participating in the key agreement process.

This scheme is also susceptible to hijacking. That is, you wait for a
legitimate BBS-to-BBS contact to start, then you jump on the channel
with higher power and take over the connection.

To thwart hijacking, you need to authenticate EACH AND EVERY PACKET.
This is not as hard as it sounds. Just append the secret key to the
contents of the packet and run the combination through a secure hash
function such as MD-4 or MD-5. Then append the resulting hash code to
the data packet. The receiver performs the same operation on the
incoming data and compares its hash code with the one included in the
packet.  If they match, then the packet has not been corrupted
(maliciously or otherwise) in transit. It might, however, be a
duplicate, so it is important to include a date-time stamp in the data
field of each packet, and to discard received packets that are older
than a certain limit.

MD-4 and MD-5 are in the public domain. Source code to implement them
can be obtained by anonymous FTP from rsa.com. They're reasonably
fast, even on PCs.

The bigger (MUCH bigger) problem is the one of key management that is
only glossed over in point #2. That's why public-key cryptosystems
such as RSA are so important in practice, even when the actual
encrypting or signing of messages may be done with non-public-key
algorithms such as DES. RSA is extremely useful as the mechanism by
which DES keys are distributed.

Phil

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

Date: 3 Dec 91 17:19:38 GMT
From: tcsi.com!taxman![e-mail]
Subject: Microsat Hams in the San Francisco Bay Area -- are there any?
To: [e-mail]

A Friend of mine who will be visiting me over the Christmas is
interested in meeting some hams who have accessed the microsat
satellites. He has been experimenting with this but has been having
some trouble getting his system to work properly. He would love to
have a chat with anyone who has been more successful.

Cheers,
-Graham

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

Date: 3 Dec 91 16:46:48 GMT
From: telesoft![e-mail]
Subject: QSL inf 4 u5mir packet contact request.
To: [e-mail]

In <[e-mail]> [e-mail] (Rob Mayfield, vk5xxx@vk5xip.#sa.aus.oc) writes:

>Can anyone help me with the qsl address, personal name, and normal callsign
>when earthbound, for U5MIR.

U5MIR is Sergej Krikalev.

Some others are:
    U1MIR Vladimir Titov
    U2MIR Musa Manarov
    U3MIR Valerij Polyakov
    U4MIR Aleksandr Volkov

Here's the QSL info I have (worked for me).  It is a bit old and refers
to the previous crew, U2MIR and U9MIR, but the other info should still
be correct.

% Both voice and packet QSO's made by Soviet spase station "MIR"
% current crew (U2MIR and U9MIR) can be confirmed by UW3AX. The
% address is: Boris Stepanov, P.O.Box 679, 107207 Moscow, USSR.
% For direct reply please enclose SAE plus IRC's or equivalent.
% Please also have patience: no QSO comfirmattion can be made
% before current crew will be back on the Earth (the expected
% month is May).
%
% All QSL's for previous U-MIR activity has been filled and sent
% before March last year. This aplies only for those who sent QSL
% to U-MIR. They were only some 25 % of logged contacts. UW3AX has
% U-MIR logs for previous missions in hands and can confirm QSO's.
%
% 73 de Boris Stepanov, UW3AX
%
% 11.02.91

>Are accurate logs kept, or would a trace of the
>session help in confirming contact ?

I think logs are kept, I just sent them a standard QSL card will all
the regular QSL info (time/date/freq/mode...).  I even got my card before
Musa was back on the ground!

73,
--GaryM
--
Gary Morris                  Internet: [e-mail]
KK6YB                        UUCP:     ucsd!telesoft!garym
TeleSoft, San Diego, CA      Phone:    [phone]

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

End of Packet-Radio Digest V91 #315
******************************
Date: Sat,  7 Dec 91 04:30:04 PST
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 #316
To: packet-radio


Packet-Radio Digest         Sat,  7 Dec 91       Volume 91 : Issue 316

Today's Topics:
             Current Status of Packet FAQ
             DARPA PROJECT SURAN
               Ottawa PI Board
        PK232 PC-PACKRATT-like Unix Pgm (???)

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 Dec 91 04:20:51 GMT
From: elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!hobbes.physics.uiowa.edu!moe.ksu.ksu.edu!matt.ksu.ksu.edu![e-mail]
Subject: Current Status of Packet FAQ
To: [e-mail]

I have reposted the last revision of the Amateur Packet Radio
Frequently Asked Questions (FAQ) list.

I am currently working on a new section for the FAQ that will include
books, magazines, and organizations dealing with packet radio.  Any
suggestions for this section are welcome.

Also, I have a good deal of miscellaneous information that will
be incorporated as well.

-Steve Schallehn  KB0AGD

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

Date: 7 Dec 91 07:03:29 GMT
From: [e-mail]
Subject: DARPA PROJECT SURAN
To: [e-mail]

In Recent messages Phil Karn mentioned DARPA project SURAN. I presume
that SURAN concerns either: packet radio, or computer networking in
general, but I would like to find out more. Please could someone point
me in the right direction - perhaps even a contact at DARPA? I have
interests in both Systems Engineering and Assessment and it sounds from
what was said that a good deal of modelling had been done in support of
the project.

Thanks in advance

Ron Collins
G6VUG

[e-mail]    INTERNET

100015,2657                   Compuserve

[e-mail]          AMPRNET

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

Date: 6 Dec 91 20:45:44 GMT
From: [e-mail]
Subject: Ottawa PI Board
To: [e-mail]

Sorry to post this, but mail to wb2sjc goes boinnnnnng.

>I'm using an Ottawa PI board with a GRAPES 56k modem and a 33MHZ 386.
>Everything works fine when the 386 is running at 16MHZ. At 33MHZ incomming
>data appears garbled. Looks like a timing problem. Has anyone else
>experienced this problems ?  Wonder if replacing the 8530 with a 85C30
>would help ? Anyone have any ideas ? Would appreciate any help.

George, please provide some more details.  Does the bus on your machine
always run at 8 MHz, or is there a possibility that it runs faster when
the cpu is running at 33 MHz?  (Sometimes different bus speeds can be set
in the cmos bios setup).  Check your board and make sure it is an 8530A
part (probably marked 8530APS)... it should be, but you never know.  When
you say garbled, do you mean that the frames don't look right when you
trace the PI interface?  Are there checksum errors?  How about sending a
copy of the trace?  While you're at it, include a copy of your autoexec.net
file.  What version of NOS are you using?  Changing processor speed while
NOS is running could confuse the PI driver, so you should do it before
starting up NOS.

Standing by to hear from you...

Barry VE3JF

---
Barry McLarnon                  |  Internet: [e-mail]
Communications Research Center  |  AMPRnet: [e-mail]
Ottawa, Canada  K2H 8S2         |  PBBSnet: ve3jf@ve3jf.#eon.on.can

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

Date: 4 Dec 91 03:06:07 GMT
From: mjbtn![e-mail]
Subject: PK232 PC-PACKRATT-like Unix Pgm (???)
To: [e-mail]

Hello,

This may have been asked before, but has anyone written or knows of a unix
or xenix program that talks to the AEA PK232 TNC via the serial port much
the name way as PC-PACKRATT or PacketTerm (etc, etc)?  This would basically
be some program that send/receives stuff to/from the PK232 'cmd:' mode (I
suppose).  I am not so much interested in doing packet this way as I have
KA9Q Net for Unix running fine.  What I would like to do is have the ability
to use the other PK232 stuff (AMTOR, etc) via a controlled environment (say
under CURSES).  Operating from the 'cmd:' prompt is OK, but....  :-)

Thanks for any input.

73's,

Mark.

--
Mark J. Bailey, N4XHX                              _______/====X11====\_______
USMAIL: 511 Memorial Blvd., Murfreesboro, TN 37129 |         JobSoft         |
VOICE:  [phone]                            | Design & Development Co.|
UUCP:   ...!uunet!mjbtn!mjb, ...!raider!mjbtn!mjb  |  Murfreesboro, TN  USA  |
DOMAIN: [e-mail]      CIS: 76314,160  ---------------------------
<KA9Q-UNIX-USERS Mailing List-Subscribe: [e-mail]>

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

End of Packet-Radio Digest V91 #316
******************************
Date: Sun,  8 Dec 91 04:30:03 PST
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 #317
To: packet-radio


Packet-Radio Digest         Sun,  8 Dec 91       Volume 91 : Issue 317

Today's Topics:
             DARPA PROJECT SURAN
          Kenwood TS-711/811 and direct FSK
          Midwest Packet Conference Feb 8th

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 Dec 91 22:53:48 GMT
From: qualcom.qualcomm.com!chicago.qualcomm.com![e-mail]
Subject: DARPA PROJECT SURAN
To: [e-mail]

In article <[e-mail]> [e-mail] (Ron Collins) writes:
>In Recent messages Phil Karn mentioned DARPA project SURAN. I presume
>that SURAN concerns either: packet radio, or computer networking in
>general, but I would like to find out more.

SURAN = Survivable Radio Network, a BBN project (under DARPA
sponsorship).  SURAN has been around quite some time, and they have
made quite a contribution to the literature. Probably the most
accessible collection of their work can be found in the January 1987
issue of Proceedings of the IEEE, a special issue on packet radio
networks.

Although SURAN has some special military requirements (e.g., jamming
resistance) I think it has developed quite a few ideas that may have
practical application to amateur packet radio. Automatic power control,
for one...

Phil

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

Date: 4 Dec 91 15:14:45 GMT
From: elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!wupost!spool.mu.edu!cs.umn.edu!uc.msc.edu!nachos.SSESCO.com![e-mail]
Subject: Kenwood TS-711/811 and direct FSK
To: [e-mail]

Someone sent me email asking for modifications for these radios for use
at 9600 bps.  I lost the email message due to a system failure but would
like to reply.  I have documentation from DB2OS and ZL1TRE who are using
these radios with G3RUH modems.  I'll email this info to whoever needs
it.

I'd like to find someone who's using an AEA DSP-2232 or DSP-12 with these
radios...  I'm not having much luck with my configuration.

Chris

--
Chris Elmquist, N0JCF
[e-mail]                73267,[e-mail]
[e-mail]             [phone]@work (8am-5pm CST6CDT)

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

Date: 4 Dec 91 23:19:26 GMT
From: bloom-beacon!micro-heart-of-gold.mit.edu!wupost!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!src.honeywell.com!skyler.mavd.honeywell.com![e-mail]
Subject: Midwest Packet Conference Feb 8th
To: [e-mail]

The TwinsLAN Amateur Radio Club is sponsoring the Midwest Packet Radio
Conference on Saturday, February 8th, from Noon until 9 PM.  Since this date
coincides with a large local hamfest in the Minneapolis/St. Paul area it is
hoped that packeteers from Minnesota, Iowa, North and South Dakota, Wisconsin,
Manitoba and Ontario will attend.

The conference will be held at the Skywood Inn, 5201 Central Ave. NE, in
Fridley (the SE corner of the intersection of I-694 and Hwy 65).  During
most of the conference there will be two seperate programs presented - one
geared for beginners and another for "experienced" packeteers.  A dinner is
included in the conference ticket and there will be a break from 5 - 6:30 PM
for this great meal and time to socialize.

Some of the topics to be presented include:
* Becoming familiar with your TNC
* Changing parameters to improve channel throughput
* Basic and advanced TCP/IP sessions
* "Hands-on" packet frequency coordination session
* Building and using a cellular high-speed packet network.

For more information about tickets and special room rates contact Paul Ramey,
WG0G, at [phone] (no collect calls, please).

See you at the Midwest Packet Radio COnference on Feb. 8th???  Hope So!

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

End of Packet-Radio Digest V91 #317
******************************
Date: Mon,  9 Dec 91 04:30:05 PST
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 #318
To: packet-radio


Packet-Radio Digest         Mon,  9 Dec 91       Volume 91 : Issue 318

Today's Topics:
          UCSD ftp hamradio/ka9q/incoming directory

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 Dec 91 18:09:26 GMT
From: [e-mail]
Subject: UCSD ftp hamradio/ka9q/incoming directory
To: [e-mail]

If you placed anything there more than a few weeks ago and don't see
it either in 'incoming' or the appropriate subdirectory, we'd really
appreciate it if you'd resend it.

It looks like some son-of-a-bitch used ftp's delete command to remove
a bunch of files.
    - Brian

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

End of Packet-Radio Digest V91 #318
******************************
Date: Tue, 10 Dec 91 04:30:04 PST
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 #319
To: packet-radio


Packet-Radio Digest         Tue, 10 Dec 91       Volume 91 : Issue 319

Today's Topics:
             New PI Card Driver Available
              On being civil...

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

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

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

Date: 9 Dec 91 16:21:30 GMT
From: [e-mail]
Subject: New PI Card Driver Available
To: [e-mail]

I have uploaded a Clarkson packet driver for the Ottawa PI board, written by
Dave Perry VE3IFB, to ucsd.edu.  The file is pi_dvr.zip, and can be found in
pub/hamradio/ka9q/incoming.  This driver will permit the PI board (a
synchronous I/O interface for the PC bus, with DMA support) to be used with
versions of NOS (and, presumably, the older NET code) which do not have the
built-in PI driver.  The packet driver has some limitations compared to the
built-in driver - see the pi.doc file for details.

Note that you may also find a file called pi.zip elsewhere on ucsd.  This is
not the packet driver, but an older version of the built-in driver for NOS.

Feedback on the performance of the driver would be most welcome.

- Barry VE3JF, on behalf of the Ottawa ARC Packet Working Group

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

Date: 9 Dec 91 15:56:00 GMT
From: [e-mail]
Subject: On being civil...
To: [e-mail]

> Date: 8 Dec 91 18:09:26 GMT
> From: [e-mail]
> Subject: UCSD ftp hamradio/ka9q/incoming directory
> To: [e-mail]
 ...(stuff deleted)...
> It looks like some son-of-a-bitch used ftp's delete command to remove
> a bunch of files.
>         - Brian

Regardless of what somebody has done to the files, I would appreciate
it if the postings remained civil.

Jeff Austen, k9ja, Bitnet: jra1854@tntech

P.S.  I would have sent this directly to the sender but, as you can see,
the address was not contined within the message.

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

End of Packet-Radio Digest V91 #319
******************************
Date: Thu, 12 Dec 91 04:30:06 PST
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 #320
To: packet-radio


Packet-Radio Digest         Thu, 12 Dec 91       Volume 91 : Issue 320

Today's Topics:
             DSY modem schematic (5 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: 8 Dec 91 16:09:27 GMT
From: orion.oac.uci.edu!ucivax!news.claremont.edu!elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!wupost!udel!sbcs.sunysb.edu![e-mail]
Subject: DSY modem schematic
To: [e-mail]

Does anyone have a machine readable copy of the wa4dsy 56 kBit modem?
Something in either GIF or Postscript format would be most useful.

                    Rick Spanbauer
                    SUNY/Stony Brook

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

Date: 8 Dec 91 16:18:51 GMT
From: mvb.saic.com!unogate!orion.oac.uci.edu!ucivax!news.claremont.edu!elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!wupost!udel!sbcs.sunysb.edu![e-mail]
Subject: DSY modem schematic
To: [e-mail]

To correct my own posting:

In article <[e-mail]> [e-mail] (Rick Spanbauer) writes:
>Does anyone have a machine readable copy of the wa4dsy 56 kBit modem ?
                         ^wa4dsy 56k modem schematic?
>Something in either GIF or Postscript format would be most useful.
>
>                                       Rick Spanbauer
>                                       SUNY/Stony Brook

Apologies all around, and a good of example of why not to post first thing
after rolling out of bed on Sunday morning :-)

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

Date: 9 Dec 91 19:37:24 GMT
From: mdisea![e-mail]
Subject: DSY modem schematic
To: [e-mail]

In article <9112091049.AA06270@kd4nc> dug (Doug Drye KD4NC) writes:
>
>The N. Ga Packet Radio group (GRAPES) sells a nearly full kit and various
>other sub-kits... It's a fund raising project for our non-profit club..
>the proceeds are entirely put toward expanding our N. Ga high speed
>packet bachbone (which is coming along nicely, thanks).
    ^^^^

I guess this is truly a musical network. And with the nice high-speed
modems, it really "sings" :-) :-) :-).

Sorry Doug, I couldn't resist. It _IS_ punday, after all...

For those interested in the modem, it really is worth while getting
the kit from GRAPES. It makes the job of tracing down the parts
much easier, especially the "hard to find" things like coils and
rf transformers on the rf deck. Note the quotes around hard to find.
The parts really are readily available, you just have to know where...
(Hint: try Digi-Key). The biggest advantage is that you get everything
at once and don't have to wait for back-ordered items from some
distributor.

Now, for those interested in punday, it is a GRAPES / North Fulton
Amateur Radio League (North Atlanta) tradition that reserves Mondays
and Fridays for those of us that like to inflict puns. Why Mondays and
Fridays? Well, On Monday you need some sort of relief just because it
is Monday, and Friday because the weekend is almost here and you can't
help yourself. This actually was an attempt by some to control the
punning that almost got out of control in the area. So, if you are
in Atlanta / North Georgia on a Monday or Friday, watch out!

Of course, it's harder for me to participate in the inflicting now that
I am in the Pacific Northwest... (and that draws a big :-) from Doug...).

Jack Brindle
ham radio: wa4fib
internet: [e-mail]

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

Date: 9 Dec 91 10:50:41 GMT
From: elroy.jpl.nasa.gov!sdd.hp.com!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!kd4nc![e-mail]
Subject: DSY modem schematic
To: [e-mail]

[e-mail] (Rick Spanbauer) writes:

>Does anyone have a machine readable copy of the wa4dsy 56 kBit modem?
>Something in either GIF or Postscript format would be most useful.

>                                       Rick Spanbauer
>                                       SUNY/Stony Brook

No, but I'm sure we can work something out...
We sell the entire documentation pack for $20. That includes "B" sized
copies of the schematics (I hate fine print) and all the other information
you need to assess the design.

The N. Ga Packet Radio group (GRAPES) sells a nearly full kit and various
other sub-kits... It's a fund raising project for our non-profit club..
the proceeds are entirely put toward expanding our N. Ga high speed
packet bachbone (which is coming along nicely, thanks).

BTW.. you won't be able to construct a "true" WA4DSY modem without the
EPROM which contains the State Machine patterns that generate the waveforms...
that is part of our PC board kit.

Please contact me directly, I hope I can
assist you in your experimentation... We try to
support experimenters, since that's where are "coming from" ....

73s

Doug
gatech!kd4nc!dug   (GRAPES Inc)


PS.. Sorry for the "near-Commercialism", but I had to stand up
    for our club... (No one here is being paid).
--
Doug Drye KD4NC

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

Date: 9 Dec 91 10:49:50 GMT
From: pacbell.com!att!linac!uwm.edu!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!kd4nc![e-mail]
Subject: DSY modem schematic
To: [e-mail]

[e-mail] (Rick Spanbauer) writes:

>Does anyone have a machine readable copy of the wa4dsy 56 kBit modem?
>Something in either GIF or Postscript format would be most useful.

>                                       Rick Spanbauer
>                                       SUNY/Stony Brook

No, but I'm sure we can work something out...
We sell the entire documentation pack for $20. That includes "B" sized
copies of the schematics (I hate fine print) and all the other information
you need to assess the design.

The N. Ga Packet Radio group (GRAPES) sells a nearly full kit and various
other sub-kits... It's a fund raising project for our non-profit club..
the proceeds are entirely put toward expanding our N. Ga high speed
packet bachbone (which is coming along nicely, thanks).

BTW.. you won't be able to construct a "true" WA4DSY modem without the
EPROM which contains the State Machine patterns that generate the waveforms...
that is part of our PC board kit.

Please contact me directly, I hope I can
assist you in your experimentation... We try to
support experimenters, since that's where are "coming from" ....

73s

Doug
gatech!kd4nc!dug   (GRAPES Inc)


PS.. Sorry for the "near-Commercialism", but I had to stand up
    for our club... (No one here is being paid).
---
Doug Drye KD4NC

--
Doug Drye KD4NC

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

End of Packet-Radio Digest V91 #320
******************************
Date: Fri, 13 Dec 91 04:30:06 PST
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 #321
To: packet-radio


Packet-Radio Digest         Fri, 13 Dec 91       Volume 91 : Issue 321

Today's Topics:
             DSY modem schematic
             Forwarded for G3LDI

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

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

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

Date: 9 Dec 91 16:20:50 GMT
From: swrinde!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!spool.mu.edu!agate!stanford.edu!CSD-NewsHost.Stanford.EDU![e-mail]
Subject: DSY modem schematic
To: [e-mail]

dug (Doug Drye KD4NC) writes:

>BTW.. you won't be able to construct a "true" WA4DSY modem without the
>EPROM which contains the State Machine patterns that generate the waveforms...
>that is part of our PC board kit.

An alternate ROM (not the ROM itself, but the data for a ROM) is available
via Email from me.  It is compatible with the DSY, and will communicate with
it.  It differs from the DSY ROM in two ways: 1) It is a constant amplitude
waveform, and so can be run through class C amplifiers, but 2) it has about
10% wider bandwidth as a result.

Marc Kaufman, WB6ECE ([e-mail])

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

Date: 6 Dec 91 22:28:23 GMT
From: [e-mail]
Subject: Forwarded for G3LDI
To: [e-mail]

  I write Packet Panorama in Practical Wireless, a column devoted, obviously,
entirely to packet radio. I am instigating a monthly item called "Sysops
Corner". This will be a photograph of the sysop, in the shack, preferably
together with information on what the sysop does, i.e. BBS, Node, Remote Sysop
or combination of all three, plus details of equipment and antennas used and
the interests held.
  I can read both 3.5 and 5.25 standard/HD disks and would be prepared to
return disks and photographs after use. My address is as follows:
Roger J. Cooke, G3LDI,
The Old Nursery,
The Drift,
Swardeston,
Norwich,
Norfolk,
England, NR14 8LQ.    Tel: [phone]  (daytime answering machine)
  I would also be interested in any packet groups, clubs or organisations
that may be in existance. Please send any details you may have.
73 de Roger, G3LDI @ GB7LDI

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

End of Packet-Radio Digest V91 #321
******************************
Date: Sat, 14 Dec 91 04:30:03 PST
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 #322
To: packet-radio


Packet-Radio Digest         Sat, 14 Dec 91       Volume 91 : Issue 322

Today's Topics:
                AmigaNOS help.
             REQUEST INFORMATION

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

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

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

Date: 13 Dec 91 15:57:00 GMT
From: [e-mail]
Subject: AmigaNOS help.
To: [e-mail]

Hello all,

I got AmigaNOS by ftp as a package from ucsd.edu.  The documentation was
sorely lacking.  I was able to get things running using a combination of
the old KA9Q docs and some GRINOS docs.  Some of the information did not
match what I observed happening with AmigaNOS.  Does anyone have or know
where I can find documentation specific to the AmigaNOS implementation?

By-the-way, does anyone know where I can subscribe to an Amiga newsgroup?

73, Erich Muschinske  KA6AMD
[e-mail]
KA6AMD @ WA6YBN.#SOCA.CA.USA.NA

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

Date: 13 Dec 91 03:41:00 GMT
From: [e-mail]
Subject: REQUEST INFORMATION
To: [e-mail]

    I WOULD LIKE TO RECEIVE NAMES OF BINARY ARCHIVES FOR PC/MSDOS.

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

Date: 11 Dec 91 22:45:39 GMT
From: elroy.jpl.nasa.gov!swrinde!mips!zaphod.mps.ohio-state.edu!moe.ksu.ksu.edu!hobbes.physics.uiowa.edu!news.iastate.edu!ux1.cso.uiuc.edu![e-mail]
To: [e-mail]

References <9112091049.AA06270@kd4nc>, <[e-mail]>, <[e-mail]>so.uiuc
Subject : Re: DSY modem schematic

[e-mail] writes:

>But seriously, what are the ballpark figures of getting one of these things
>going in kit form ??

And where do we write/call for more info??
Thanks, Jay

>Rob, vk5xxx
>[e-mail]
--
*************************************************************************
* 73 de Jay, WT9S     Internet: [e-mail]                *
*                     Packet:   [e-mail]                    *
*************************************************************************

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

Date: 13 Dec 91 21:25:32 GMT
From: [e-mail]
To: [e-mail]

References <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject : Re: DSY modem schematic

[e-mail] writes:
>But seriously, what are the ballpark figures of getting one of these things
>going in kit form ??

Well, you need the modem kit,   $250.

and a transverter to get it from 29 MHz to a band where it's legal to
use it,                         $125 to $250

and a box to put it in          $30

and a power supply (+/-5v,12)   $20 - $50

and an interface card for your PC that can run at 56kb without
swallowing the whole cpu        $110  (I like the Ottawa PI card)
                ====
                $535 to 690

Of course, if you have some of this, or can build it, you can get off a
lot cheaper.
    - Brian

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

Date: 10 Dec 91 15:11:13 GMT
From: usc!zaphod.mps.ohio-state.edu!qt.cs.utexas.edu!yale.edu!spool.mu.edu!munnari.oz.au!yoyo.aarnet.edu.au!sirius.ucs.adelaide.edu.au!levels![e-mail]
To: [e-mail]

References <[e-mail]>, <9112091049.AA06270@kd4nc>, <[e-mail]>
Subject : Re: DSY modem schematic

In article <[e-mail]>, [e-mail] (Jack Brindle) writes:
> In article <9112091049.AA06270@kd4nc> dug (Doug Drye KD4NC) writes:
>>
>>The N. Ga Packet Radio group (GRAPES) sells a nearly full kit and various
>>other sub-kits... It's a fund raising project for our non-profit club..
>>the proceeds are entirely put toward expanding our N. Ga high speed
>>packet bachbone (which is coming along nicely, thanks).
>         ^^^^
>
> I guess this is truly a musical network. And with the nice high-speed
> modems, it really "sings" :-) :-) :-).
>
> Sorry Doug, I couldn't resist. It _IS_ punday, after all.
Notlob ? Thats British Rail for you :-)

But seriously, what are the ballpark figures of getting one of these things
going in kit form ??

Rob, vk5xxx
[e-mail]

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

End of Packet-Radio Digest V91 #322
******************************
Date: Sun, 15 Dec 91 04:30:04 PST
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 #323
To: packet-radio


Packet-Radio Digest         Sun, 15 Dec 91       Volume 91 : Issue 323

Today's Topics:
             Hello BayComm Users!
       New Techician has more questions than good sense

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 Dec 91 03:14:24 GMT
From: ub!galileo.cc.rochester.edu![e-mail]
Subject: Hello BayComm Users!
To: [e-mail]

I am likely to get a BayComm Packet Modem rather soon, and I am interested in
getting firsthand input on how well it works.  I already have the software,
gotten from wuarchive, but have not actually gotten my hands on the hardware.
Please email to [e-mail], as I read this newsgroup
infrequently.

===============================================================================
|  Dan Gravatt (DNLG_LTD), KB2NDC     |  "But if you trick us again, Kirsty,  |
|  Business Manager, Amateur Radio    |   your suffering will be legendary -  |
|  Club Station K2ZWI, Rochester      |   even in Hell."                      |
|  Home Packet BBS-WB2PSI, Rochester  |         Pinhead, _Hellbound_          |
===============================================================================

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

Date: 11 Dec 91 16:29:02 GMT
From: nosc!news.ucsd.edu!sdd.hp.com!elroy.jpl.nasa.gov!freedom.msfc.nasa.gov![e-mail]
Subject: New Techician has more questions than good sense
To: [e-mail]

I decided not to let the FCC's slowness in issuing calls deter me from
asking stupid newbie questions, so here goes:

  a) What's involved in getting started in packet? I would assume a
     transceiver (duh), TNC, and software. What sorts of Mac-based
     packet software exist?

  b) How feasible is it to become an .ampr.org site? How do you
     connect to a backbone? What is the KA9Q package for? What systems
     does it run on?

  c) What sort of experimentation is there going on in packet land?
     Anyone working with 900MHz-range stuff?

-Paul

--
Paul Robichaux                  | Disclaimer: NTI pays for my skills, not my
[e-mail]  |             opinions. And, no, I don't work
+1 205 544 TIGR                 |             for NASA.
           THINK BIG- life's too short to be small.

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

End of Packet-Radio Digest V91 #323
******************************
Date: Mon, 16 Dec 91 04:30:03 PST
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 #324
To: packet-radio


Packet-Radio Digest         Mon, 16 Dec 91       Volume 91 : Issue 324

Today's Topics:
          Macintosh Packet Software (2 msgs)
       New Techician has more questions than good sense
               packet on cb? !
            UO14, UO22 Satellites

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 Dec 91 17:01:50 GMT
From: usc!wupost!think.com!rpi!news-server.csri.toronto.edu!torsqnt!geac!alias![e-mail]
Subject: Macintosh Packet Software
To: [e-mail]

I'm looking for sources of Packet Radio (and other ham) software for
Macintosh computers.  Packet terminal programs, NET and NOS, logging
software, antenna rotator contollers, satellite tracking, etc. etc.

The IBM PC seems to be the weapon of choice for most ham software, but I
can't believe that nobody has written or ported software for the Mac.

If there's enough software and/or interest, I'd be willing to maintain a
list of FTP sites, BBSes, etc...

    Thanks!

--
C. Harald Koch  VE3TLA                Alias Research, Inc., Toronto ON Canada
Internet:    [e-mail]      [e-mail]      [e-mail]
"Monogamy is an acquired taste, like sushi." "I thought you liked sushi for
the variety?" "Therin lies the mysterious Zen paradox of men, women, and fish!"

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

Date: 13 Dec 91 05:18:57 GMT
From: usc!zaphod.mps.ohio-state.edu!wupost!m.cs.uiuc.edu!ux1.cso.uiuc.edu!news.iastate.edu!vincent1.iastate.edu![e-mail]
Subject: Macintosh Packet Software
To: [e-mail]

In <[e-mail]> [e-mail] (C. Harald Koch) writes:

>I'm looking for sources of Packet Radio (and other ham) software for
>Macintosh computers.  Packet terminal programs, NET and NOS, logging
>software, antenna rotator contollers, satellite tracking, etc. etc.

>The IBM PC seems to be the weapon of choice for most ham software, but I
>can't believe that nobody has written or ported software for the Mac.

>If there's enough software and/or interest, I'd be willing to maintain a
>list of FTP sites, BBSes, etc...

>       Thanks!

>--
>C. Harald Koch  VE3TLA                Alias Research, Inc., Toronto ON Canada

Try FTPing to ftp.apple.com.  I don't recall what directory they're in, but
there is some mac ham software on that site.  I haven't seen any packet stuff,
though, that's shareware or freeware.  The only packet software I have seen
comes with from AEA, I think.  Works with either a PK232 or PK232MBX or
something like that.

Anthony Glen Jeffries
[e-mail]
[e-mail]

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

Date: 12 Dec 91 17:06:07 GMT
From: infopiz!lupine!hansen![e-mail]
Subject: New Techician has more questions than good sense
To: [e-mail]

In article <[e-mail]>, [e-mail] (Paul Robichaux) writes:
|> I decided not to let the FCC's slowness in issuing calls deter me from
|> asking stupid newbie questions, so here goes:
|>
|>   a) What's involved in getting started in packet? I would assume a
|>      transceiver (duh), TNC, and software. What sorts of Mac-based
|>      packet software exist?
Radio:
    For 1200 baud almost any FM tranceiver will work.  Most people start
    on 2 meters, just because there is alot of activity there.  You can
    choose a Hand held, mobile or base radio all will work.  Make sure it
    will tune from 144.0 MHz to 148.0 MHz (some of the older ones can only
    tune 146.0 to 148)
TNC:
    There are many choices here, all cost about the same for a 1200 baud
    model.  Here is a list of companies:
        MFJ
        Kantronics
        PacComm
        AEA
Software:
    Any terminal emulation software will work just fine.  If you want some-
    thing that is written for the TNC/Computer... Contact the TNC companies
    often they also sell software.  Also many individuals do as well..
    Since I use a PC, I do not know what good MAC software there is.
    Please remember that if you have a terminal emulation program it will
    work great!


|>
|>   c) What sort of experimentation is there going on in packet land?
|>      Anyone working with 900MHz-range stuff?
I have not done any work with 900 MHz, but a group of us in Northern California have put up radios/packet on 1.2 GHz for DX spotting (called packet cluster).  Works just fine!


Oh.... Congrats!  and Welcome to Ham radio!

DE KJ6NN
Phil

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

Date: 12 Dec 91 05:52:01 GMT
From: usc!wupost!zaphod.mps.ohio-state.edu!uunet.ca!canrem!dosgate!canrem![scott.cole%canrem.uucp]@ucsd.edu
Subject: packet on cb? !
To: [e-mail]

BG> This question has come up in the past and I believe it was pointed out
BG> that there actually are people using it.

    Yes they are using it and have used it since the early to mid 70's
    or at least that is when I first found out about it.!

BG> I agree with it being fairly un-reliable and I am sure that there will
BG> be periodic jammers (at least at first), but I also think it is doable
BG> and maybe even a good idea.  After all, could the sound of packet be any
BG> worse than what you hear there now??
BG>bill   KB3YV

     NO not at all it is very RELIABLE at 26 to 27 Mhz in FM mode but in
lets say AFSK or direct FSK tuning errors of as little as 20 Hz can cause
failure to decode packets..  and also remember 300 baud is about as fast
as you can go do to the bandwidth of 26 to 27 Mhz... You need to go VHF or
UHF to go 1200 Baud and up.!

      -=[ Thank You -=- S.C -=- Ontario -=- Canada -=- KHJ-4164 ]=-
     -=[ - * -.-. * .-. * ---.. * ..--- * ....- * ----. * .-.-.- ]=-
---
 ~ DeLuxe} 1.20 #2756 ~ Where is the HAM in radio....
--
Canada Remote Systems.  Toronto, Ontario
NorthAmeriNet Host

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

Date: 12 Dec 91 14:26:25 GMT
From: bonnie.concordia.ca!ccu.umanitoba.ca!bison!sys6626!inqmind![e-mail]
Subject: UO14, UO22 Satellites
To: [e-mail]

[e-mail] (Paul Brewer) writes:

>
> FM packet on the uplink and downlink at 9600 baud. They seemed to imply
> that good old FSK currently being used for 9600 baud terrestial links
> will work (i.e. you can work um if you are already set up for 9600
> baud packet , without having to buy an SSB riug or an expensive PSK
> modem).
>

Correct. You will need some sort of 9600 baud packet system as used
terrestrially. Uplink is 2M. Downlink is 435 MHz. You'll need a full
duplex system such as the G3RUH system. You can use the half duplex
K9NG if you either have 2 of them or if you mod one for full duplex.

I use turnstiles for up and down links. 30 watts uplink power.

As for expensive radios, I use a retuned surplus land mobile transmitter
for the uplink (rock bound) and a hamtronics 430 MHz receiver kit
for the downlink (rockbound and AFC range widened).

I'm a new ham and didn't have any existing VHF/UHF equipment. UO-14
was the cheapest to get on to for me.

Bruce

[e-mail]
The Inquiring Mind BBS, Winnipeg, Manitoba  204 488-1607

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

Date: 12 Dec 91 22:26:54 GMT
From: gatech!emory!wa4mei!ke4zv![e-mail]
To: [e-mail]

References <[e-mail]>, <[e-mail]>, <[e-mail]>
Reply-To : [e-mail] (Gary Coffman)
Subject : Re: DSY modem schematic

In article <[e-mail]> [e-mail] (Jay Freeman) writes:
>[e-mail] writes:
>
>>But seriously, what are the ballpark figures of getting one of these things
>>going in kit form ??
>
>And where do we write/call for more info??
>Thanks, Jay

Write to GRAPES at the following address:

GRAPES Inc.
P. O. Box 871
Alpharetta, GA 30239-0871

As to system costs, a complete system including transverter can be put
together for around $400-$750 depending on the transverter chosen. The
modem kit itself puts out RF at 29 Mhz and requires an external transverter
to translate the signal up to UHF. Remember that in this system, the modem
*is* the radio so no external radio is required, just a transverter.
The kit alone is $250.

Gary KE4ZV

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

Date: 12 Dec 91 14:42:13 GMT
From: pacbell.com!att!linac!uwm.edu!zaphod.mps.ohio-state.edu!samsung!news.cs.indiana.edu!umn.edu!noc.MR.NET!uc.msc.edu!nachos.SSESCO.com![e-mail]
To: [e-mail]

References <9112091049.AA06270@kd4nc>, <[e-mail]>, <[e-mail]>st
Subject : Re: DSY modem schematic

In article <[e-mail]> [e-mail] writes:
>In article <[e-mail]>, [e-mail] (Jack Brindle) writes:
>> In article <9112091049.AA06270@kd4nc> dug (Doug Drye KD4NC) writes:
>>>
>>>The N. Ga Packet Radio group (GRAPES) sells a nearly full kit and various
>>>other sub-kits... It's a fund raising project for our non-profit club..
>>>the proceeds are entirely put toward expanding our N. Ga high speed
>>>packet bachbone (which is coming along nicely, thanks).
>>         ^^^^
>
>But seriously, what are the ballpark figures of getting one of these things
>going in kit form ??
>

And along these same lines, has anyone got them running on 1296 ? I saw
some previous postings asking about 28 MHz <=> 1296 MHz transverters but
never saw any definitive answers on whether or not they exist...

Are people using intermediate 144 MHz transverters and then going to 1296 ?

Could a person successfully use Hamtronics 2m transmit and receive converters
between the 'DSY and a 1296 "NO-TUNE TRANSVERTER".... ??

Inquiring minds want to know...


--
Chris Elmquist, N0JCF
[e-mail]                73267,[e-mail]
[e-mail]             [phone]@work (8am-5pm CST6CDT)

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

End of Packet-Radio Digest V91 #324
******************************
Date: Tue, 17 Dec 91 04:30:03 PST
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 #325
To: packet-radio


Packet-Radio Digest         Tue, 17 Dec 91       Volume 91 : Issue 325

Today's Topics:
              Macintosh Packet Software
              meteorite burst communica
              PACKET RADIO INFO REQUEST
              Spread spectrum data modem

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 Dec 91 19:25:32 GMT
From: telesoft![e-mail]
Subject: Macintosh Packet Software
To: [e-mail]

In <[e-mail]> [e-mail] (C. Harald Koch) writes:

>I'm looking for sources of Packet Radio (and other ham) software for
>Macintosh computers.  Packet terminal programs, NET and NOS, logging
>software, antenna rotator contollers, satellite tracking, etc. etc.

There's quite a bit at ucsd.edu in the hamradio directory.
--GaryM
--
Gary Morris                  Internet: [e-mail]
KK6YB                        UUCP:     ucsd!telesoft!garym
TeleSoft, San Diego, CA      Phone:    [phone]

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

Date: 16 Dec 91 11:27:00 GMT
From: [e-mail]
Subject: meteorite burst communica
To: [e-mail]

Attn: packet radio
SentBy: Joel Disini

               Subject:                               Time:3:41 PM
  OFFICE MEMO          meteorite burst communication          Date:12/16/91
hello netters!
This group may not be the best place to ask this question, but i am told the
technology was first discovered by HAMS, so i thought I'd try.  I am looking
for a list of vendors (and some literature too) who implement MBC (meteorite
burst communication).  (I've also heard it being called MSC - meteorite
scatter communication). The basic idea, the way i understand it, is that you
can aim a signal at a given point in the atmosphere and wait for a meteorite
trail to deflect the signal to your desired destination. Naturally, meteorites
aren't always available for signal deflection, but you can rely on these
occuring with regular frequency, at a rate of about one trail every 3 mins. I
am told that you can send quite an amount of data during the lifetime of that
metorite trail (2-3seconds? several gigabytes?)

Any help you can give is appreciated! Pls cc your responses to me at
[e-mail].
Thanks!
Joel Disini
Manila, Philippines


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

Date: 16 Dec 91 21:21:00 GMT
From: [e-mail]
Subject: PACKET RADIO INFO REQUEST
To: [e-mail]

Hi, I'm Mitch M. and new to networking.  Pleas send lots of info on Packet
radio.  My address is:

[e-mail]

:)

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

Date: 15 Dec 91 19:11:27 GMT
From: sdd.hp.com!think.com!rpi![e-mail]
Subject: Spread spectrum data modem
To: [e-mail]

     I remember reading that article in QST. The simplicity of that system is
very nice but there are a few comprimises involved. I think that you might be
mistaken in thinking that two carriers are needed to transmit data and the
reference. I don't have the article in front of me now, but I believe it uses
the recieved rf carrier to clock the PN generator by dividing it down. This
means that your rf carrier frequency must be an integer multiple of your chip
rate. This may be inconvenient. Perhaps a more serious trade off involved in
this approach is reduced immunity to narrowband interference. How much, I don't
know, I havn't done the analysis. Maybee one of those communications people out
the could give us an estimate.
    You might consider a system that does not require a transmitted reference.
I have given it some thought and come to the conclusion that it is not
substantially more difficult. Although I have not actually tried it, it seems
not too difficult to implement tau dither tracking. I strongly suggest that you
track down a copy of Spread Spectrum Systems by Robert C. Dixon (John Wiley
& Sons, 1984). It really tells you everthing you need to know and is very
readable. Absolutly chock full of practical information.
    I would be interested to hear about your results if you decide to persue
this. Likewise to anyone else on the net who is using DS SS data links.


            73, Greg - N2IKZ - [e-mail]

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

Date: 13 Dec 91 16:19:11 GMT
From: pacbell.com!att!emory!wa4mei!ke4zv![e-mail]
To: [e-mail]

References <[e-mail]>, <[e-mail]>, <[e-mail]>
Reply-To : [e-mail] (Gary Coffman)
Subject : Re: DSY modem schematic

In article <[e-mail]> [e-mail] (Chris Elmquist) writes:
>
>And along these same lines, has anyone got them running on 1296 ? I saw
>some previous postings asking about 28 MHz <=> 1296 MHz transverters but
>never saw any definitive answers on whether or not they exist...
>
>Are people using intermediate 144 MHz transverters and then going to 1296 ?
>
>Could a person successfully use Hamtronics 2m transmit and receive converters
>between the 'DSY and a 1296 "NO-TUNE TRANSVERTER".... ??

I haven't tried it yet, but I see no reason why it wouldn't work. We've
used the XV4 and 440 receive converter successfully. The XV2 and 2 meter
converter should work too. Since they can both be left running, I see no
reason why they wouldn't work with Down East's transverters or with the
SSB Electronics units. The SSB units are relay switched on their inputs,
and you'd need to modify them to remove the relay, but I don't see any
other problems.

Gary KE4ZV

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

End of Packet-Radio Digest V91 #325
******************************
Date: Wed, 18 Dec 91 04:30:02 PST
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 #326
To: packet-radio


Packet-Radio Digest         Wed, 18 Dec 91       Volume 91 : Issue 326

Today's Topics:
             Packet on an Amiga?
         Spread spectrum data modem (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: 17 Dec 91 02:17:18 GMT
From: hpl-opus!hpspdla![e-mail]
Subject: Packet on an Amiga?
To: [e-mail]

While, I am not aware of any Amiga specific packet software, you already
have the most important part: a real multi-taking operating system.  I
also have an A1000.  You can use just about any terminal emulator
program that you like.  Use it to either type directly to the modem, or
send and receive files.

Then use your favorite editor to read and write files in a separate
window.  My choice is mg (one of the micro-EMACS versions) You can use
notepad or whatever.

Connect to your local BBS.  Ask it for a list of bulletins, and have the
terminal program save it to a file.  Then edit the file.  When you see
one you like, go back to the terminal window and ask to read the
bulletin (and possibly save it to a new file).  The ability to
edit/send/save files is a lot of what the fancy packet software does
under messyDos.


AA6PZ @ N6IIUU-1.#NOCAL.CA.USA.NA

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

Date: 15 Dec 91 01:44:58 GMT
From: gatech!udel!sbcs.sunysb.edu![e-mail]
Subject: Spread spectrum data modem
To: [e-mail]

(I may be too early into my literature search to intelligently
comment on this topic yet, so forgive any particularly naive
ramblings ;-) )

The ARRL Spread Spectrum Sourcebook has an interesting article
by Andre' Kestleroot titled "Practical Spread Spectrum: An
Experimental Transmitted Reference Data Modem".  The article
discusses a technique which apparently simplifies the data recovery
problem of SS by transmitting both a reference & data modulated
carrier.  The receiver structure is deceivingly simply - it
consists of a couple of tuned amplifiers, mixer, and slicer.
If this technique is workable, ie over a real RF link, then
it would seem an ideal starting point for a practical high
speed SS packet modem.  Of course, the baseband coding would
have to be switched to something that would facilitate clock
recovery, eg manchester coding.

I guess one issue that might make the technique unworkable over
a real RF link would be selective fading or group delay differences
of the two carriers.  Are there other problems?

Comments?

                    Rick Spanbauer, wb2cfv
                    SUNY/Stony Brook

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

Date: 15 Dec 91 22:50:35 GMT
From: ogicse!uwm.edu!wupost!udel!sbcs.sunysb.edu![e-mail]
Subject: Spread spectrum data modem
To: [e-mail]

In article <c02q2#[e-mail]> [e-mail] (Gregory A. Sadowy) writes:
>     I remember reading that article in QST. The simplicity of that system is
>very nice but there are a few comprimises involved. I think that you might be
>mistaken in thinking that two carriers are needed to transmit data and the
>reference. I don't have the article in front of me now, but I believe it uses

    No, the article starting on page 8-58 uses two carrier oscillators
    at 68.8 mHz & 73 mHz.  The article itself distinguishes between
    "stored reference SS" and "transmitted reference SS"; apparently
    most amateur publications have dealt with the former, where the
    article in question deals with the latter type.

>    You might consider a system that does not require a transmitted reference.
>I have given it some thought and come to the conclusion that it is not
>substantially more difficult. Although I have not actually tried it, it seems

    The most daunting problem with the stored reference systems is
    establishment of synchronization and the time it takes.  The
    transmitted reference system seems to get around this, though
    now that I've had a little time to think about it, apparently at
    the cost of multiple access.

>track down a copy of Spread Spectrum Systems by Robert C. Dixon (John Wiley
>& Sons, 1984). It really tells you everthing you need to know and is very

    Yep, that's already on the list.  Unfortunately, the university
    library has just the 1976 version.  Hopefully Wiley has the 1984
    edition in print.

>    I would be interested to hear about your results if you decide to persue
>this. Likewise to anyone else on the net who is using DS SS data links.
>                        73, Greg - N2IKZ - [e-mail]

                    Rick

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

Date: 15 Dec 91 06:48:22 GMT
From: agate!spool.mu.edu!sol.ctr.columbia.edu!emory!kd4nc![e-mail]
To: [e-mail]

References <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject : Re: DSY modem schematic

[e-mail] (Chris Elmquist) writes:

>And along these same lines, has anyone got them running on 1296 ? I saw
>some previous postings asking about 28 MHz <=> 1296 MHz transverters but
>never saw any definitive answers on whether or not they exist...

>Are people using intermediate 144 MHz transverters and then going to 1296 ?

>Could a person successfully use Hamtronics 2m transmit and receive converters
>between the 'DSY and a 1296 "NO-TUNE TRANSVERTER".... ??
>Inquiring minds want to know...
>Chris Elmquist, N0JCF
>[e-mail]                73267,[e-mail]
>[e-mail]             [phone]@work (8am-5pm CST6CDT)

I know of no one that is doing this.. It certainly should be possible,
but we have not tried it here in Ga...

The Hamtronics units are more difficult to make work than I believe some
would be willing to handle... you should have a Spectrum Analyzer
available to insure that it's clean as you tune them up..
A few local folk here are using them on 432 mHz...
I hope to use them when we install our cross band 56KB digital repeater here
in Atlanta.. But I only plan to tackle receiving on 220 mHz at end
user locations.. I won't put them on a mountaintop site..
BTW, I am looking for a good deal on a 220 Microwave Modules transverter or
some 430 or 220 receiving converters... I know they were sold,
but the source dried up before I could get some..

I would also like to hear if anyone has tried DSY Modems on 1296...
I am E-mailing further information on 56KB modems to several posters...
My E-mail address is gatech!kd4nc!dug and the postal mailing address is

GRAPES Inc
POB 871
Alpharetta, Ga 30239-0871

Please include your postal mailing address if you want me to send
paper information in addition to E-mail information...


'73s
Doug
gatech!kd4nc!dug
or
emory!kd4nc!dug

--
Doug Drye KD4NC

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

End of Packet-Radio Digest V91 #326
******************************
Date: Thu, 19 Dec 91 04:30:04 PST
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 #327
To: packet-radio


Packet-Radio Digest         Thu, 19 Dec 91       Volume 91 : Issue 327

Today's Topics:
              Spread spectrum data modem
            UO14, UO22 Satellites

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 Dec 91 17:56:59 GMT
From: hpl-opus!hpnmdla![e-mail]
Subject: Spread spectrum data modem
To: [e-mail]

In rec.radio.amateur.packet, [e-mail] (Phil Karn) writes:

    <de-spreading description deleted>

>     If you're doing all this in a mobile environment, then the job of the
>     searcher is never done -- multipath propagation components are coming
>     and going all the time, and you have to be alert to this if you want
>     to take advantage of them (and not lose the one you're currently tracking)

   Not only are they coming and going but if you acquire on only the
biggest *one* and it happens to be extremely localized, say due to
driving past a big specular reflection from a highrise or something,
you may lose it entirely before your information is transmitted.

>     In my opinion, spread spectrum schemes that don't bother to resolve
>     multipath components are worse than useless -- they combine all of the
>     disadvantages of spread spectrum (less orthogonality, i.e., the
>     near-far problem) with almost all of the disadvantages of narrowband
>     systems.

  I agree.  It sure would be nice to have a function that dynamically
weighs many different arrival times (PN clock phases) simultaneously,
based on correlation/amplitude at each, and then sums them all back
together, in effect "putting the time spread signal back together".
  Years ago I thought that a circuit like that would be great for
moonbounce where the reflected signal can be badly spread in time due to
the moon's non-specular reflections.
   Putting the signal back together would allow extreme reduction in
pre-detection bandwidth and along with coherent detection could permit
slow information rate EME contacts with very small stations.  I never
discovered an easy way to do this, even at the low data rates and
frequency spreading of a few tens of kHz which occur on amateur EME up
through 10 GHz. To my knowledge, the nearest anyone has come to this is
the work N4HY wnd W3IWI did using DSP.
  Putting a high information rate multipath SS signal back together on the
fly sounds like a pretty good challenge even today.  Maybe some of the
newest DSP stuff would stand a chance.

  In any case, I think that selecting/controlling radio paths and
handling their non-ideal attributes, especially multipath distortion,
are among the major technical challenges in building a wide areas
amateur radio network.
  With the Hubmaster protocol and the backbone work we are doing here in
Northern California, we are seeking practical ways to solve some of
these problems by using higher quality (line-of-sight) paths-- all the
way to the (highspeed) users.  The structure using a central server
(hub), a la current nbfm repeaters, was chosen to allow local
optimization of paths for a small number of users who can hopefully
cooperate in its implementation by using directional antennas and modest
hardware.  The polling aspects of the Hubmaster protocol are a result of
that physical arrangement and not due to some fundamental preference to
polling.  Such LOS paths are much more effective from a resource
utilization perspective in that they have both lower attenuation as well
as greatly reduced multipath problems.  However, presently they must be
statically rather than dynamically selected. Getting (potential) high
speed users to appropriately appreciate and  focus on path selection is
proving to be a significant challenge.

  In general, we continue to need methods of dealing with
less-than-ideal paths.  The mobile environment is certainly a challenge
for high speed/performance data communications.  Maybe economical
hardware and techniques to handle it will be a fallout of current
commercial efforts in PCN and digital cellular communications and amateurs
can make use of it.  However I'm afraid that by the time that happens
there will be little additional that amateur radio has to offer.

Glenn Elmore n6gn

N6GN @ K3MC
amateur IP:     [e-mail]
Internet:       [e-mail]

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

Date: 16 Dec 91 22:47:44 GMT
From: elroy.jpl.nasa.gov!nntp-server.caltech.edu!mustang.mst6.lanl.gov!data.nas.nasa.gov!muddy.nas.nasa.gov![e-mail]
Subject: UO14, UO22 Satellites
To: [e-mail]

Reguarding packet on the UO14 and UO22 satellites, [e-mail]
(Bruce Walzer) writes,

> Correct. You will need some sort of 9600 baud packet system as used
> terrestrially. Uplink is 2M. Downlink is 435 MHz. You'll need a full
> duplex system such as the G3RUH system. You can use the half duplex
> K9NG if you either have 2 of them or if you mod one for full duplex.

Can you run the station unattended, or do you need to be there to adjust
for doppler shift and such?

> As for expensive radios, I use a retuned surplus land mobile transmitter
> for the uplink (rock bound) and a hamtronics 430 MHz receiver kit
> for the downlink (rockbound and AFC range widened).

Does this mean that the satellite uses FM?

> I'm a new ham and didn't have any existing VHF/UHF equipment. UO-14
> was the cheapest to get on to for me.

I'm not a new ham, but I certainly don't have a large budget.  The concept
of satellite communication has always been exciting to me, but I have been
(perhaps mistakenly) under the impression that it takes hard-to-find-on-the-
surplus-market SSB gear (or CW, of course) and steerable antennas.  If I
can use existing or low-cost gear and a fixed antenna, I may just set up
a satellite packet station someday soon!

--Dave
________________________________________________________________________
David L. Kensiski [KB6HCN]              Numerical Aerodynamic Simulation
[e-mail]               NASA Ames Research Center, M/S 258-6
[phone]                       Moffett Field, California 94035-1000

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

End of Packet-Radio Digest V91 #327
******************************
Date: Fri, 20 Dec 91 04:30:03 PST
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 #328
To: packet-radio


Packet-Radio Digest         Fri, 20 Dec 91       Volume 91 : Issue 328

Today's Topics:
        Beginner's Choice (PK-88 od MFJ-1270)?
              Help needed with MFJ 1278
              meteor burst communicatio
              new TAPR 9600 BAUD modems?
              Novice questions.
             Packet on an Amiga?
              SpreadSpectrum and Packet
              Spread spectrum data modem

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 Dec 91 22:36:43 GMT
From: sdd.hp.com!elroy.jpl.nasa.gov!spc9![e-mail]
Subject: Beginner's Choice (PK-88 od MFJ-1270)?
To: [e-mail]

Greeting all.

I am getting ready to make my first purchase.  I posted awhile back asking
for some start-up help and received many good replies.

After doing some research, (and asking several folks), it looks like I have
boiled my choice for TNC's down to the PK-88 and the MFJ-1270.  It looks
like they can both do TCP/IP via KISS (MFJ needs ROM's to do this do it not?)
How availble are they?

Any suggestions as to which to get?

I want to migrate to 9600 bps.  PK-88 can do this with the G3RUH modem (??).
Can the MFJ do this also?

I've also heard that one or the other tends to drop out of KISS mode frequntly.
Is this so?

I've also heard that the MFJ has ROM's that allow it to go up to 56Kbps.
Is THIS so?

Also, since I seem to be buying things in stages... the next item is a
transceiver capable of 9600bps transmission.  Any suggestions?  I've heard
the TEKK digital radio (crystals and tuned) is a GOOD choice.  Also heard
that this is available from ONE person  (Mike Curtis?)  Hey Mike, how about
this?

Thanks.

Kolin.

[e-mail]
[e-mail]

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

Date: 17 Dec 91 13:00:26 GMT
From: newsstand.cit.cornell.edu!vax5.cit.cornell.edu![e-mail]
Subject: Help needed with MFJ 1278
To: [e-mail]

I am having some trouble using my MFJ 1278 on the HF modes.
Specifically, I am having a great deal of trouble getting it
to decode RTTY signals.  It only seems to work correctly maybe
one time out of ten that I try it.  Mostly I just get garbage
characters.  Has anyone else had this trouble?  Any suggestions
on what I can try to remedy the problem?  BTW, the 1278 is one
of the later ones - about 10 months old.

Thanks in advance.

73,

KA7I
Bruce Fingerhood
[e-mail]
School of Electrical Engineering
Cornell University

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

Date: 19 Dec 91 14:00:00 GMT
From: [e-mail]
Subject: meteor burst communicatio
To: [e-mail]

Attn: packet radio
SentBy: Joel Disini

               Subject:                               Time:10:03 PM
  OFFICE MEMO          meteor burst communication & HF        Date:12/19/91
Hello Netters,

some time ago I made a post asking about meteor burst communication vendors.
I have since learned that MBC is pretty pricey.  A basic setup will go for
$165k. $150k for the base and $15k for the remote.  Throughput is low; 50-100
bps on average. There are more expensive systems, which can go all the way up
to 4000-5000 bps.  These systems are not available though, and will start at
around $250k per site.

Given these numbers, I was wondering how viable packet on HF would be as an
email backbone to connect  sites up to 1000 miles away (the max range for
MBC). I am told that HF channels are sporadic in nature; sometimes you can
connect, sometimes you can't; nightime is supposedly the best time for
communication.  Also, for sites that are not that far away (but far enough
that they aren't within the line of sight), HF signals generate a ground wave
that allow these sites to connect at any given time (on demand).

Does anyone care to comment on this?
As usual, please cc your response to me at [e-mail].
Thanks!
joel disini
manila



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

Date: 18 Dec 91 08:53:28 GMT
From: news.hawaii.edu!mpg.phys.hawaii.edu![e-mail]
Subject: new TAPR 9600 BAUD modems?
To: [e-mail]

I just ordered some stuff from TAPR this morning.  I had also intended
to purchase a pair of the K9NG modem kits but the person I was speaking
with indicated that TAPR may be coming out with an 'improved' 9600 BAUD modem
kit, supposedly full-duplex.  Unfortunately, that was the only information
I could get on this new modem and I was also told this was not a sure thing.

Does anyone have any idea what the improvements are in this new modem kit?
Are they significant for a half-duplex 9600 BAUD net?

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

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

Date: 17 Dec 91 17:36:45 GMT
From: fs7.ece.cmu.edu!crabapple.srv.cs.cmu.edu!andrew.cmu.edu![e-mail]
Subject: Novice questions.
To: [e-mail]

Actually, I dont't mean novice...
I am almost totally cluueless about packet/ham
but I know what I want to know.  I want to get
a portable radio/tnc setup so I can go
packeting around with my portable pc.

What does someone recomend to the totally naive person?
What kind of license to I need?
What kind of radio what kind of tnc?
What does tnc stand for?
Can I get kits?  I like to build robots etc. so I can probaly
handle something of this complexity.  I am, however, totally
unfamiliar with RF (almost).

All advice appreciated.
Cb

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

Date: 17 Dec 91 15:06:12 GMT
From: sun-barr!cronkite.Central.Sun.COM!grapevine.EBay.Sun.COM!sunicnc.France.Sun.COM![e-mail]
Subject: Packet on an Amiga?
To: [e-mail]

In article <[e-mail]>, [e-mail] (Paul Zander) writes:
   > While, I am not aware of any Amiga specific packet software, you already
   > have the most important part: a real multi-taking operating system.  I
   > also have an A1000.  You can use just about any terminal emulator
   > program that you like.  Use it to either type directly to the modem, or
   > send and receive files.

Thats very true, and is how I use my Amiga, but I believe there is
Amiga software around. There is certainly a port of AmigaNOS, and I've
seen companies advertise hardware/software packages for various Ham
functions. One company that makes ATV stuff (and may well do Packet
software/hardware as well) is:

Black Belt Systems
398 Johnson Road
RR1 Box 4272
Glasgow
MT 59230


The guy that runs it (Ben Williams) is a ham.

Note I`ve never used their ham stuff, nor am I connected with them,
but I've seen favourable reports

Steve


--
Steve McKinty
SUN Microsystems ICNC
38240 Meylan, France
email: [e-mail]     BIX: smckinty

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

Date: 19 Dec 91 14:03:36 GMT
From: [e-mail]
Subject: SpreadSpectrum and Packet
To: [e-mail]

Regarding recent discussions on Direct Sequence Spread Spectrum, and the May
89 Kesteloot article.

I have constructed the PN sequence generator as discribed in the article.
Note that the article is reprinted in the Spread Spectrum Source Book (ARRL).
The first snag that turns up is that the MC3396P prescaler chip is no longer
available from Motorola.  You will have to build a new divider chain using
Fast TTL.  You may wish to use a small amp in front of the divider.

Here are the primary considerations:
1) The center frequency or non spead signal must (by FCC rules) carry the
data.  You may choose narrow band FM or a wider signal to suit your data
needs.
2) The PN sequence must be one of the three sequences approved by the FCC.
3) You can choose a chip rate (divider output frequency) to suit your needs,
but you must confine your signal to the given band.

There are some secondary considerations:
1) You can choose some other stage of the exciter's multiplier chain and then
select a new divider ratio.
2) Theoretically, there is a problem adding transverters, if the transverter
LO is not phase sychronous with the the base oscillator.  This is a good
experiment for someone.
3) Using too high a chip rate will cause sync problems.  Start slow and build
up.

A new snag turned up recently:  Hamtronics has changed the 440 exiciter board
and the power level control is no longer used.  The output is tuned by two
capicitors for peak and no drive level varible resistor exists.  This should
be a simple mod for UHFer.  (We are building on to a repeater system)

Good Luck with DSSS

Tim, [e-mail]  <-- yes packet.  Palm Bay, FL 32905.

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

Date: 18 Dec 91 05:20:07 GMT
From: network.ucsd.edu!qualcom.qualcomm.com!qualcom.qualcomm.com![e-mail]
Subject: Spread spectrum data modem
To: [e-mail]

In article <[e-mail]>, [e-mail] (Glenn Elmore) writes:
|>   I agree.  It sure would be nice to have a function that dynamically
|> weighs many different arrival times (PN clock phases) simultaneously,
|> based on correlation/amplitude at each, and then sums them all back
|> together, in effect "putting the time spread signal back together".

You can do this if there are relatively few multipath components, at
least within the resolution that your chipping rate allows. You need
one demodulator per multipath component. The higher your chipping
rate, the more you can discriminate between multipath components (and
prevent the destructive interference that can occur between them), but
then you need more demodulators to put the signal back together again.

|>   Years ago I thought that a circuit like that would be great for
|> moonbounce where the reflected signal can be badly spread in time due to
|> the moon's non-specular reflections.

This is a lot harder because the multipath components from the moon
are not at all discrete. You could probably capture a few of them, but
you'd still miss much of the received energy.

|>   In general, we continue to need methods of dealing with
|> less-than-ideal paths.  The mobile environment is certainly a challenge
|> for high speed/performance data communications.

You got that right. And you can probably guess why our CDMA system has
generated so much interest. :-)

Phil

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

Date: 17 Dec 91 02:42:03 GMT
From: walter!qualcom.qualcomm.com!qualcom.qualcomm.com![e-mail]
To: [e-mail]

References <[e-mail]>, <c02q2#[e-mail]>, <[e-mail]>
Reply-To : [e-mail]
Subject : Re: Spread spectrum data modem

Automatic receiver synchronization in a spread-spectrum system is not
as hard as a lot of hams make it out to be. And unless you do it,
you're wasting many (if not most) of the benefits of spreading.

For example, a speaker at the recent ARRL CNC tutorial showed one
spread spectrum receiver that simply passes the incoming signal
through a SAW correlator and thence to a data slicer. Although this
circuit is admittedly better than the mostly junk Part 15 units we've
been seeing (at least this approach gives some processing gain!) it is
not doing anything to resolve multipath. And multipath rejection is
probably THE feature of spread spectrum that more than makes up for
its shortcomings, especially when you're mobile.

Probably the easiest way to synchronize to an incoming spread spectrum
signal is to sweep a PN correlator (a PN generator feeding a mixer)
through all possible offsets and look for the sudden rise in
narrowband energy at the output you get when you have the correct PN
timing.

Since you don't know carrier frequency and phase at this point you
need a post-despreading filter wide enough to accomodate doppler shift
and other causes of frequency uncertainty. But once you find the
approximate PN timing, you can engage a standard code tracking loop to
keep it. Then you proceed to demodulate the despread narrowband
signal, e.g., acquiring carrier frequency and phase if you're using
PSK. Once this happens, the demodulator filter bandwidth can drop down
to that required to match the incoming signal for best Eb/No
performance.

If you're doing all this in a mobile environment, then the job of the
searcher is never done -- multipath propagation components are coming
and going all the time, and you have to be alert to this if you want
to take advantage of them (and not lose the one you're currently tracking).

In my opinion, spread spectrum schemes that don't bother to resolve
multipath components are worse than useless -- they combine all of the
disadvantages of spread spectrum (less orthogonality, i.e., the
near-far problem) with almost all of the disadvantages of narrowband
systems.

Phil

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

Date: 17 Dec 91 11:48:05 GMT
From: mcsun!unido!urmel![e-mail]
To: [e-mail]

References <c02q2#[e-mail]>, <[e-mail]>, <[e-mail]>9
Subject : Re: Spread spectrum data modem

Hello,

as there was written a lot about the use of spread spectrum, I'd like
to know if there are some packet MODEMs for taking benefit of this technique.

If so please post your answer here or send me an E-Mail
(to [e-mail]).

Thanks in advance.

Bye es 73
     Ralf


--
Ralf Crumbach, DD2KZ        | One of the most striking differences
 [e-mail]     | between a cat and a lie is that a
 AX.25:                     | cat has only nine lives.
   [e-mail]   |   - M. Twain

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

End of Packet-Radio Digest V91 #328
******************************
Date: Sat, 21 Dec 91 04:30:02 PST
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 #329
To: packet-radio


Packet-Radio Digest         Sat, 21 Dec 91       Volume 91 : Issue 329

Today's Topics:
         "Craig Shergold, Dying Boy" - Hoax?
        Beginner's Choice (PK-88 od MFJ-1270)?
              Comments on PK-88
             Extended KISS spec (3 msgs)
          FT-470: Looking for Hyperscan Mod.
             FTP site for ROSE? (2 msgs)
              Help with Heath Pocket TNC
              Internet <--> Packet Radio
                MODEM
          NEC PC-8401A-LS (Starlet) FORSALE
              NET/Mac and slip question
        NOS for Microsoft Windows v3? (2 msgs)
              SpreadSpectrum and Packet
              Spread spectrum data modem

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 Dec 91 14:54:55 GMT
From: network.ucsd.edu!usc!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!athena.cs.uga.edu![e-mail]
Subject: "Craig Shergold, Dying Boy" - Hoax?
To: [e-mail]

We have recently started getting email asking people to send postcards or
business cards to a dying 7-year-old boy named Craig Shergold.  I suspect
the same message is going to turn up on ham radio.

I don't think these appeals are genuine, because Craig has apparently been
7 years old ever since the message started circulating in the mid-1980s.
Even if originally genuine, it is now hopelessly out of date.

Further discussion on alt.folklore.urban, which debunks the Craig Shergold
legend regularly.

73 de N4TMI

--
==================================================================
Michael A. Covington, Ph.D.  |  [e-mail]   |  N4TMI
Artificial Intelligence Programs | U of Georgia | Athens, GA 30602
==================================================================

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

Date: 19 Dec 91 20:56:58 GMT
From: network.ucsd.edu!usc!rpi!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!kd4nc!ke4zv![e-mail]
Subject: Beginner's Choice (PK-88 od MFJ-1270)?
To: [e-mail]

In article <[e-mail]> [e-mail] (Kolin Hand) writes:
>Greeting all.
>
>I am getting ready to make my first purchase.  I posted awhile back asking
>for some start-up help and received many good replies.
>
>After doing some research, (and asking several folks), it looks like I have
>boiled my choice for TNC's down to the PK-88 and the MFJ-1270.  It looks
>like they can both do TCP/IP via KISS (MFJ needs ROM's to do this do it not?)
>How availble are they?

We've had exceptionally good luck with the MFJ 1270 at switch sites and
user stations. It is a true TAPR clone and will use all firmware that
has been developed for the TNC2. The later versions of the firmware,
1.6 and 1.7 include KISS. We prefer to use a separate dedicated KISS
rom in our equipment to prevent the chance of the TNC dropping out
of KISS mode during a power failure, but the KISS implementation in
the standard rom will work fine for an attended station. The 1270
seems to generate the least RFI of all the TNCs currently available.

>Any suggestions as to which to get?

We like the MFJ and the Paccomm TIny 2. Both work exceptionally well
at unattended sites. Our experience with AEA TNCs has not been positive.
Kantronics TNCs are not firmware or hardware compatible and we have avoided
them for this reason.

>I want to migrate to 9600 bps.  PK-88 can do this with the G3RUH modem (??).
>Can the MFJ do this also?

The G3RUH modem will work on any TNC with the TAPR modem disconnect header
such as the MFJ and the Tiny 2. It can be fitted to *most* other TNCs, but
sometimes with difficulty.

>I've also heard that one or the other tends to drop out of KISS mode frequntly.
>Is this so?

All TNCs with multi-mode firmware can drop out of KISS mode under some
conditions. At least with the units that are TAPR firmware compatible
you can substitute a dedicated KISS rom that will absolutely prevent
this. This is our practice at all sites.

>I've also heard that the MFJ has ROM's that allow it to go up to 56Kbps.
>Is THIS so?

MFJ doesn't have the roms, but *we* do, Grapes that is. The rom image
is included with every kit. There are other hardware mods that you must
carry out. Detailed instructions are included for true TAPR clones.
Now a days there are better alternatives if you use a PC clone. There
are at least three plugin cards available that will drive the
56 kb modem directly from the buss using DMA circumventing the interrupt
per character performance bottleneck of a serial interface. With certain
of the cards, multiple 56 kb modems can be serviced by a lowly XT.

>Also, since I seem to be buying things in stages... the next item is a
>transceiver capable of 9600bps transmission.  Any suggestions?  I've heard
>the TEKK digital radio (crystals and tuned) is a GOOD choice.  Also heard
>that this is available from ONE person  (Mike Curtis?)  Hey Mike, how about
>this?

The TeKK radios are ok for half duplex operation. Several of us are
using them at 9600 baud. A better choice would be a radio such as
a Motorola Micor that can run full duplex, but only if your LAN supports
such operation. The TeKK is low power and suffers from poor receiver
sensitivity and is subject to strong signal overload, but is ok for
many home stations. Cheap for a new radio too. I wouldn't attempt
to put one at a switch site.

Gary KE4ZV

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

Date: 21 Dec 91 02:26:00 GMT
From: [e-mail]
Subject: Comments on PK-88
To: [e-mail]

As the owner of two PK-88's, I feel compelled to make a plug for them as
excellent starter TNC's. I got my first PK-88 back in 1989 planning to use it
with my TRS-80 COCO and MC-10. It worked like a charm. It was hardly any
trouble to get hooked up, and the command set was a breeze to learn. Contrary
to a myth that has floated around, the PK-88 will operate on HF. Granted, its
not as easy to use on HF as the PK-232 with its tuning indicator, but it workes
nonetheless. The PK-88 will run as a KISS TNC with no hardware modifications. I
am told that it can be modified to work with PacCom's NB-96 G3RUH 9600 baud
modem. My only gripe with the PK-88 is a bug in the 1990 revision of the
software that prevents the TNC from switching back to command mode after a
remote disconnect, regardless of the setting of NEWMODE. I recently installed
the DCD state machine modification in one of my TNC'S, and it works
wonderfully.

I hope the comments help you in making your decision.
73 de Will Snyder/KB4LFD
Internet: [e-mail]
Bitnet: [e-mail]
Packet: KB4LFD@N4CCK.#ILMNC.NC.USA.NOAM

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

Date: 15 Dec 91 06:46:27 GMT
From: munnari.oz.au!metro!grivel!gara!ipso![e-mail]
Subject: Extended KISS spec
To: [e-mail]

According to the blurb that comes with the G8BPQ switch stuff, it relies
on an extended KISS implementation that uses (hitherto unheard-of :-)
features such as checksumming, flow control, polling, and ACKing etc.

Is any of this formally documented?  A mate of mine is designing a KISS
modem-on-a-chip (a 68HC11) and wants to know the full details.

--
Dave Horsfall (VK2KFU)         VK2KFU @ VK2RWI.NSW.AUS.OC
[e-mail]                  ...munnari!ips.OZ.AU!dave

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

Date: 20 Dec 91 20:39:37 GMT
From: network.ucsd.edu!swrinde!mips!atha!aunro!aupair.cs.athabascau.ca![e-mail]
Subject: Extended KISS spec
To: [e-mail]

[e-mail] (Dave Horsfall) writes:

>According to the blurb that comes with the G8BPQ switch stuff, it relies
>on an extended KISS implementation that uses (hitherto unheard-of :-)
>features such as checksumming, flow control, polling, and ACKing etc.

>Is any of this formally documented?

Not really - you need to scan the documentation that comes with the
software that uses these extended features.

I sent Phil some mail a while back asking if he had plans to publish
a "Son of KISS" spec. He did a very good job of evading the question :-)
I am getting concerned about all these unofficial extensions. The
potential for collisions in the use of new KISS commands is much too
high already.

If Phil isn't willing to take on publishing a new spec I will very
reluctantly step into the pit and offer my services ...
--
       atha!cs.athabascau.ca!lyndon || [e-mail]
            Packet: [e-mail]
    Admittedly, the CA domain registrars seem a bit overzealous in
     their quest to preserve the purity of the namespace.   --Mark Moreas

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

Date: 20 Dec 91 21:09:23 GMT
From: network.ucsd.edu!qualcom.qualcomm.com!qualcom.qualcomm.com![e-mail]
Subject: Extended KISS spec
To: [e-mail]

In article <[e-mail]>, [e-mail] (Lyndon Nerenberg) writes:
|> [e-mail] (Dave Horsfall) writes:
|>
|> >According to the blurb that comes with the G8BPQ switch stuff, it relies
|> >on an extended KISS implementation that uses (hitherto unheard-of :-)
|> >features such as checksumming, flow control, polling, and ACKing etc.
|>
|> >Is any of this formally documented?
|>
|> I sent Phil some mail a while back asking if he had plans to publish
|> a "Son of KISS" spec. He did a very good job of evading the question :-)
|> I am getting concerned about all these unofficial extensions. The
|> potential for collisions in the use of new KISS commands is much too
|> high already.
|>
|> If Phil isn't willing to take on publishing a new spec I will very
|> reluctantly step into the pit and offer my services ...

If you do publish a new spec, you should call it something other than
"KISS", since that description (Keep It Simple Stupid) would no longer
apply. The whole purpose behind KISS was to provide the *bare minimum*
of hooks to allow a PC without an HDLC interface to use a TNC to
generate and receive arbitrary HDLC frames. Flow control, polling and
ACKing were (and are) very much against the KISS principle, and Mike
(K3MC) and I deliberately excluded them. They really don't belong there.

Checksumming is about the only feature that I might even think about
adding to the KISS TNC spec were I to do it all over again. The wire
between the host and TNC typically does have a low error rate, but
unfortunately people have been trying to use KISS TNCs with programs
and hardware that isn't quite up to handling solid 9600 bps (or
whatever) input streams.  Occasionally characters are lost and people
blame the KISS TNC for this when of course the fault is elsewhere.
Also, KISS was primarily intended for TCP/IP, which has its own header
checksums.

And of course KISS was only meant as a stopgap hack until true HDLC
interfaces became available. They are now available, at least for the
PC, and I strongly advocate that anyone trying to decide between an
external KISS TNC and a dedicated HDLC board (e.g., DRSI PCPA, PACCOMM
PC-100, etc) opt for the latter.

Phil

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

Date: 21 Dec 91 00:36:16 GMT
From: [e-mail]
Subject: FT-470: Looking for Hyperscan Mod.
To: [e-mail]

Hello there,
Sorry about taking up bandwidth on an old question like this, but I'm looking
for the Keyboard-Entry Hyperscan Modification for the Yaesu FT-470. I don't
have access to info. like this otherwise. Replies can be sent directly to my
"address". Many Thanks for your patience.
    73 de Gogian, KC6VKZ
Gogian Yee:es GSD/WCO:XEROX

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

Date: 15 Dec 91 06:47:38 GMT
From: agate!spool.mu.edu!munnari.oz.au!metro!grivel!gara!ipso![e-mail]
Subject: FTP site for ROSE?
To: [e-mail]

Is there an FTP site for ROSE, preferably with source?

--
Dave Horsfall (VK2KFU)         VK2KFU @ VK2RWI.NSW.AUS.OC
[e-mail]                  ...munnari!ips.OZ.AU!dave

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

Date: 20 Dec 91 20:44:20 GMT
From: network.ucsd.edu!swrinde!mips!atha!aupair.cs.athabascau.ca![e-mail]
Subject: FTP site for ROSE?
To: [e-mail]

[e-mail] (Dave Horsfall) writes:

>Is there an FTP site for ROSE, preferably with source?

nro.cs.athabascau.ca:hams/rose-422.tar.Z or
nro.cs.athabascau.ca:hams/rose-422.zip

These contain the first version publically released. There may be
newer versions. If you know of one let me know so I can update
the archive.
--
       atha!cs.athabascau.ca!lyndon || [e-mail]
            Packet: [e-mail]
    Admittedly, the CA domain registrars seem a bit overzealous in
     their quest to preserve the purity of the namespace.   --Mark Moreas

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

Date: 19 Dec 91 20:40:19 GMT
From: network.ucsd.edu!pacbell.com!mips!think.com!spdcc!dirtydog.ima.isc.com!ispd-newsserver!kodak![e-mail]
Subject: Help with Heath Pocket TNC
To: [e-mail]

I have a strange problem with a Heath pocket tnc.  The thing seems to work
ok when monitering the local packet, but when I connect to a local BBS
here is what I get:

*********************************************


c wb2wxq
*** CONNECTED to WB2WXQ
Hi Mark! Welcome to ROCBBS!  BBS moved back to Kodak Park on 11/14
Please leave a note to the SysOp with a signal report.  Thanks!

Type H if you need Help>
l
*** DISCONNECTED


*********************************************

It seems that a carrage return will cause it to disconnect.
I am thinking that I have something set up wrong in its setup, and am
hoping that someone has an answer.


Thanks.


Mark Hilliard, N2HHR

[e-mail]

716-588-2077 days
315-986-4080 night

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

Date: 18 Dec 91 20:06:26 GMT
From: nosc!dog.ee.lbl.gov!hellgate.utah.edu!cs.utexas.edu!wupost!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!hamblin.math.byu.edu![e-mail]
Subject: Internet <--> Packet Radio
To: [e-mail]

I am looking for any information about wormholes between packet and internet
for mail transfers.  If anyone has an information, there are a few people out
there that would really like to find out about them.  I am interested in any
wormholes setup especially in California.

Thanks in advance.

Sean Eckton
KD6BIK
Packet   :  kd6bik @ wb7esh.#orem.ut.usa.na
Internet :  [e-mail]

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

Date: 18 Dec 91 20:39:22 GMT
From: mcsun!uknet!warwick!kingpol![e-mail]
Subject: MODEM
To: [e-mail]

Dear all members,

does anyone know if it is possible to transmit data over the radio via
a mode rather than use the costly phone ?

If anyone knows, what equipment do you need ?

------------------------------------------------------------------------------
Richard Smart
Kingston Polytechnic                            [5m[1m\[0m
[e-mail]       ____________________/_____  ______________________
NSF: rsmart@nsf            /_] # #  INTERCITY  # # [_| |[][___][___][___][___]
=====================     <__________________________] |Ll____________________
              +~[1m[4mo[0m--[1m[4mo[0m~==============~[1m[4mo[0m--[1m[4mo[0m~+-+~ [1m[4mo[0m=[1m[4mo[0m"""""""""""""""""
------------------------------------------------------------------------------

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

Date: 18 Dec 91 17:06:50 GMT
From: duke!news.duke.edu!acpub.duke.edu![e-mail]
Subject: NEC PC-8401A-LS (Starlet) FORSALE
To: [e-mail]

  Recently someone wrote me regarding a CP/M portable I have and commented:
> I run vhf packet using the [same] cp/m computer and a pocket size packet unit.
> Very portable and usable: many hams would dearly love a similar setup!

  SO I took it into my head to post here.

   The NEC Starlet is 5 years old, fully CP/M compatible (Z80), with the
semi-standard CP/M screen size of 16 X 80.  It's a clamshell machine resembling
the Tandy 200, and many of the IBM laptops on the market today (particularly
the Toshibas).  The screen is LCD, larger than the previous Starlet model, and
not backlit.  That's the only drawback to this machine.  The keyboard is
phenomenal, and the machine runs OVER 8 hours on NiCads.  The machine can be
configured to auto-sleep, an option that increases battery life effectively to
days; the machine ALWAYS "auto-resumes" whether it sleeps or is shut off.
There's an extra internal battery that will preserve dynamic RAM for 5 days
after AC is cut off and NiCads go dead.
   Storage is on a 256K RAMdisk cartridge that has a lithium cell preserving
the contents for >>5 years<<.  I have found the cartridge to be FAR more
reliable than any floppy I have ever used.  It has never lost a byte.
Internal and datapack batteries were replaced 2 years ago (easy to do) and
have 3 years left to them.  They cost about $3 each at your local pharmacy.
   The machine has software on ROM: scaled-down versions of WordStar, CalcStar,
Filer, and a Telecom program.  Built-in 300 baud modem, and a serial port that
can pull 9600 baud (the telecom program can use either internal modem, external
modem, or direct link through serial port, and of course other CP/M comm
programs are out there).  I use a null-modem cable to transfer data to a PC,
and a simple wordstar-->WordPerfect conversion program (public domain) does
the rest for me.
   NEC made a floppy-disk unit, 1200baud modem, and other options for the
Starlet, and these should be "out there" somewhere -- it was a pretty popular
machine in some design industries and for roving business-types.

  SO:  Starlet, 256K RAM Cartridge, null-modem cable, 4 hi-capacity NiCads,
Ni-Cad charger, AC adaptor, misc PC/Starlet software (not much), all original
manuals.  Asking $150 total, (shipping included in price).
--
Mike Scher                      [e-mail]
Duke University -- Durham, NC:  Law and Cultural Anthropology
This post expressly not for use as toilet tissue.
(c) 1991 - All lefts deserved.

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

Date: 19 Dec 91 05:49:23 GMT
From: munnari.oz.au!metro!seagoon.newcastle.edu.au!jupiter.newcastle.edu.au![e-mail]
Subject: NET/Mac and slip question
To: [e-mail]

I am trying to set up a slip link using the Macintosh version of KA9Q "NET/Mac".
However it is giving me a bit of trouble... Can anyone supply me with some
example "attach" commands for autoexec.net for slip?

Thanks indeed!

Gary, VK6XQ/VK2GWC
------------------------------------------------------------------------------
Gary W. Carroll. Systems Manager,                  [e-mail]
         Department of Computer Science,   Ph (049) 21 6175
         University of Newcastle,
         Newcastle, 2308, Australia.       Packet Radio: VK2GWC@VK2CZZ
------------------------------------------------------------------------------

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

Date: 19 Dec 91 05:04:06 GMT
From: network.ucsd.edu!usc!cs.utexas.edu!utgpu!cunews!nrcnet0!bnrgate!bwdls58![e-mail]
Subject: NOS for Microsoft Windows v3?
To: [e-mail]

  Has anyone ported KA9Q NOS software to Microsoft windows?  If so can
you point me to the source and/or binaries?  If not, any ideas on the
feasibility and magnitude of the effort to do it?

Thx & 73,
John
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
| John R. Moseby                        | Email   : [e-mail]           |
| BNR Inc.  Dept. 3J12                  | Radio   : ka4smc                  |
| P.O. Box 13478                        | Opinions are like.....!           |
| Research Triangle Park, NC USA 27709  | These opinions are mine not BNR's |
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

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

Date: 20 Dec 91 14:48:17 GMT
From: network.ucsd.edu!usc!cs.utexas.edu!tamsun!cs.tamu.edu![e-mail]
Subject: NOS for Microsoft Windows v3?
To: [e-mail]

In article <[e-mail]>, [e-mail] (John Moseby) writes:
|>
|>   Has anyone ported KA9Q NOS software to Microsoft windows?  If so can
|> you point me to the source and/or binaries?  If not, any ideas on the
|> feasibility and magnitude of the effort to do it?
|>
|> Thx & 73,
|> John

There really oughta be a FAQ....
Try ucsd.edu in /hamradio/packet/ka9q/incoming.  WNOS 3A is in there.
Have your Borland C 2.0 ready....
Send a message to [e-mail]; message body: Subscribe tcp-group
for the tcp-group mailing list.
73,
    Kurt

--
Kurt Freiberger, wb5bbw   [e-mail]   409/847-8607  fax:[phone]
Dept. of Computer Science, Texas A&M University      DoD #264: BMW R80/7 pilot
"We preserve our freedom using three boxes: ballot, jury, and cartridge."
      *** Not an official document of Texas A&M University ***

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

Date: 19 Dec 91 21:47:04 GMT
From: network.ucsd.edu!sdd.hp.com!cs.utexas.edu!asuvax!ncar!hsdndev!bunny![e-mail]
Subject: SpreadSpectrum and Packet
To: [e-mail]

Tim=J.=[e-mail] writes:
>1) The center frequency or non spead signal must (by FCC rules) carry the
>data.  You may choose narrow band FM or a wider signal to suit your data
>needs.
>2) The PN sequence must be one of the three sequences approved by the FCC.
>3) You can choose a chip rate (divider output frequency) to suit your needs,
>but you must confine your signal to the given band.

When I was at the ARRL Computer Networking Conference this year I heard
someone mention that the FCC eliminated the requirement to use one of the
three "approved" PN sequences.  I also remember that they eased a few other
requirements as well, but I don't remember which ones.

Does anyone have more detailed information?
--
Dave Pascoe   |  [e-mail]
KM3T          |  Tel: [phone]

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

Date: 18 Dec 91 16:00:09 GMT
From: ncar!hsdndev!bunny![e-mail]
Subject: Spread spectrum data modem
To: [e-mail]

I don't have time to write extensively on it right now, but there is a
way to do this....it's called a RAKE modem.  I'll write more in a day or
so..
--
Dave Pascoe   |  [e-mail]
KM3T          |  Tel: [phone]

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

Date: 20 Dec 91 21:53:16 GMT
From: network.ucsd.edu!swrinde!mips!atha!aupair.cs.athabascau.ca![e-mail]
To: [e-mail]

References <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject : Re: Extended KISS spec


I agree that checksumming was an oversight. Even in its intended
application of sending encapsulated IP frames, the requirement
to send raw AX.25 packets was there from the very beginning (AX.25
ID frames).

When KISS was developed, the state of the art in TNC's was a single
radio port running 2400 baud. KISS was sufficient to handle that.
It's naive to think that the state of the art wouldn't progress,
though, and it has. Part of that advancement has been the introduction
of HDLC hardware interfaces. However the concept of the KISS TNC
was so elegant that it has spawned an enormous install base (vs.
the direct hardware approach). It's not fair to now tell these
people that they must forgo their current TNC interfaces and adopt
a hardware approach when they want capabilities like medium speed
(9600/19200 bps) and multiple ports, soley due to altruistic
considerations.

I, too, don't want to see tons of excess baggage added to KISS, however
there are some very useful extensions to the protocol being proposed
that will significantly help the existing user base achieve better
throughput (having the TNC asynchronously notify the host when it
*actually* sends a packet over the RF link is a *big* win on busy
channels if the host uses this information to control its retry
timers).

Face it Phil, you've created a monster. Given your experience in
the field, all I can say is "you should have known better" :-)
If you want to freeze KISS as is that's fine by me. I have no
objection to inventing a new protocol, with a new name, that just
happens to be backwards compatible with KISS. Of course, in a few
years I will be kicking myself in the head for having done so.
Such is the price of progress.

And for the record, I too am very much in favour of the hardware
based approach. If it's an option, use it!

--
       atha!cs.athabascau.ca!lyndon || [e-mail]
            Packet: [e-mail]
    Admittedly, the CA domain registrars seem a bit overzealous in
     their quest to preserve the purity of the namespace.   --Mark Moreas

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

Date: 20 Dec 91 23:24:58 GMT
From: sun-barr!cronkite.Central.Sun.COM!waveguide.Central.Sun.COM![e-mail]
To: [e-mail]

References <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject : Re: Extended KISS spec


Let's not forget those (like me :-) who don't use PCs on the air.  My UNIX
machine uses KISS to talk to a pair of TNCs not because its so great or
because I especially like KISS, but because I don't have a PC bus to plug
these wonderful cards into, and I don't think I want to re-write much of NOS
into the UNIX kernel so it can speak AX25.

I could sure use some extensions to KISS.  I'd  be delighted to participate
in discussions of the KISS++ protocol -- so how do we start?

Mike KA9WSB

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

Date: 21 Dec 91 00:16:31 GMT
From: network.ucsd.edu!swrinde!mips!atha!aunro!aupair.cs.athabascau.ca![e-mail]
To: [e-mail]

References <[e-mail]>, <[e-mail]>, <kl4uuaINN50g@cronkite>
Subject : Re: Extended KISS spec

[e-mail] (Mike Westerhof SE Chicago Metro) writes:

>I could sure use some extensions to KISS.  I'd  be delighted to participate
>in discussions of the KISS++ protocol -- so how do we start?

Personally, I would like to see us follow the IETF model whereby we
set up a working group to define the new spec, then build a reference
implementation to shake out the new protocol, and use our experience
in the field trials to correct any deficiencies in the spec. Once
it's stable we can release the published version of the spec (and
probably a final reference implementation for something like the
TNC-2).
--
       atha!cs.athabascau.ca!lyndon || [e-mail]
            Packet: [e-mail]
    Admittedly, the CA domain registrars seem a bit overzealous in
     their quest to preserve the purity of the namespace.   --Mark Moreas

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

End of Packet-Radio Digest V91 #329
******************************
Date: Sun, 22 Dec 91 04:30:02 PST
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 #330
To: packet-radio


Packet-Radio Digest         Sun, 22 Dec 91       Volume 91 : Issue 330

Today's Topics:
       Another Green Ham-Packeteer Wanna-Be looking for advice
             BCNodes via digi's ?? how ?
              Comments on PK-88
              DSY modem update?
           Extended KISS protocol (2 msgs)
              Extended KISS spec
              Extensions to KISS
       SatTrak - Satellite Tracker posted to comp.binaries.mac

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 Dec 91 22:29:00 GMT
From: network.ucsd.edu!usc!cs.utexas.edu!tamsun!summa.tamu.edu![e-mail]
Subject: Another Green Ham-Packeteer Wanna-Be looking for advice
To: [e-mail]

Any information you can send my way would be greatly appreciated.
I'm at A&M and we have a ham club here but I am never able to make
the meetings.

I'm interested in the codeless licenses since I do not have time
or patience to become used to code.

-Steve Suehs

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

Date: 22 Dec 91 07:44:28 GMT
From: network.ucsd.edu!swrinde!mips!spool.mu.edu!munnari.oz.au!yoyo.aarnet.edu.au!sirius.ucs.adelaide.edu.au!levels![e-mail]
Subject: BCNodes via digi's ?? how ?
To: [e-mail]

Anyone got some idea's on how to bcnodes using nos when your nearest node
is 2 digi hops away ?? Nos just bcnodes > NODES., Ive tried adding an ax
route for NODES ... :-|

Comments about the sense in doing this > /dev/null
Comments about how to do this most welcome at : [e-mail]

73's ... Rob vk5xxx

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

Date: 21 Dec 91 12:00:57 GMT
From: network.ucsd.edu!usc!wupost!bcm!lib!oac.hsc.uth.tmc.edu![e-mail]
Subject: Comments on PK-88
To: [e-mail]

I'm currently running a PK-88 on the local IP network; it does fine, except
for one problem: I can't set the MTU above 984. The TNC throws away any
packets with a data portion longer than 1K. Other folks with true TNC-2 clones
don't have that problem.

--
Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can
[e-mail]      | adequately be explained by stupidity.
  "Last time I tried to eat a Dodge Omni, it damn near ran me over!" --
     Josh Fielek, when told that most people are omnivores

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

Date: 22 Dec 91 04:01:08 GMT
From: [e-mail]
Subject: DSY modem update?
To: [e-mail]

Has anyone looked into updating the DSY design?  It's reasonably sound,
but it uses really old chips.  It seems to me that the design could be
updated to make use of newer chips and yield a greatly reduced component
count.  Perhaps we could even convince some grad student studying VLSI
design to make up a custom chip, perhaps a gate-array/ASIC to do all the
digital stuff, and use some newer analog stuff to cut 'way down on the
number of parts.

A few simple changes occur to me - it's perhaps possible to use some
other type of modulator which would require fewer adjustments, and the
demodulation might well be done at 10.7 MHz, thus eliminating another
conversion step, crystal oscillator, filter, etc.

Any takers?
    - Brian

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

Date: 21 Dec 91 01:13:23 GMT
From: network.ucsd.edu!swrinde!mips!atha!aunro!alberta!access.usask.ca!herald.usask.ca![e-mail]
Subject: Extended KISS protocol
To: [e-mail]

I may have missed seeing mention of this, but in my view, one absolutely
essential feature of a new KISS protocol is one that allows the computer
to interrogate the TNC to ask it how many unsent packets its (the TNC) got.
The computer has no way of telling if the channel is blocked and will
keep sending retry packets to the TNC at each timeout.
Pete [e-mail]           VE5VA

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

Date: 21 Dec 91 17:46:47 GMT
From: network.ucsd.edu!usc!wupost!darwin.sura.net!haven.umd.edu!ni.umd.edu!sayshell.umd.edu![e-mail]
Subject: Extended KISS protocol
To: [e-mail]

In article <[e-mail]> [e-mail] (Peter Hardie) writes:
>I may have missed seeing mention of this, but in my view, one absolutely
>essential feature of a new KISS protocol is one that allows the computer
>to interrogate the TNC to ask it how many unsent packets its (the TNC) got.
>The computer has no way of telling if the channel is blocked and will
>keep sending retry packets to the TNC at each timeout.

Why?

A real transport protocol will perform an exponential backoff as it
begins to perform retransmissions.  Won't the lack of an ACK do the
same thing as having the TNC tell you it can't transmit the packet?
What will you do differently?

louie
WA3YMH
"Transport protocols 'R' us."

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

Date: 21 Dec 91 19:38:13 GMT
From: [e-mail]
Subject: Extended KISS spec
To: [e-mail]

Phil wrote:
> If you do publish a new spec, you should call it something other than
> "KISS", since that description (Keep It Simple Stupid) would no longer
> apply. The whole purpose behind KISS was to provide the *bare minimum*
> [..]
> Checksumming is about the only feature that I might even think about
> adding to the KISS TNC spec were I to do it all over again. The wire

Here in Stuttgart, Germany, we have done exactly this. We built a KISS
version, which adds a CRC16 to the frames. The protocol used to switch on
this feature is backwards compatible, so the host can distinguish between
KISS and SMACK (Stuttgart Modified Amateur Checksummed Kiss).

The spec will be published in the near future. Please direct questions
to [e-mail], but I won't be able to answer before mid of
january.

Jan
--
   Jan Schiefer, DL5UE, Degerlocherstr. 5, 7000 Stuttgart 70, Germany
              [e-mail]
 "pronI auxDoNot vbLike adjHungarian nNotation advAtAll excl!"        -me

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

Date: 21 Dec 91 20:42:18 GMT
From: network.ucsd.edu!sdd.hp.com!mips!atha!aunro!alberta!access.usask.ca!herald.usask.ca![e-mail]
Subject: Extensions to KISS
To: [e-mail]

> From: [e-mail] (Louis A. Mamakos)
> Subject: Re: Extended KISS protocol
> In article <[e-mail]> [e-mail]
> (Peter Hardie) writes:
> >I may have missed seeing mention of this, but in my view, one absolutely
> >essential feature of a new KISS protocol is one that allows the computer
> >to interrogate the TNC to ask it how many unsent packets its (the TNC) got.
> >The computer has no way of telling if the channel is blocked and will
> >keep sending retry packets to the TNC at each timeout.
>
> Why?
>
> A real transport protocol will perform an exponential backoff as it
> begins to perform retransmissions.  Won't the lack of an ACK do the
> same thing as having the TNC tell you it can't transmit the packet?
> What will you do differently?
>
> louie
> WA3YMH
> "Transport protocols 'R' us."

But the lack of an ACK means that you should send an RR packet to
interrogate the other end.
To clarify: when the whole protocol is in the TNC and the computer sends a
data packet to the TNC, the TNC transmits the packet when the channel is
clear and then sets a timer. If the timer expires then the TNC usually
will send an RR packet enquiring as to the status of the packet it sent.
If the channel is blocked when it tries to send the RR then it just backs
off and retries the RR later.
But when you put most of the protocol in the computer, it can't see the channel
at all and most implementations I have seen (such as MSYS) have no choice but
to do something like this: send the data packet to the TNC and set a retry
timer in the computer.
If there's no ack by the time the timer expires then either send the packet
again (if it is small) or send the RR packet. If there's no response at the
next retry time then send RR again. It's part of the AX.25 protocol, but
the problem is that KISS splits the protocol into two pieces in such a way
that the computer does not have enough info to behave properly all the time
and this is why (especially on HF) you can see a station send a single
transmission consisting of several RR packets all for the same packet number.
The computer couldn't see that the TNC was not Txing because of a congested
channel and kept timing out and sending the RRs to the TNC which simply
stored them all up until it could finally spit them out.
This is why I prefer the WA8DED protocol over KISS as far as implementation
goes because on a per-conection basis WA8DED allows you to interrogate
the TNC to find out how many unsent packets it has and thus the computer
can send, in the simplest case, one packet per connection and when its
retry timer expires it first asks the TNC how many packets it has in the
buffer for that connection. If the answer is one, then the computer does
nothing because the packet hasn't made it into the aether yet. If the answer
is zero and ACK hasn't been received then the computer can send RR (and
again interrogate at timer expiration to make sure the RR was sent before
stuffing another into the TNC).
KISS has some advantages over WA8DED, such as the fact that it can be
found in, or made available for, practically every TNC there is.
But to repeat my earlier statement, the *only* extension I believe is
*essential* to KISS is to allow the computer to ask it how many unsent
packets it has. This will then allow those who write KISS drivers to
make their software handle a clogged channel properly.
Hope I made myself clearer - I'm still recovering from a royal dose of
the flu!
Merry Christmas all.

Pete [e-mail]

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

Date: 21 Dec 91 19:42:20 GMT
From: network.ucsd.edu!usc!zaphod.mps.ohio-state.edu!qt.cs.utexas.edu!cs.utexas.edu!asuvax!hrc!gtephx![e-mail]
Subject: SatTrak - Satellite Tracker posted to comp.binaries.mac
To: [e-mail]

I just finished a program called SatTrak for the Macintosh. It's
primarily a satellite tracker, but it does much more (see below).
It's targeted towards hams, but others may also find it useful.

It has been posted to comp.binaries.mac and sent to the sumex
archives, and should appear in the near future.  Requires Mac Plus or
better, System 6.0 or better.

SatTrak will

    - Generate a detailed, customizable plot of when a particular
      satellite will be visible from a given location, it's position,
      altitude, and many other items

    - Given operation mode data for a satellite, tells you what mode
      the satellite is operating in

    - Generate a list of satellites currently visible from a given
      location

    - Display (on a world map) a satellites position at any point in
      time

    - Display in real time (on a world map) a satellites current
      location

    - Generate beam headings between two locations

    - Find grid identifier (Maidenhead grid locator) of any location

    - Generate MUF plots between any two locations for any day

    - Generate band openings from a selected location to various
      points around the world

    - Find the line-of-sight distance between antennas at two
      elevations

    - Given a frequency, gives the half and quarter wavelengths, and
      second and third harmonic frequencies - and shows a simple
      dipole antenna design (HF or VHF)

    - Convert NASA format element sets to Keplerian format

    - Print or save windows to a file, copy text or pictures to other
      programs

    - Saves data for up to 200 satellites, 20 ground locations, and
      mode data for up to 20 satellites

    - Preferences (metric or english, UTC or local, data to output)

    - Help panels

    - Color pictures.  System 7 friendly (sorry, no balloon help yet)

(NOTE: Print, copy, and save are disabled in this version.  If you pay
the shareware fee, I'll give you a password to enable these functions)

If you can't download from the network, send a floppy (800K or
1.4M) and a prepaid mailer to the following address and I'll send you
the program:

SatTrak
Mike Pflueger
6207 W. Beverly Ln.
Glendale, AZ  85306

Enjoy!


--
Mike Pflueger @ AG Communication Systems (formerly GTE Comm. Sys.), Phoenix, AZ
UUCP: {...!ncar!noao!asuvax | uunet!samsung!romed!asuvax | att}!gtephx!pfluegerm
Work: 602-582-7049        FAX: [phone]     Home: 602-439-1978
Packet: WD8KPZ @ KB7TV.AZ.USA.NA  Internet: gtephx![e-mail]

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

Date: 21 Dec 91 03:54:24 GMT
From: eos!aio!mec.jsc.nasa.gov![e-mail]
To: [e-mail]

References <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject : Re: Extended KISS spec

In article <[e-mail]> [e-mail] writes:
>In article <[e-mail]>, [e-mail] (Lyndon Nerenberg) writes:
>|> [e-mail] (Dave Horsfall) writes:
>|>
>|> >According to the blurb that comes with the G8BPQ switch stuff, it relies
>|> >on an extended KISS implementation that uses (hitherto unheard-of :-)
>|> >features such as checksumming, flow control, polling, and ACKing etc.
>|>
>|> >Is any of this formally documented?
>|>
>|> I sent Phil some mail a while back asking if he had plans to publish
>|> a "Son of KISS" spec. He did a very good job of evading the question :-)
>|> I am getting concerned about all these unofficial extensions. The
>|> potential for collisions in the use of new KISS commands is much too
>|> high already.
>
>If you do publish a new spec, you should call it something other than
>"KISS", since that description (Keep It Simple Stupid) would no longer
>apply. The whole purpose behind KISS was to provide the *bare minimum*
>of hooks to allow a PC without an HDLC interface to use a TNC to
>generate and receive arbitrary HDLC frames. Flow control, polling and
>ACKing were (and are) very much against the KISS principle, and Mike
>(K3MC) and I deliberately excluded them. They really don't belong there.
>
>Checksumming is about the only feature that I might even think about
>adding to the KISS TNC spec were I to do it all over again. The wire
>between the host and TNC typically does have a low error rate, but
>unfortunately people have been trying to use KISS TNCs with programs
>and hardware that isn't quite up to handling solid 9600 bps (or
>whatever) input streams.  Occasionally characters are lost and people
>blame the KISS TNC for this when of course the fault is elsewhere.
>Also, KISS was primarily intended for TCP/IP, which has its own header
>checksums.
>
>And of course KISS was only meant as a stopgap hack until true HDLC
>interfaces became available. They are now available, at least for the
>PC, and I strongly advocate that anyone trying to decide between an
>external KISS TNC and a dedicated HDLC board (e.g., DRSI PCPA, PACCOMM
>PC-100, etc) opt for the latter.

I tend to vote with Phil here.   The issue is not whether there should be an
extended KISS spec:  It obviously already exists.  What is actually the issue
is what it is, since Phil is correct.  IT AIN'T KISS, because it's no longer
"simple".

Using the hardware options, where available, is one obvious approach.  The
other is for BPQ and others to identify the "extensions", codify them, and
write the extensions into a nwe code set.  If they persist in calling it a
KISS extension, then it MUST be backward compatible.  If it's not called
"KISS-something" then that requirement can be waived.

Let's use KISS for what it was intended for, and not take the original author
to task for taking a position that's easy to understand and defend.

73, Gerry

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

Date: 21 Dec 91 05:58:17 GMT
From: network.ucsd.edu!swrinde!mips!atha!aunro!ve6mgs![e-mail]
To: [e-mail]

References <[e-mail]>, <kl4uuaINN50g@cronkite>, <[e-mail]>
Subject : Re: Extended KISS spec

[e-mail] (Lyndon Nerenberg) sez:
>Personally, I would like to see us follow the IETF model whereby we
>set up a working group to define the new spec, then build a reference
>implementation to shake out the new protocol, and use our experience

Who is going to pay this working group :-) Anarchy is cheaper :-).

Great idea, who can we railroad into this cause and where do I send the
wishlist to ... (Packet transmitted, S unit reading, power scale for
transmitted packet)

Ciao, 73 de VE6MGS/Mark -sk-

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

End of Packet-Radio Digest V91 #330
******************************
Date: Mon, 23 Dec 91 04:30:02 PST
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 #331
To: packet-radio


Packet-Radio Digest         Mon, 23 Dec 91       Volume 91 : Issue 331

Today's Topics:
              Comments on PK-88
              DSY modem update?
            Extended KISS protocol (Why?)
               Getting started
              NOS "wampes" for ISC unix
         What am I missing for PACSAT work ?

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

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

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

Date: 22 Dec 91 14:05:29 GMT
From: news.hawaii.edu!mpg.phys.hawaii.edu![e-mail]
Subject: Comments on PK-88
To: [e-mail]

In article <[e-mail]> [e-mail] (Jay Maynard) writes:
>I'm currently running a PK-88 on the local IP network; it does fine, except
>for one problem: I can't set the MTU above 984. The TNC throws away any
>packets with a data portion longer than 1K. Other folks with true TNC-2 clones
>don't have that problem.

The Kantronics KPC-2400 also has a similar limitation.


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

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

Date: 22 Dec 91 16:49:36 GMT
From: network.ucsd.edu!swrinde!emory!wa4mei!ke4zv![e-mail]
Subject: DSY modem update?
To: [e-mail]

In article <[e-mail]> [e-mail] (Brian Kantor) writes:
>Has anyone looked into updating the DSY design?  It's reasonably sound,
>but it uses really old chips.  It seems to me that the design could be
>updated to make use of newer chips and yield a greatly reduced component
>count.  Perhaps we could even convince some grad student studying VLSI
>design to make up a custom chip, perhaps a gate-array/ASIC to do all the
>digital stuff, and use some newer analog stuff to cut 'way down on the
>number of parts.
>
>A few simple changes occur to me - it's perhaps possible to use some
>other type of modulator which would require fewer adjustments, and the
>demodulation might well be done at 10.7 MHz, thus eliminating another
>conversion step, crystal oscillator, filter, etc.
>
>Any takers?
>       - Brian


We've discussed several changes to the basic design from time to time,
but those common old parts are easy  to find and replacing debugged
board designs is costly. The three adjustments on the transmit encoder
allow you to compensate for a multitude of sins of component tolerances
in the entire transmit chain. It does require a simple AF grade scope
to get them set right, but you only have to do it once. A gate array
could reduce the parts count on the encoder by 2, or an ASIC could
reduce the count by 4, but puts you in a single source situation for
field replacement parts. Gate arrays wouldn't help on the decoder or
RF boards.

THE FOLLOWING IS MY PERSONAL OPINION ONLY, AND DOESN'T REFLECT OFFICAL
GRAPES POSITIONS.

A couple of changes that would be worthwhile (IMHO) would be to use a
newer DAC chip that includes the latch and output amp, and go to
Minicicuits type diode ring balanced modulators so the output could be
on-channel instead of at 29 Mhz. This would eliminate the need for a
costly external transmit converter, though at the cost of additional
buffer stages and a power brick. This would require slightly different
RF boards for each band. That reduces the universal appeal of the modem
somewhat, but with the problem of locating suitable transverters being
what it is, I think it's a good idea.

The major drawback to eliminating the 455 khz stage in receive is
the necessity for a band filter with the proper group delay. This
was a major stumbling block in the original design. By good fortune,
it was possible to design a filter with the desired characteristics
at 455 khz with off the shelf parts. Tektronix is showing an integrated
filter with the proper characteristics at 10.7 Mhz, but the order
quantities required are unreasonable for us and being stuck with a
single source part is another consideration. If a good, readily available,
filter design comes along, then eliminating the 455 khz stage is
feasible. Staying with the theme of on-channel operation, the
first mixer could be changed to operate at channel frequency and
a helically filtered preamp, like the nice Hamtronics units, could
form the front end. Single conversion to 10.7 Mhz from UHF would
be prone to image problems though.

Changing the boards to surface mount, and constructing a motherboard
to eliminate the harness and house an on board power supply would
simplify packaging problems and reduce the size of the modem. The
modular nature of the original design was deliberate, however. It allows
for wide flexibility in operations. The transmit and receive chains
can be totally separated for split site or crossband usage. The
original choice of 29 Mhz for the modem input and output pushed
the more difficult RF circuitry onto an external transverter and
allowed one modem design to be used on any band for which a transverter
was available. With the advent of MMIC UHF amplifiers and packaged mixers,
and with the decline in availability of cheap transverters, integrating
the on-channel electronics into the RF board begins to look attractive.
But we don't want to destroy the modular nature of the unit completely,
so some duplication of circuitry is inevitable. We also have to keep
in mind the grade of test equipment available to people putting the
kits together. Today, only a modest performance scope is required. If
we start putting UHF circuitry on the modem, access to a spectrum
analyser would become necessary, or at least desirable.

Gary KE4ZV

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

Date: 22 Dec 91 20:49:01 GMT
From: network.ucsd.edu!swrinde!mips!atha!aunro!ve6mgs![e-mail]
Subject: Extended KISS protocol (Why?)
To: [e-mail]

[e-mail] (Peter Hardie) writes:
>I may have missed seeing mention of this, but in my view, one absolutely
>essential feature of a new KISS protocol is one that allows the computer
>to interrogate the TNC to ask it how many unsent packets its (the TNC) got.

and [e-mail] (Louis A. Mamakos) sez:
>Why?
>
>A real transport protocol will perform an exponential backoff as it
>begins to perform retransmissions.  Won't the lack of an ACK do the
>same thing as having the TNC tell you it can't transmit the packet?
>What will you do differently?

Well, this issue is a bit clouded. The TNC may, due to channel usage, not
transmit the packet for a long period of time. The software talking to the
TNC does not know if it has not received a ACK because it failed to transmit
yet or if the message failed to propogate. If it failed to transmit, it is
far better to wait. If it failed because of some other reason on the air,
then of course you want a retransmission.

On a busy channel, where your packet may be held for an extended period of
time in the TNC, the link may be dropped, when in fact a bit of patience is
called for. One could argue that it is a bad link (slow). But I think a
timer makes more sense if it starts once the packet is on the air, rather
than when it got to the TNC.

Ciao, 73 de VE6MGS/Mark -sk-

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

Date: 23 Dec 91 05:30:34 GMT
From: ricevm1.rice.edu![e-mail]
Subject: Getting started
To: [e-mail]

I would like to get into Packet Radio. What TNC is most popular.
I looking at theKantronics KAM, MFJ 1278, and AEA PK-232MBX
Pleae tell my what you think.

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

Date: 23 Dec 91 07:42:10 GMT
From: xyzoom![e-mail]
Subject: NOS "wampes" for ISC unix
To: [e-mail]

I would be interested in corresponding with anyone running
"isc-wampes" NOS for ISC Unix.

--Rob


--
Rob Lingelbach  KB6CUN  [e-mail] -or- ...!uunet!xyzoom!rob
      2660 Hollyridge Dr L.A. CA 90068  voice: 213 464-6266
"I care not much for a man's religion whose dog or cat are not the
better for it."  --Abraham Lincoln

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

Date: 23 Dec 91 06:05:02 GMT
From: [e-mail]
Subject: What am I missing for PACSAT work ?
To: [e-mail]

I'm very interested in getting started with 9600 baud packet via the
PACSATS. If I'm not mistaken, this can be done with an FM uplink on both UHF
and VHF and non-directional antennas. I thought about purchasing the Kenwood
241/441 pair for local FM work and I need to know if these xcvrs will work
for PACSAT use ? Also - need feedback on what 9600 baud modem is best suitable
with an AEA PK-232 (G3RUH, Pac-comm, MFJ, TAPR, etc.)
Any comments/sugjestions are welcome.
Thanks es 73,
Rich
WB2JBS

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

End of Packet-Radio Digest V91 #331
******************************
Date: Tue, 24 Dec 91 04:30:03 PST
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 #332
To: packet-radio


Packet-Radio Digest         Tue, 24 Dec 91       Volume 91 : Issue 332

Today's Topics:
              DSY modem update?
            Extended KISS protocol
             HELP! For MFJ1278 controller
        J-pole antenna for Microsats (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: 23 Dec 91 15:47:04 GMT
From: network.ucsd.edu!usc!wupost!udel!sbcs.sunysb.edu![e-mail]
Subject: DSY modem update?
To: [e-mail]

>In article <[e-mail]> [e-mail] (Brian Kantor) writes:
>Has anyone looked into updating the DSY design?  It's reasonably sound,
>but it uses really old chips.  It seems to me that the design could be
>updated to make use of newer chips and yield a greatly reduced component
>count.  Perhaps we could even convince some grad student studying VLSI

    [original posting text deleted]

In article <[e-mail]> [e-mail] (Gary Coffman) writes:
>The major drawback to eliminating the 455 khz stage in receive is
>the necessity for a band filter with the proper group delay. This
>was a major stumbling block in the original design. By good fortune,
>it was possible to design a filter with the desired characteristics
>at 455 khz with off the shelf parts. Tektronix is showing an integrated
>filter with the proper characteristics at 10.7 Mhz, but the order
>quantities required are unreasonable for us and being stuck with a
>single source part is another consideration. If a good, readily available,
>filter design comes along, then eliminating the 455 khz stage is
>feasible. Staying with the theme of on-channel operation, the
>first mixer could be changed to operate at channel frequency and
>a helically filtered preamp, like the nice Hamtronics units, could
>form the front end. Single conversion to 10.7 Mhz from UHF would
>be prone to image problems though.

    Can you elaborate on the design parameters for the existing 455 mHz
    filter, eg phase chracteristics, passband ripple, etc?  This would
    greatly benefit those of us contemplating doing an update pass on
    the dsy modem.  Although expensive in Q1, Sawtek has a line of both
    70 mHz & 140 mHz filters that would allow for a better choice of
    IF in an "on channel" design.

>Gary KE4ZV


                        Thanks,

                        Rick Spanbauer
                        wb2cfv
                        [e-mail]

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

Date: 23 Dec 91 23:56:34 GMT
From: network.ucsd.edu!qualcom.qualcomm.com!qualcom.qualcomm.com![e-mail]
Subject: Extended KISS protocol
To: [e-mail]

In article <[e-mail]>, [e-mail] (Louis A. Mamakos) writes:
|> A real transport protocol will perform an exponential backoff as it
|> begins to perform retransmissions.  Won't the lack of an ACK do the
|> same thing as having the TNC tell you it can't transmit the packet?
|> What will you do differently?

Furthermore, a real transport protocol will also measure and keep
track of the intervals between transmission of a data packet and
receipt of the corresponding ACK, and it will set its retransmission
timeout appropriately. TCP has done this since day 1 (although the
algorithms have been steadily refined over the years) and my own AX25
implementation (in NOS) uses the same algorithm.

When the protocol does round-trip timing, it doesn't matter whether
the packet is stuck in the local TNC, waiting for the channel to
clear, or whether its acknowledgement is stuck in the remote TNC for
the same reason (something you can't detect by simply querying the
local TNC).  It automatically takes into account ALL delays
encountered by the packet and its acknowledgement.

As for packets piling up in the TNC because of a busy channel, I'm
coming more and more to the conclusion that, on simplex channels at
least, "data carrier detect" is at best useless and more often
actually counterproductive to the full, efficient use of the channel.
I.e., CSMA just doesn't work.

Of course, it will take new channel access protocols and algorithms to
deal with this, and that's another subject.

Phil

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

Date: 23 Dec 91 21:55:29 GMT
From: network.ucsd.edu!sdd.hp.com!spool.mu.edu!snorkelwacker.mit.edu!world!eff!iWarp.intel.com|ichips!intelhf![e-mail]
Subject: HELP! For MFJ1278 controller
To: [e-mail]

      I have a new MFJ1278 multimode controller. I've successfully
    used it on every mode except SSTV. Seems most people are sending
    72 second pictures, now, and the multicom/MFJ package only
    handles 36 sec. max. I have yet to get a recognizable picture
    on 14.230/233! I'm not even sure I'm tuning in properly.

    Any help/suggestions appreciated.

        George  WB6YZZ

        [e-mail]

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

Date: 23 Dec 91 15:20:19 GMT
From: pa.dec.com!nntpd.lkg.dec.com!sousa!omdemo.enet.dec.com![e-mail]
Subject: J-pole antenna for Microsats
To: [e-mail]

    I am interested in building the J-pole (or similar) antenna  that
    AMSAT has detailed in their publications.  I have tested a
    conglomeration of misc. antennas including a Ringo, 1/4 wave whip,
    turnstyle, dual 11 elem cushcraft yagis with different polarization,
    etc.  None of these have given very good response.  I know that my
    next purchase needs to be a mast mounted GASfet amp.  However, I
    would like to try the J-pole routne, too.

    I have both azimuth + elevation rotors set up now.  (crude but, hey,
    they work!)

    Are there commercial versions of a dual-band (2m/440)
    J-pole similar to the AMSAT project antenna?  If they weren't too
    expensive, I might just order a kit rather than run all over trying to
    find the proper materials.  Available time for such projects is getting
    scarcer and scarcer!

    Thanks..

        --chas, WB0LJP

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

Date: 23 Dec 91 20:10:35 GMT
From: eos!aio![e-mail]
Subject: J-pole antenna for Microsats
To: [e-mail]

In <[e-mail]> [e-mail] (Chas Hicks) writes:


>       I am interested in building the J-pole (or similar) antenna  that
>       AMSAT has detailed in their publications.  I have tested a
>       conglomeration of misc. antennas including a Ringo, 1/4 wave whip,
>       turnstyle, dual 11 elem cushcraft yagis with different polarization,
>       etc.  None of these have given very good response.  I know that my
>       next purchase needs to be a mast mounted GASfet amp.  However, I
>       would like to try the J-pole routne, too.

>       I have both azimuth + elevation rotors set up now.  (crude but, hey,
>       they work!)

>       Are there commercial versions of a dual-band (2m/440)
>       J-pole similar to the AMSAT project antenna?  If they weren't too
>       expensive, I might just order a kit rather than run all over trying to
>       find the proper materials.  Available time for such projects is getting
>       scarcer and scarcer!

>       Thanks..

>               --chas, WB0LJP

If you have a tourch and some plumbers flux and solder on hand, the dual-band
J-pole can be constructed in less than two hours, and will require less than
$10.00 of materials (all new).  I built one a few months ago even though I
don't have 440 capability.  I was extreemly well pleased with the 2 meter
performance, and pleasently surprised at how quickly it went together.  Oh,
yes, I did already have the co-ax and connectors, but most commercial units
will not provide them anyway.  Give building a try!  it's cheap, easy and
it works.

Good luck & 73

Sarge
--
Jack R. Sargeant, Sr. W0RIJ             These opinions are mine and only mine
Computer Systems Specialist             (unless you wnat to claim them).
Lockheed Engineering & Sciences Co.
Someday (maybe) we'll get E-Mail and FTP access.  In the meantime, we post.

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

End of Packet-Radio Digest V91 #332
******************************
Date: Wed, 25 Dec 91 04:30:02 PST
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 #333
To: packet-radio


Packet-Radio Digest         Wed, 25 Dec 91       Volume 91 : Issue 333

Today's Topics:
            Extended KISS protocol
               new DRSI card PCPA-9600

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 Dec 91 12:42:40 GMT
From: [e-mail]
Subject: Extended KISS protocol
To: [e-mail]

One thing that could be added to KISS without changing the spec (much)
and without breaking anything (I think) is to collapse duplicate
packets.  When a new packet arrives via KISS to be transmitted check to
see if it there is an identical one queued for transmission and dispose
of it if so.  Do this by calculating a CRC of each incoming frame and
comparing it with stored CRCs of frames already in the queue.

This would handle the situation where some heavy traffic appears and
multiple retries are queued before being transmitted.  TCP takes a few
such occurrances to adjust and stupid, non-adaptive AX.25 software
never backs off. With standard KISS what happens is that two or more
copies of the same packet are transmitted when the channel goes clear.
But in TCP or AX.25 there is no point in resending a packet if it hasn't
been transmitted yet.

There is also a pathological degradation that occurs in AX.25 when the
the retry time is short and the packets are long.  The channel gets
busy and several retries stack up.  The total time required to transmit
the queue is so long that more retries arrive and are added to the
queue.  A dozen or more retries may be transmitted and tie up the
channel uselessly.  Then the receiving station has to transmit a dozen
rejects further uselessly clogging the channel and making the problem
even worse.

It is surprising how often I see this phenomenon on our channel. The
only "solution" to the problem with standard KISS is an ad hoc
adjustment of the retry time to much longer periods than would
otherwise be necessary.  Of course, changes to AX.25 such as Phil's can
reduce this problem but that doesn't help the users of other software.

Simply tossing the retries under these conditions would not bother
TCP or anything else I can think of.  So why not?


--
/\/\/\/\/\/
Doug Collinge,  first try: sol.uvic.ca!samisen!djc
        then try:  samisen![e-mail]
        or maybe:  uunet!sol.uvic.ca!samisen!djc
VE7GNU          VE7GNU@VE7VBB.#ISLAND.BC.CAN.NOAM
        Victoria, BC, Canada

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

Date: 24 Dec 91 16:14:18 GMT
From: [e-mail]
Subject: new DRSI card PCPA-9600
To: [e-mail]

Can some one give me the latest info on this new card
it has 1 1200 baud modem on it and 1 9600 non g3ruh modem ?
i have been told it can use normal bandwidth of a fm radio in the same
way as the 1200 baud modems can..
any more info on this new drsi card please..
also whats the cost of it ?
barry dc0hk/g8sau
[e-mail]

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

End of Packet-Radio Digest V91 #333
******************************
Date: Thu, 26 Dec 91 04:30:03 PST
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 #334
To: packet-radio


Packet-Radio Digest         Thu, 26 Dec 91       Volume 91 : Issue 334

Today's Topics:
              DSY redesign ....

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 Dec 91 18:21:44 GMT
From: [e-mail]
Subject: DSY redesign ....
To: [e-mail]

Simple and cheap transverters exist but they all have 144 Mhz IF.
See the ads from DownEast microwave, etc.

If anything redesign is done to the DSY board, the IF should be moved
to 2M.

Roy, AA4RE

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

Date: 25 Dec 91 14:48:50 GMT
From: network.ucsd.edu!usc!wupost!emory!kd4nc!ke4zv![e-mail]
To: [e-mail]

References <[e-mail]>, <[e-mail]>, <[e-mail]>

Reply-To : [e-mail] (Gary Coffman)
Subject : Re: DSY modem update?

In article <[e-mail]> [e-mail] (Rick Spanbauer) writes:
>>In article <[e-mail]> [e-mail] (Brian Kantor) writes:
>>Has anyone looked into updating the DSY design?  It's reasonably sound,
>>but it uses really old chips.  It seems to me that the design could be
>>updated to make use of newer chips and yield a greatly reduced component
>>count.  Perhaps we could even convince some grad student studying VLSI
>
>       [original posting text deleted]
>
>In article <[e-mail]> [e-mail] (Gary Coffman) writes:
>>The major drawback to eliminating the 455 khz stage in receive is
>>the necessity for a band filter with the proper group delay.
>
>       Can you elaborate on the design parameters for the existing 455 mHz
>       filter, eg phase chracteristics, passband ripple, etc?  This would
>       greatly benefit those of us contemplating doing an update pass on
>       the dsy modem.  Although expensive in Q1, Sawtek has a line of both
>       70 mHz & 140 mHz filters that would allow for a better choice of
>       IF in an "on channel" design.

I would like to redirect public efforts away from a redesign of the
excellent existing modem and towards the final needed piece to make
56 kb a widespread success. That item is a simple no-tune transverter
that can follow the modem and can be built by digital folks with limited
test equipment. That appears to be a better immediate course of action
than redesigning what is already a sound product. We've been depending
on the Microwave Modules transverters, and they are often in short supply.
What is needed is a simple transverter that can take 1 mw of 29 Mhz
energy and translate it to 10 watts at 433 Mhz, or 222 Mhz, though the
bandplan isn't very favorable to 56 kb at 222 Mhz since the UPS grab.
The Down East Microwave design for 902 Mhz is already suitable, but we
have lots of existing activity on 433 Mhz with which we would like to
remain compatible. We'd like a board along the lines of the production
RF board. It should be easily dividable into receive and transmit
sections for split site use, and it should be the same form factor as
the RF board for packaging reasons. It should have short TR delay on the
order of 1 ms. Anybody with good ideas in this area is welcome to give it
a shot. And if you are interested, let me know.

Gary KE4ZV

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

Date: 25 Dec 91 17:46:47 GMT
From: network.ucsd.edu!sdd.hp.com!mips!atha!aunro!aupair.cs.athabascau.ca![e-mail]
To: [e-mail]

References <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject : Re: DSY modem update?

I would like to second Gary's suggestion: we desparately need a
*simple* transverter design to get DSY modems up onto 70cm.  I've been
looking around for a year now, and there just doesn't seem to be anything
out there compatible with a `beer budget' experimenter's means.

regards,
Ross  VE6PDQ
--
Ross Alexander  [e-mail]  [phone]  [e-mail]
"Yes: someday - someday soon - every PC owner will be able to wait millions of
cycles for a disk access." Don Lindsay, in <[e-mail]>

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

Date: 25 Dec 91 19:01:54 GMT
From: network.ucsd.edu!usc!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!spool.mu.edu!agate!stanford.edu!CSD-NewsHost.Stanford.EDU![e-mail]
To: [e-mail]

References <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject : Re: DSY modem update?

[e-mail] (Ross Alexander) writes:

>I would like to second Gary's suggestion: we desparately need a
>*simple* transverter design to get DSY modems up onto 70cm.  I've been
>looking around for a year now, and there just doesn't seem to be anything
>out there compatible with a `beer budget' experimenter's means.

Well, you don't REALLY need linear conversion if you are willing to give up
a little bandwidth and go to a constant amplitude waveform.  You can use FM
gear.  The DSY compatible waveform exists.

Marc Kaufman ([e-mail])

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

Date: 26 Dec 91 08:16:19 GMT
From: network.ucsd.edu!usc!wupost!emory!wa4mei!ke4zv![e-mail]
To: [e-mail]

References <[e-mail]>, <[e-mail]>, <[e-mail]>
Reply-To : [e-mail] (Gary Coffman)
Subject : Re: DSY modem update?

In article <[e-mail]> [e-mail] (Marc T. Kaufman) writes:
>[e-mail] (Ross Alexander) writes:
>
>>I would like to second Gary's suggestion: we desparately need a
>>*simple* transverter design to get DSY modems up onto 70cm.  I've been
>>looking around for a year now, and there just doesn't seem to be anything
>>out there compatible with a `beer budget' experimenter's means.
>
>Well, you don't REALLY need linear conversion if you are willing to give up
>a little bandwidth and go to a constant amplitude waveform.  You can use FM
>gear.  The DSY compatible waveform exists.
>
>Marc Kaufman ([e-mail])

That doesn't save a lot of money though. The hard parts are the LO chain
and the receiver noise figure. MMICs and a brick can handle the signal
path with no tweaking and low cost. Getting a stable, clean LO with minimum
tweaking, and a good receive noise figure without tweaking are the hardest
parts.

Gary KE4ZV

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

End of Packet-Radio Digest V91 #334
******************************
Date: Fri, 27 Dec 91 04:30:02 PST
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 #335
To: packet-radio


Packet-Radio Digest         Fri, 27 Dec 91       Volume 91 : Issue 335

Today's Topics:
             J-pole antenna for Microsats

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: 26 Dec 91 13:53:32 GMT
From: [e-mail]
Subject: J-pole antenna for Microsats
To: [e-mail]

In <[e-mail]> [e-mail] (Chas Hicks) writes:>
I am interested in building the J-pole (or similar) antenna  that
>       AMSAT has detailed in their publications.  I have tested a
>       conglomeration of misc. antennas including a Ringo, 1/4 wave whip,
>       turnstyle, dual 11 elem cushcraft yagis with different polarization,
>       etc.  None of these have given very good response.  I know that my
>       next purchase needs to be a mast mounted GASfet amp.  However, I
>       would like to try the J-pole routne, too.

>       I have both azimuth + elevation rotors set up now.  (crude but, hey,
>       they work!)

>       Are there commercial versions of a dual-band (2m/440)
>       J-pole similar to the AMSAT project antenna?  If they weren't too
>       expensive, I might just order a kit rather than run all over trying to
>       find the proper materials.  Available time for such projects is getting
>       scarcer and scarcer!

>       Thanks..

>               --chas, WB0LJP

A simple to build design using "hardware store"  ALUMINUM parts is shown in
(can't remember which) either the 1992 Handbook  (in the satellite section) or
the Satellite Experimenters Handbook (both available from ARRL).

I'm planning on putting one together this weekend, will post results.

           73   es GL
                     Dan  WH6A
InterNet:  [e-mail]
Packet:      WH6A@KB4OWD.#jax.fl.usa.na
LL:                904.281.2059

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

Date: 26 Dec 91 17:44:45 GMT
From: network.ucsd.edu!swrinde!mips!spool.mu.edu!umn.edu!noc.MR.NET!uc.msc.edu!nachos.SSESCO.com![e-mail]
To: [e-mail]

References <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject : Re: DSY modem update?

In article <[e-mail]> [e-mail] (Ross Alexander) writes:
>I would like to second Gary's suggestion: we desparately need a
>*simple* transverter design to get DSY modems up onto 70cm.  I've been
>looking around for a year now, and there just doesn't seem to be anything
>out there compatible with a `beer budget' experimenter's means.

I'll "third" the suggestion with a slight modification...  a 1296 MHz
transverter with 'DSY compatible IF (ie, 29 MHz) would also be very
attractive.  Here in Minneapolis the top data rate is 9600 bps and
we'd obviously like to go faster.  We also have very little
activity on 1296.  A means for running 56Kbps on 1296 MHz would be
very desireable.


--
Chris Elmquist, N0JCF
[e-mail]                [e-mail]
[e-mail]             [phone]@work (8am-5pm CST6CDT)

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

End of Packet-Radio Digest V91 #335
******************************
Date: Sat, 28 Dec 91 04:30:02 PST
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 #336
To: packet-radio


Packet-Radio Digest         Sat, 28 Dec 91       Volume 91 : Issue 336

Today's Topics:
                 Dial-up slip
             Packet-Radio Digest V91 #331

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 Dec 91 20:41:32 GMT
From: network.ucsd.edu!swrinde!zaphod.mps.ohio-state.edu!wupost!think.com!snorkelwacker.mit.edu!thunder.mcrcim.mcgill.edu![e-mail]
Subject: Dial-up slip
To: [e-mail]

Subject : Dial-up SLIP

Hi Merry Xmas,

I am trying to use my 2400 baud modem to contact my university,

I have nos kit installed

I have an IP address, and gateway address supplied by my systems admin.

my pc is a 80386-80387, 25 Mhz, 2 Mbytes RAM, modem connected on com2.

I have been trying to use your syntax in the article of
----------cut here-----------------------------------------------------
Article 2943 of rec.ham-radio.packet:
Path: mcdphx!asuvax!cs.utexas.edu!hellgate.utah.edu!helios.ee.lbl.gov!ucsd
        !ucsdhub!hp-sdd!hplabs!hpfcso!hpldola!hp-lsd!col!bdale
From: [e-mail] (Bdale Garbee)
Newsgroups: rec.ham-radio.packet
Subject: Re: Dial-up SLIP and NET
Message-ID: <[e-mail]>
Date: 14 Dec 89 02:31:29 GMT
References: <[e-mail]>
Organization: HP Colorado Springs Division
Lines: 27

Ok, here's some fixed text for that section, sorry for the delay, but I've had
a few unexpected time-consumers the last week or two.

SLIP Modem Dialing

An extension to the attach command allows the syntax:

   attach <hw type> <I/O address> <vector> <mode> <label> <bufsiz> <mtu>
      [<speed>] [[optional '-' for debug] <send> <expect> <send> [...]]

---
with no success

could some knd sole e-mail me pls a sample attach command that I could use,
and where do I plug in my university phone number,

or is what i am doing is wrong, and I am missing some thing,

thanks a lot in advance,
ahmed

[e-mail]

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

Date: 27 Dec 91 04:24:19 GMT
From: [e-mail]
Subject: Packet-Radio Digest V91 #331
To: [e-mail]

Question from a new ham (actually still in the process of getting my papers).
I have had opposite advice from present hams concerning the type of wire to use
of antennas.  One person suggested using copper "ground" wire (about 1/4"
think--I don't know the gauge), while a second person said that the smaller the
wire the better.  Any difinitive answers out there?  I'd like to build a
half-wave dipole and could use some help.
_______________________________________________________________________________
To: [e-mail]
From: [e-mail] on Mon, Dec 23, 1991 8:54 AM
Subject: Packet-Radio Digest V91 #331
Received: by macmail.inre.asu.edu (2.00/GatorMail) with SMTP/TCP;23 Dec 91
08:53:44 U
Received: from ASUACAD by ASUVM.INRE.ASU.EDU (IBM VM SMTP V2R1)
   with BSMTP id 2329; Mon, 23 Dec 91 08:53:05 MST
Resent-To: <[e-mail]>
Sender:    <[e-mail]> (Mon, 23 Dec 1991 08:53:04 MST)
Resent-By: (CEAS VM/CMS Forwarding Agent) <[e-mail]>
Received: from VMD.CSO.UIUC.EDU by ASUVM.INRE.ASU.EDU (Mailer R2.08) with BSMTP
 id 3872; Mon, 23 Dec 91 08:50:07 MST
Received: by UIUCVMD (Mailer R2.07) id 9339; Mon, 23 Dec 91 09:50:38 CST
Date:         Mon, 23 Dec 1991 04:30:02 PST
Reply-To:     [e-mail]
Sender:       Packet Radio <[e-mail]>
From:         Packet-Radio Mailing List and Newsgroup
</dev/[e-mail]>
Subject:      Packet-Radio Digest V91 #331
X-To:         [e-mail]
To:           "J. Richard Haefer" <[e-mail]>

Packet-Radio Digest         Mon, 23 Dec 91       Volume 91 : Issue 331

Today's Topics:
              Comments on PK-88
              DSY modem update?
            Extended KISS protocol (Why?)
               Getting started
              NOS "wampes" for ISC unix
         What am I missing for PACSAT work ?

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

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

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

Date: 22 Dec 91 14:05:29 GMT
From: news.hawaii.edu!mpg.phys.hawaii.edu![e-mail]
Subject: Comments on PK-88
To: [e-mail]

In article <[e-mail]> [e-mail] (Jay Maynard)
writes:
>I'm currently running a PK-88 on the local IP network; it does fine, except
>for one problem: I can't set the MTU above 984. The TNC throws away any
>packets with a data portion longer than 1K. Other folks with true TNC-2 clones
>don't have that problem.

The Kantronics KPC-2400 also has a similar limitation.


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

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

Date: 22 Dec 91 16:49:36 GMT
From: network.ucsd.edu!swrinde!emory!wa4mei!ke4zv![e-mail]
Subject: DSY modem update?
To: [e-mail]

In article <[e-mail]> [e-mail] (Brian Kantor) writes:
>Has anyone looked into updating the DSY design?  It's reasonably sound,
>but it uses really old chips.  It seems to me that the design could be
>updated to make use of newer chips and yield a greatly reduced component
>count.  Perhaps we could even convince some grad student studying VLSI
>design to make up a custom chip, perhaps a gate-array/ASIC to do all the
>digital stuff, and use some newer analog stuff to cut 'way down on the
>number of parts.
>
>A few simple changes occur to me - it's perhaps possible to use some
>other type of modulator which would require fewer adjustments, and the
>demodulation might well be done at 10.7 MHz, thus eliminating another
>conversion step, crystal oscillator, filter, etc.
>
>Any takers?
>       - Brian


We've discussed several changes to the basic design from time to time,
but those common old parts are easy  to find and replacing debugged
board designs is costly. The three adjustments on the transmit encoder
allow you to compensate for a multitude of sins of component tolerances
in the entire transmit chain. It does require a simple AF grade scope
to get them set right, but you only have to do it once. A gate array
could reduce the parts count on the encoder by 2, or an ASIC could
reduce the count by 4, but puts you in a single source situation for
field replacement parts. Gate arrays wouldn't help on the decoder or
RF boards.

THE FOLLOWING IS MY PERSONAL OPINION ONLY, AND DOESN'T REFLECT OFFICAL
GRAPES POSITIONS.

A couple of changes that would be worthwhile (IMHO) would be to use a
newer DAC chip that includes the latch and output amp, and go to
Minicicuits type diode ring balanced modulators so the output could be
on-channel instead of at 29 Mhz. This would eliminate the need for a
costly external transmit converter, though at the cost of additional
buffer stages and a power brick. This would require slightly different
RF boards for each band. That reduces the universal appeal of the modem
somewhat, but with the problem of locating suitable transverters being
what it is, I think it's a good idea.

The major drawback to eliminating the 455 khz stage in receive is
the necessity for a band filter with the proper group delay. This
was a major stumbling block in the original design. By good fortune,
it was possible to design a filter with the desired characteristics
at 455 khz with off the shelf parts. Tektronix is showing an integrated
filter with the proper characteristics at 10.7 Mhz, but the order
quantities required are unreasonable for us and being stuck with a
single source part is another consideration. If a good, readily available,
filter design comes along, then eliminating the 455 khz stage is
feasible. Staying with the theme of on-channel operation, the
first mixer could be changed to operate at channel frequency and
a helically filtered preamp, like the nice Hamtronics units, could
form the front end. Single conversion to 10.7 Mhz from UHF would
be prone to image problems though.

Changing the boards to surface mount, and constructing a motherboard
to eliminate the harness and house an on board power supply would
simplify packaging problems and reduce the size of the modem. The
modular nature of the original design was deliberate, however. It allows
for wide flexibility in operations. The transmit and receive chains
can be totally separated for split site or crossband usage. The
original choice of 29 Mhz for the modem input and output pushed
the more difficult RF circuitry onto an external transverter and
allowed one modem design to be used on any band for which a transverter
was available. With the advent of MMIC UHF amplifiers and packaged mixers,
and with the decline in availability of cheap transverters, integrating
the on-channel electronics into the RF board begins to look attractive.
But we don't want to destroy the modular nature of the unit completely,
so some duplication of circuitry is inevitable. We also have to keep
in mind the grade of test equipment available to people putting the
kits together. Today, only a modest performance scope is required. If
we start putting UHF circuitry on the modem, access to a spectrum
analyser would become necessary, or at least desirable.

Gary KE4ZV

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

Date: 22 Dec 91 20:49:01 GMT
From: network.ucsd.edu!swrinde!mips!atha!aunro!ve6mgs![e-mail]
Subject: Extended KISS protocol (Why?)
To: [e-mail]

[e-mail] (Peter Hardie) writes:
>I may have missed seeing mention of this, but in my view, one absolutely
>essential feature of a new KISS protocol is one that allows the computer
>to interrogate the TNC to ask it how many unsent packets its (the TNC) got.

and [e-mail] (Louis A. Mamakos) sez:
>Why?
>
>A real transport protocol will perform an exponential backoff as it
>begins to perform retransmissions.  Won't the lack of an ACK do the
>same thing as having the TNC tell you it can't transmit the packet?
>What will you do differently?

Well, this issue is a bit clouded. The TNC may, due to channel usage, not
transmit the packet for a long period of time. The software talking to the
TNC does not know if it has not received a ACK because it failed to transmit
yet or if the message failed to propogate. If it failed to transmit, it is
far better to wait. If it failed because of some other reason on the air,
then of course you want a retransmission.

On a busy channel, where your packet may be held for an extended period of
time in the TNC, the link may be dropped, when in fact a bit of patience is
called for. One could argue that it is a bad link (slow). But I think a
timer makes more sense if it starts once the packet is on the air, rather
than when it got to the TNC.

Ciao, 73 de VE6MGS/Mark -sk-

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

Date: 23 Dec 91 05:30:34 GMT
From: ricevm1.rice.edu![e-mail]
Subject: Getting started
To: [e-mail]

I would like to get into Packet Radio. What TNC is most popular.
I looking at theKantronics KAM, MFJ 1278, and AEA PK-232MBX
Pleae tell my what you think.

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

Date: 23 Dec 91 07:42:10 GMT
From: xyzoom![e-mail]
Subject: NOS "wampes" for ISC unix
To: [e-mail]

I would be interested in corresponding with anyone running
"isc-wampes" NOS for ISC Unix.

--Rob


--
Rob Lingelbach  KB6CUN  [e-mail] -or- ...!uunet!xyzoom!rob
      2660 Hollyridge Dr L.A. CA 90068  voice: 213 464-6266
"I care not much for a man's religion whose dog or cat are not the
better for it."  --Abraham Lincoln

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

Date: 23 Dec 91 06:05:02 GMT
From: [e-mail]
Subject: What am I missing for PACSAT work ?
To: [e-mail]

I'm very interested in getting started with 9600 baud packet via the
PACSATS. If I'm not mistaken, this can be done with an FM uplink on both UHF
and VHF and non-directional antennas. I thought about purchasing the Kenwood
241/441 pair for local FM work and I need to know if these xcvrs will work
for PACSAT use ? Also - need feedback on what 9600 baud modem is best suitable
with an AEA PK-232 (G3RUH, Pac-comm, MFJ, TAPR, etc.)
Any comments/sugjestions are welcome.
Thanks es 73,
Rich
WB2JBS

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

End of Packet-Radio Digest V91 #331
******************************

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

Date: 27 Dec 91 15:21:34 GMT
From: network.ucsd.edu!usc!wupost!darwin.sura.net!europa.asd.contel.com!emory!kd4nc!ke4zv![e-mail]
To: [e-mail]

References <[e-mail]>, <[e-mail]>, <[e-mail]>
Reply-To : [e-mail] (Gary Coffman)
Subject : Re: DSY modem update?

In article <[e-mail]> [e-mail] (Chris Elmquist) writes:
>In article <[e-mail]> [e-mail] (Ross Alexander) writes:
>>I would like to second Gary's suggestion: we desparately need a
>>*simple* transverter design to get DSY modems up onto 70cm.  I've been
>>looking around for a year now, and there just doesn't seem to be anything
>>out there compatible with a `beer budget' experimenter's means.
>
>I'll "third" the suggestion with a slight modification...  a 1296 MHz
>transverter with 'DSY compatible IF (ie, 29 MHz) would also be very
>attractive.  Here in Minneapolis the top data rate is 9600 bps and
>we'd obviously like to go faster.  We also have very little
>activity on 1296.  A means for running 56Kbps on 1296 MHz would be
>very desireable.

You can kludge it now by using a Hamtronics XV2 and a receive converter
to put the DSY on 2 meters then using a SSB Electronics transverter from
there. Just leave the transmit converter and receive converter running
all the time, it's not even too expensive. The SSB Electronics transverter
is another issue. IT's EXPENSIVE, and it must be modified to work properly.
As it comes out of the box, the IF side is TR switched and the antenna
side is separate. This is exactly backwards of what you want. You must
split the inputs, simple, and build a TR for the outputs, not so simple.
Or you can leave the output split and run two beams with preamps and
power amps mounted at the antennas. That's a real good way to go.

Using the XV2 and receive converter trick works with most of the higher
frequency transverters that want a 2 meter input. Hamtronics has a winner
here. The XV4 and converter will put you directly on 433, but the performance
isn't up to par with the Microwave Modules units. Lots cheaper though.

Gary KE4ZV

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

End of Packet-Radio Digest V91 #336
******************************
Date: Sun, 29 Dec 91 04:30:02 PST
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 #337
To: packet-radio


Packet-Radio Digest         Sun, 29 Dec 91       Volume 91 : Issue 337

Today's Topics:
            Extended KISS protocol
        ftp site for A.R.R.L. C.N.C. texts ? (2 msgs)
             Manuals 1218 version
                 PMP
                  PMP where?
               Want WNOS 3A 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: 29 Dec 91 05:32:23 GMT
From: network.ucsd.edu!usc!zaphod.mps.ohio-state.edu!mips!news.cs.indiana.edu!ux1.cso.uiuc.edu![e-mail]
Subject: Extended KISS protocol
To: [e-mail]

[e-mail] (Doug Collinge VE7GNU) writes:

>Simply tossing the retries under these conditions would not bother
>TCP or anything else I can think of.  So why not?

It wouldn't bother TCP, but it wouldn't help things, either.  Retransmits
at the TCP layer still get new IP ID's at the IP layer, and so aren't
identical to earlier transmissions of the same segment even though they
contain the same data.

If I can throw my hat into the ring, I don't see why the TNC (acting as
the data link layer agent here) needs to provide any feedback to higher
layers in the protocol stack about the length of its queue, or try to
"second-guess" the higher layers in any way. In the bad old days of the
Internet, routers used to return "source quench" messages when their
queues were near full, which was supposed to tell the sender to slow
down. It turned out to be an inferior mechanism for congestion
control.

A much better method is for the entity that is generating the packets
themselves, the layer 4 protocol, to watch what is going on with the
acknowledgements it is receiving vs the data it is sending out. The
network has a finite capacity of packets, measured by the sum of all
available queue space in all routers/TNC's/whatever on the net. The
real way to avoid overflowing the outbound queue is to not inject
packets on the network faster than they are being removed (i.e.,
acknowledged), and to do something clever with adaptive transmission
rates and window sizes to accommodate the load on the network.

Of course, if you don't have a layer 4 protocol, you must be doing
connection-oriented AX.25, which means you aren't doing networking,
you're just doing point-to-point communication on a shared channel, in
which case you should run your TNC in normal mode, let it figure out how
to access the channel, and leave it at that. The TNC is then talking to
you as a serial modem, and should tell you about a full-queue situation
by control-S-ing you or dropping CTS.

--
Charley Kline, KF9FF, PP-ASEL                                 [e-mail]
Univ. of Illinois Computing and Communication Services      AMPR: kf9ff@ka9mnx
1304 W. Springfield Ave, Urbana IL  61801                       [phone]

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

Date: 29 Dec 91 01:09:13 GMT
From: network.ucsd.edu!sdd.hp.com!spool.mu.edu!munnari.oz.au!metro!extro.ucc.su.OZ.AU![e-mail]
Subject: ftp site for A.R.R.L. C.N.C. texts ?
To: [e-mail]

Hello, this may well be a silly question, but is there an ftp site that
holds the ARRL Computer Network Conference texts ? While I realise they
are available in pre-printed form, (I have two), I'm happy to read them
from a soft copy and save everyone some paper.

  Thanks
  Terry, VK2KTJ


--
---------------------------------------------------------------------------
Terry Dawson, Chatswood, Sydney|                 |[e-mail]
[e-mail]|                 |phone    : [phone]
[44.136.8.5]  (4800@4800)      |                 |fax      : [phone]

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

Date: 29 Dec 91 04:05:53 GMT
From: network.ucsd.edu!usc!wupost!udel!sbcs.sunysb.edu![e-mail]
Subject: ftp site for A.R.R.L. C.N.C. texts ?
To: [e-mail]

In article <[e-mail]> [e-mail] (Terry Dawson) writes:
>Hello, this may well be a silly question, but is there an ftp site that
>holds the ARRL Computer Network Conference texts ? While I realise they
>are available in pre-printed form, (I have two), I'm happy to read them
>from a soft copy and save everyone some paper.
>  Terry, VK2KTJ

    The material is copyrighted:

    "This work is publication No. XX of the Radio Amateur's Library,
     published by the League.  All rights reserved.  No part of this
     work may be reproduced in any form except with written permission
    of the publisher.  All rights of translation reserved."

    As I recall, there was an effort a few years back to get the
    original documents in tex/troff/ascii from the authors and archive
    the files online (there are some residual bits ucsd.edu).  Nothing
    much came of it.

    I would, however, like to see the ARRL continue to keep past works in
    stock for a reasonable period of time, eg 10 yrs.  If ARRL does choose
    to let their stock lapse it would be a service to the amateur
    community to allow the "expired works" to be scanned and disseminated,
    rather than just sitting on the copyright.

    Any ARRL folk out there listening?

                    Rick Spanbauer
                    SUNY/Stony Brook
                    wb2cfv

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

Date: 28 Dec 91 20:57:34 GMT
From: gatech!mailer.cc.fsu.edu!uflorida!pine.circa.ufl.edu![e-mail]
Subject: Manuals 1218 version
To: [e-mail]

I am just starting to use ka9q net, and I got it working between my xt
and my 386.  Works great and really loaded with features.

I just downloaded the newest version 1218 from simtel, but it does not
contan any manuals.  The manuals are normaly in a file called
man-9112.zip, but they don't have it.  Are they out yet, or is there
somebody that can explain some new features to me.

I want to know what the tip server can do.  What happens if you do
start tip <iface>.  and can I access that remotely.
What I want to do is have a dialout modem on my server and have 2
computers conected to it being able to talk to the modem.

Hans van Oostrom
PO Box J-254, JHMHC                 hans@ufpine                (BITNET)
Gainesville, FL  32601, USA         [e-mail]    (INTERNET)
>>>          Hoe ver je ook gaat, overal zie je landgenoten           <<<

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

Date: 28 Dec 91 19:21:49 GMT
From: network.ucsd.edu!usc!rpi!news-server.csri.toronto.edu!bonnie.concordia.ca!ccu.umanitoba.ca!access.usask.ca!herald.usask.ca![e-mail]
Subject: PMP
To: [e-mail]

You can FTP the PMP package from helios.tn.cornell.edu in the /pub
directory.
Pete [e-mail]    VE5VA

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

Date: 28 Dec 91 15:24:18 GMT
From: network.ucsd.edu!usc!wupost!emory!wa4mei!n4rsy!ke4zv![e-mail]
Subject: PMP where?
To: [e-mail]

I know that this has come up again and again, but I wasn't paying
attention because I didn't need the information. Now I have someone
who needs to put a minimum cost packet station together. Would some
kind person mail me the info on getting PMP and info on the interface
required?

Gary KE4ZV

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

Date: 28 Dec 91 17:14:24 GMT
From: agate!usenet.ins.cwru.edu!cleveland.Freenet.Edu![e-mail]
Subject: Want WNOS 3A EXE
To: [e-mail]

I'm looking for someone with ftp or email access to the internet who has
or is willing to compile an executable version of WNOS 3A with asy, netrom,
and slip support.

Bob WZ8Y

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

Date: 28 Dec 91 16:30:17 GMT
From: network.ucsd.edu!usc!wupost!spool.mu.edu!umn.edu!cs.umn.edu!uc.msc.edu!nachos.SSESCO.com![e-mail]
To: [e-mail]

References <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject : Re: DSY modem update?

In article <[e-mail]> [e-mail] (Gary Coffman) writes:
>
[ stuff about wanting a 1296 transverter w/ 29 MHz IF deleted ]

>You can kludge it now by using a Hamtronics XV2 and a receive converter
>to put the DSY on 2 meters then using a SSB Electronics transverter from
>there. Just leave the transmit converter and receive converter running
>all the time, it's not even too expensive. The SSB Electronics transverter
>
>Using the XV2 and receive converter trick works with most of the higher
>frequency transverters that want a 2 meter input. Hamtronics has a winner
>here. The XV4 and converter will put you directly on 433, but the performance
>isn't up to par with the Microwave Modules units. Lots cheaper though.
>
This was one of the first things that came to mind... and I've discussed
it with several others here on the net.  One of the concerns that was
raised was whether or not there would be too much drift between all of
the converter oscillators to keep the 'DSY happily on frequency...?

I'm sure it helps to keep the 10m<->2m converters running all of the
time...  but what amount of drift could be expected with this setup
and can the 'DSY tolerate it ?

Perhaps you've proven that it works, Gary...  what 1296 transverter
did you use before/after the Hamtronics 2m converters ?

73, Chris

--
Chris Elmquist, N0JCF
[e-mail]                [e-mail]
[e-mail]             [phone]@work (8am-5pm CST6CDT)

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

End of Packet-Radio Digest V91 #337
******************************
Date: Tue, 31 Dec 91 04:30:02 PST
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 #338
To: packet-radio


Packet-Radio Digest         Tue, 31 Dec 91       Volume 91 : Issue 338

Today's Topics:
        ftp site for A.R.R.L. C.N.C. texts ? (4 msgs)
            GRAPES KLISS ROM Image wanted
               packet gateways
       What radios will work w/ G3RUH modem ?? (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: 29 Dec 91 19:21:45 GMT
From: network.ucsd.edu!network.ucsd.edu![e-mail]
Subject: ftp site for A.R.R.L. C.N.C. texts ?
To: [e-mail]

Many of the papers from the ARRL CNC 7 are to be found by anonymous FTP
on LOUIE.UDEL.EDU.
    - Brian

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

Date: 30 Dec 91 01:06:36 GMT
From: munnari.oz.au!metro!extro.ucc.su.OZ.AU![e-mail]
Subject: ftp site for A.R.R.L. C.N.C. texts ?
To: [e-mail]

[e-mail] (Rick Spanbauer) writes:

>In article <[e-mail]> [e-mail] (Terry Dawson) writes:
>>Hello, this may well be a silly question, but is there an ftp site that
>>holds the ARRL Computer Network Conference texts ? While I realise they

>       The material is copyrighted:

>       "This work is publication No. XX of the Radio Amateur's Library,
>        published by the League.  All rights reserved.  No part of this
>        work may be reproduced in any form except with written permission
>       of the publisher.  All rights of translation reserved."

Hmm, yes I read the copyright, I was hoping that the authors retained
copyright and therefore could distribute them to their liking, a bit
naive I guess ?

It would be a shame for the texts to become unavailable, having re-read
the ones that I have, they are a great source of information that is
mostly taken for granted as a result of the authors efforts being accepted.
It easy to forget (or not ever find out) the research involved with
the development of the numerous technologies.

Thanks Brian also, I will take a look at 'louie' today.

  Terry


--
------------------------------------------------------------------------
Terry Dawson, [e-mail], [e-mail]
[phone] (voice), [phone] (fax).   __\*/__            _____

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

Date: 30 Dec 91 18:27:15 GMT
From: network.ucsd.edu!sdd.hp.com!spool.mu.edu!hri.com!noc.near.net!uhasun!arrlhq![e-mail]
Subject: ftp site for A.R.R.L. C.N.C. texts ?
To: [e-mail]

In rec.radio.amateur.packet, [e-mail] (Rick Spanbauer) writes:
>In article <[e-mail]> [e-mail] (Terry Dawson) writes:
>>Hello, this may well be a silly question, but is there an ftp site that
>>holds the ARRL Computer Network Conference texts ? While I realise they
>>are available in pre-printed form, (I have two), I'm happy to read them
>>from a soft copy and save everyone some paper.
>>  Terry, VK2KTJ
>
>       The material is copyrighted:

[quote deleted]

>       I would, however, like to see the ARRL continue to keep past works in
>       stock for a reasonable period of time, eg 10 yrs.  If ARRL does choose
>       to let their stock lapse it would be a service to the amateur
>       community to allow the "expired works" to be scanned and disseminated,
>       rather than just sitting on the copyright.
>
>       Any ARRL folk out there listening?

At present, all of the CNC proceedings are in print.  The first four
are in a single volume, the remaining ones are in individual volumes.

Because we don't pay authors for the material in the proceedings (this
includes all of the proceedings, e.g., Central States VHF Conference,
as well as CNCs) the authors retain the right to use the material
elsewhere.  Including, naturally, making it available on Internet.
So if you have the author's permission, you can sure post the paper
for FTP access.

ARRL doesn't make any money on these things.  We just about break even,
which is all we really want to do.  The idea is to provide a medium for
technical dialogue.  But the publications are copyright so that some
unscrupulous sort can't sell knock-off copies and make us *lose*
money, thereby making it difficult to continue publishing proceedings.

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

Date: 30 Dec 91 21:21:46 GMT
From: network.ucsd.edu!usc!wupost!udel!sbcs.sunysb.edu!cs.sunysb.edu![e-mail]
Subject: ftp site for A.R.R.L. C.N.C. texts ?
To: [e-mail]

In article <[e-mail]>, [e-mail] (Jon Bloom) writes:
> At present, all of the CNC proceedings are in print.  The first four
> are in a single volume, the remaining ones are in individual volumes.

    Jon, I stand corrected.  I had assumed, wrongly, that since CNC 5/6
    were no longer advertised in QST, they were no longer available.
    Any chance you can do anything about getting Microwave 88 back
    into print, though?  :-)

> ARRL doesn't make any money on these things.  We just about break even,
> which is all we really want to do.  The idea is to provide a medium for
> technical dialogue.  But the publications are copyright so that some
> unscrupulous sort can't sell knock-off copies and make us *lose*
> money, thereby making it difficult to continue publishing proceedings.

    Even with such goals, it would be useful to make provisions for
    getting out of print proceedings (eg Microwave 88, in my
    case) into the hands of those that want them.  Maybe selling off
    rights to "out of print" works to a microfilm or CD-ROM service is
    an acceptable compromise.

                    Rick Spanbauer
                    SUNY/Stony Brook
                    wb2cfv

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

Date: 30 Dec 91 23:51:51 GMT
From: ncrcom!ciss!lawday![e-mail]
Subject: GRAPES KLISS ROM Image wanted
To: [e-mail]

Since I can't seem to get mail directly to Gary Coffman, I'll post a
question here that I <know> he could answer:

Our group is desparately looking for the souped-up KISS code that GRAPES
put together for TNC-2s and the DSY modem, together with the necessary
hardware mods.  We want to try the same idea with the Kantronics D4-10
radios.

What do I need to do to get a disk with the code (image?) and the
hardware modes?

John Ackermann   AG9V

--
John R. Ackermann, Jr.        Law Department, NCR Corporation, Dayton, Ohio
[phone]                [e-mail]
Packet Radio: ag9v@n8acv      tcp/ip: [e-mail] [44.70.12.34]

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

Date: 30 Dec 91 05:11:00 GMT
From: network.ucsd.edu!sdd.hp.com!spool.mu.edu!agate!usenet.ins.cwru.edu!wsu-cs!davespc![e-mail]
Subject: packet gateways
To: [e-mail]

Hi All,

Can anyone tell me who I can contact to find out how to go
about setting up a gateway between the internet and packet. An E-Mail
address or phone number would be great!!! Thanks for any help
you can offer.


       | Dave Beaujean
EMail  | wsu-cs.cs.wayne.edu!davespc!dave
USMail | 9349 Syracuse, Taylor, Michigan  48180   USA
Voice  | [phone]

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

Date: 30 Dec 91 09:41:00 GMT
From: [e-mail]
Subject: What radios will work w/ G3RUH modem ??
To: [e-mail]

Anyone have a list of
Anyone on the net have a list of currently marketed FM radios that
are compatible with the G3RUH modem running at 9600 baud ??
I understand that not all radios are compatible.
-Rich
WB2JBS @4Z4SV.ISR.MDLE
[e-mail]

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

Date: 31 Dec 91 07:14:40 GMT
From: network.ucsd.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!ub!dsinc!wells!beyonet![e-mail]
Subject: What radios will work w/ G3RUH modem ??
To: [e-mail]

In article <[e-mail]> [e-mail] (RICHARD HAREL) writes:
>Anyone have a list of
>Anyone on the net have a list of currently marketed FM radios that
>are compatible with the G3RUH modem running at 9600 baud ??
>I understand that not all radios are compatible.
>-Rich
>WB2JBS @4Z4SV.ISR.MDLE
>[e-mail]

    From the article in Decembers CQ magazine on Page 94 called "Packet
User's Notebook: The Next-Frontier-High Speed Modems by Buck Rogers, k4abt.

    Question: Which Radios can be used at 9600 Bauds?
    G3RUH list at that time:

    Alinco DR-1200 Data Radio
    ALR series:ALR-72, ALR 709
    Kantronics DVR 2-2 Data Radio
    ICOM IC series:25,38,228,271,290,471
    Kenwood TR series:7500,7700
    TM series:211,212,221,231,431
    TS series:700,770
    Standard C58,C140
    Yaesu FT series:212,221,230

    This is an old list and it has increased by 10 times anyone have
    a later list?

Steve Urich                     WB3FTP                  [e-mail]

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

Date: 30 Dec 91 01:16:19 GMT
From: network.ucsd.edu!qualcom.qualcomm.com!chicago.qualcomm.com![e-mail]
To: [e-mail]

References <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject : Re: ftp site for A.R.R.L. C.N.C. texts ?

I merged the papers on louie.udel.edu with those on ucsd.edu.

The ARRL conference papers on ucsd.edu are available by anonymous FTP.
They're in directory /hamradio/packet/arrl, with subdirectories by
year.  Most of my own papers are there, as are many others contributed
by AMPRNET (TCP/IP) folks. When I get a chance, I'll go through some
of my archive tapes, pull out my remaining papers and put them up on
ucsd.edu as well.

Phil

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

Date: 29 Dec 91 13:07:32 GMT
From: network.ucsd.edu!swrinde!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!wa4mei!ke4zv![e-mail]
To: [e-mail]

References <[e-mail]>, <[e-mail]>, <[e-mail]>
Reply-To : [e-mail] (Gary Coffman)
Subject : Re: DSY modem update?

In article <[e-mail]> [e-mail] (Chris Elmquist) writes:
>In article <[e-mail]> [e-mail] (Gary Coffman) writes:
>>
>[ stuff about wanting a 1296 transverter w/ 29 MHz IF deleted ]
>
>>You can kludge it now by using a Hamtronics XV2 and a receive converter
>>to put the DSY on 2 meters then using a SSB Electronics transverter from
>>there. Just leave the transmit converter and receive converter running
>>all the time, it's not even too expensive. The SSB Electronics transverter
>>
>>Using the XV2 and receive converter trick works with most of the higher
>>frequency transverters that want a 2 meter input. Hamtronics has a winner
>>here. The XV4 and converter will put you directly on 433, but the performance
>>isn't up to par with the Microwave Modules units. Lots cheaper though.
>>
>This was one of the first things that came to mind... and I've discussed
>it with several others here on the net.  One of the concerns that was
>raised was whether or not there would be too much drift between all of
>the converter oscillators to keep the 'DSY happily on frequency...?
>
>I'm sure it helps to keep the 10m<->2m converters running all of the
>time...  but what amount of drift could be expected with this setup
>and can the 'DSY tolerate it ?
>
>Perhaps you've proven that it works, Gary...  what 1296 transverter
>did you use before/after the Hamtronics 2m converters ?

The DSY modem can track frequency errors of plus and minus 5 khz
with no increase in error rate. Beyond that, the signal goes outside
the IF filter edges and error rate increases. Keeping a signal inside
a 10 khz window at 1296 without AFC  should be rather easy. I used
the SSB Electronics transverter in my tests. Inside, keeping it on
frequency was not difficult after a warm up period. Using it on
a mountaintop year round would probably require some form of AFC. I
didn't attempt that. My Down East Microwave 902 transverter drifts
around a lot, I haven't solved that problem yet.

We're talking a 4 PPM frequency error and that should be simple, but
it isn't always. Adding little slip on crystal ovens *should* fix most
problems. I recently got a dozen of these little fellows, but haven't
had a chance to try them out yet. Between building a new 2000 square
foot shop, fixing dead test equipment, and keeping a voice repeater
running, I haven't had much time to play.

Gary KE4ZV

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

End of Packet-Radio Digest V91 #338
******************************