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

Text File | 1993-12-31 | 233.8 KB | 5,817 lines

1 Dec 90 04:30:06 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #208
To: packet-radio


Packet-Radio Digest         Sat,  1 Dec 90       Volume 90 : Issue 208

Today's Topics:
     Anybody using integrated microprocessor & serial I/O chips?
                   For Sale
               KA9Q's TCP/IP for Xenix
               NET-ROM (2 msgs)
         PACSAT PROTOCOL INF. WANTED (2 msgs)
                  TNC/FT-470
          Windows 3.0 based packet radio programs ?

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 90 14:28:31 GMT
From: eru!hagbard!sunic!mcsun!ukc!acorn![e-mail]  (Adrian Godwin)
Subject: Anybody using integrated microprocessor & serial I/O chips?
To: [e-mail]

In article <[e-mail]> [e-mail] writes:
>
>Has anyone done anything with the integrated microprocessor and serial I/O chips
>(like the 68302:  68k core + ISDN style serial I/O, or the Z80181:  Z180 core + 1
>SCC-style channel)?
>
>These chips (especially the '302) look like a great way to build small, cheap,
>low-power packet-radio gadgets.

I believe somebody's doing a high-end controller based on the 68302, but I've
been looking at the 64180S for use in a TNC or intelligent interface.
I've ported the TNC-2 KISS code to it (and now use it successfully with the KA9Q s/w
on an Amiga), but it's not really perfect for the ultra-low chip count device I had
in mind.

The configuration I have uses the 64180S, a static RAM chip, a PROM, a MAX-something
RS-232 driver, a 7406 to drive PTT, an oscillator package and an SSI package I
use to give me true carrier detect. I'll probably add a DALLAS power control chip
for watchdog, reset and non-volatile RAM support.

The oscillator could be replaced with a crystal, but the package I'm using
conveniently generates a clock source for the 7910 modem, and can be arranged to
provide a clock for a G3RUH modem. Unfortunately, the division ratios don't
suit the TCM3105 modem's clock requirements.

I'm not yet using the DMA controller, since I don't yet need the speed for
a mere 1200 baud modem and I just wanted (initially) a near-port of the TNC-2
code. The DMA controller looks truly wonderful, with hardware management of
multiple chained buffers.

The on-chip clock recovery conveniently generates a delayed version of
the rx clock, so comparing the phase of this with the incoming data provides
true-DCD for the price of a 7474 (I use one of the internal timers to
count the resulting pulses and provide some filtering).


I've stopped there for a while (while I sort out the NOS and radio stuff a
little better), but I'm rather put off developing it as far as I originally
intended, because it falls between two stools - it needs too much support for
a very low chip-count miniature TNC, and it isn't flexible enough for a
multipurpose box like the Data Engine.

The SCC + DMA hardware should be terrific for high speed transfers, but there
seems little point when it's limited by the async port connection to the host
- traditional KISS problem. Note that the async port isn't supported by DMA.
Since there's only one SCC, I can't even take advantage of the transfer rate for
a node or repeater with no host access.
This seems a problem with the Kantronics box too - is anyone making use of
it's 56kbps capability ?

It's possible I might add a bidirectional parallel port and connect to the
host with that, but there are only 2 DMA channels, so I'd have to do the
host connection in software (or steal the SCC DMA some of the time).

On the miniaturisation side, the component count isn't as low as I hoped,
and promises to rise. There is very little parallel i/o on the 64180S, and
it's therefore very hard to control any other parameters - such as modem speed,
modem selection, etc. without expanding the chip count. The 7910 makes this
particularly tricky due to it's fussy initialization requirements.
This problem seems to me to lose the major advantage of putting the SCC and other
peripherals on-chip.

The SCC clocks can only output at the baud rate - so it can't be used to
generate a 16x clock as some faster modems require.

Perhaps the ideal use is as an intelligent peripheral card, with shared
memory access. The device will support a meg of DRAM with very little
hardware, and the serial port might be used for debugging, or to control
IIC peripherals (D-A for KA9Q's power-control scheme ??) .
This might best suit a machine with very little space for IO cards, since
the space for the PC expansion card doesn't really necessitate a low chip-count
solution. A 56kbps intelligent controller half-card for portables, perhaps ?


-adrian (G7HWN)




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

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

Date: 30 Nov 90 20:11:43 GMT
From: csusac![e-mail]  (Matt Monsoor)
Subject: For Sale
To: [e-mail]

  I am posting this for our Amateur Radio Club the 'River City ARCS'!

  Have two(2) 'Systron Donner' Model 1626-01 MicroWave synthesizers (Sweep
Generators) for sale!  They cover the range of 40 MHz to 27Ghz, have a
Digital Readout with DBM meter(Digital), and a IEEE 488 Remote Control Port.

  They were Built in September 1982 and the warranty ended September 1983.
I understand that when they were new they cost around $20,000!

  Contact me by internet or call Ron Holden at home and leave a message at
[phone].


--
+-----------------------------------------------------------------------------+
|    Matthew G. Monsoor    |    UUPC:     {ucdavis|lll-crg}!csusac!monsoor    |
|      [phone]      |    Internet:  [e-mail]            |
+-----------------------------------------------------------------------------+

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

Date: 30 Nov 90 04:32:40 GMT
From: crash!ipars![e-mail]  (Scott O'Connell)
Subject: KA9Q's TCP/IP for Xenix
To: [e-mail]

I am looking for KA9Q's TCP/IP software for SCO Xenix 386 2.3.3 (the
real 2.3.3 via xnx155b) and Development System 2.3.0.

I do not have FTP access.  Anon UUCP preferred.

Thanks in advance!

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

Date: 30 Nov 90 20:12:36 GMT
From: shlump.nac.dec.com!delni.enet.dec.com![e-mail]  (Fred R. Goldstein)
Subject: NET-ROM
To: [e-mail]

In article <[e-mail]>, [e-mail] (Bryan Douglas Reeves) writes...
>Can someone please summarize the theory of NET-ROM packewt fowarding and
>networking?  I have been told it is he predominent form here in
>California, and would like more information on using it.

I don't know the _details_ of it, but the general idea is thus:  NET/ROM
builds a datagramme network (Layer 3) using a proprietary packet
protocol, with route determnation based on regularly recomputing
paths via a Distance Vector technique.  DECnet Phase III/IV us distance
vector, as is cisco IGRP, though most newer nets are moving towards
link state routing (IS-IS, OSPF, RSPF).

End to end links are made via a PAD function, with link integrity
taken from a transport protocol that's bsaed on Andy Tannenbaum's
Protocol 6 in his textbook.  It's not much different in theory from
TP4 or TCP, just a simple version.

Since it runs in a ROM with a small-memory TNC to support it, NET/ROM
nets don't scale very well.  They're the appliance operators' way to
build a network, imho.

BTW, NordLink's public domain TheNet is a clone of NetRom with some
bugs fixed, like you can change your nodenamewithout buying a new
chip.

---
Fred R. Goldstein k1io         Digital Equipment Corp., Littleton MA
[e-mail]   voice: [phone]
 Do you think anyone else on the planet would share my opinions, let
 alone a multi-billion dollar corporation?

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

Date: 30 Nov 90 23:26:17 GMT
From: usc!sdd.hp.com!uakari.primate.wisc.edu!uflorida!haven!ni.umd.edu!sayshell.umd.edu![e-mail]  (Louis A. Mamakos)
Subject: NET-ROM
To: [e-mail]

In article <[e-mail]> [e-mail] (Fred R. Goldstein) writes:
>I don't know the _details_ of it, but the general idea is thus:  NET/ROM
>builds a datagramme network (Layer 3) using a proprietary packet
>protocol, with route determnation based on regularly recomputing
>paths via a Distance Vector technique.  DECnet Phase III/IV us distance
>vector, as is cisco IGRP, though most newer nets are moving towards
>link state routing (IS-IS, OSPF, RSPF).

One very important difference is that it is difficult to apply the "easy" fixes
to a distance vector based routing algorithm used in the radio environment.
Things like split horizon/poison reverse can't be used since the communications
subnet is not fully connected.  Thus, the NET/ROM routing protocol is prone to
having loops form.  It has a relatively slow update interval, so that the
"count to infinity" method of resolving routing loops takes a while to happen.

The other *big* problem with distance-vector protocols in this environment is
that is makes the assumption that each link between neighboring switches are
bidirectional.  Just because switch "A" can hear "B" doesn't mean that "B" can
hear "A".

Because of this, NET/ROM operators tend to manually fiddle the routing table and
weights, which begins to defeat the purpose of having a routing protocol at all.

louie
WA3YMH

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

Date: 30 Nov 90 10:36:37 GMT
From: eru!hagbard!sunic!news.funet.fi!kannel![e-mail]  (Joni-Pekka Kurronen)
Subject: PACSAT PROTOCOL INF. WANTED
To: [e-mail]

PACSAT

I Red From Amsat-Uk Oscar News 1990-85 Article Written By K8ka.
I 'am Wondering Where I Can Found Pacsat Protcol Standards Forom internet:
Protocol Suite
Broadcast Protocol
Filetransfer
File header definition
.......

It might be that we try to implement some kind of interface to ka9q
software which connects our ka9q based BBS/Netrom node/... to the
satellites.
We have allready made digital part of hardware required in satellite
communications. We call it arti it is 82530 based internal modem card
to pc. It is possible to turn antenna via this board because it has
analog to digital conversion and relay control for 8 relays.

I hope we get information needed. If we start this project you will be
infomed via internet very soon.

Radio club of University student union of Lappeenranta University
Our call sign is OH5AT

73'oh5bzr kurre

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

Date: 30 Nov 90 18:04:40 GMT
From: idacrd![e-mail]  (Robert McGwier)
Subject: PACSAT PROTOCOL INF. WANTED
To: [e-mail]



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

Date: 30 Nov 90 01:46:17 GMT
From: csus.edu!wuarchive!sdd.hp.com!uakari.primate.wisc.edu!dali.cs.montana.edu!milton!ogicse!intelhf!donk![e-mail]  (usenet news)
Subject: TNC/FT-470
To: [e-mail]

This is to thank all of the kind people who sent me mail on my question
on connecting my HK232 to an FT-470.

All of the information was very helpful.

My license arrive day before yesterday and the cable was ready and worked
first time.

Thanks..

***************************************************************************
* Intel may own me body and soul, but these opinions are MINE. So there.  *
*-------------------------------------------------------------------------*
* Jerry Gaiser (N7PWF)                                                    *
* [e-mail]         You can find me either here or        *
* [e-mail]         here                                  *
*-------------------------------------------------------------------------*
* "We have ways to make you scream."                                      *
* -- Intel advertisement, in the June 1989 Doctor Dobbs Journal           *
***************************************************************************

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

Date: 30 Nov 90 22:14:16 GMT
From: usc!hacgate!ashtate![e-mail]  (Steve Silverwood)
Subject: Windows 3.0 based packet radio programs ?
To: [e-mail]

In article <[e-mail]> [e-mail] (CAL-LAB (MS:JER2-85 TEL:7589)) writes:
>Are there programs available that utilize the graphics of Windows 3.0
>in the Packet Radio world ? e.g. - KA9Q's net, NOS or just something fancier
>than the built-in teminal program of Windows 3.0.
>73,
>Rich

Rick -- You might check out Crosstalk for Windows.  //Steve// KB6OJS

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

Date: (null)
From: (null)
If it is not available for anonymous ftp on tomcat.gsfc.nasa.gov in the
pacsat directory, it will be tonight.  Thanks for the reminder.

73's
Bob

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

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

End of Packet-Radio Digest
******************************
Date: Sun,  2 Dec 90 04:30:03 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #209
To: packet-radio


Packet-Radio Digest         Sun,  2 Dec 90       Volume 90 : Issue 209

Today's Topics:
        Windows 3.0 Based Packet Radio Program

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: Sat, 1 Dec 90 23:55:30 PST
From: [e-mail] (CAL-LAB (MS:JER2-85 TEL:7589))
Subject: Windows 3.0 Based Packet Radio Program
To: "[e-mail]"@HERMES.intel.com

>>Date: 29 Nov 90 14:54:30 GMT
>>From: [e-mail]  (Peter John Skelly)
>>Subject: Windows 3.0 based packet radio programs ?
>>To: [e-mail]
>>
>>I'm concidering writing a packet program for windows.  Any suggestions
>>would be helpful.


>>Pete Skelly

Hello Pete,

     Such an undertaking sounds like more than a full time task. Good Luck !
May I suggest the following if you are to begin the project.

- I use the Macintosh and a program  written by Steve Fine called
  "MacRatt". The program - as all Macintosh programs works with a GUI
  set-up. It's extremely easy to use however, as all 1st version
  programs, there's room for improvement. One example is the Macros.
  These are pull down menus which allow the user to select various strings of
  commands upon clicking the mouse. 20 are available which I find is not too
  few or too many. What's nice about Macros is that they are not displayed
  on the screen until you need them. Instead a small "M" is displayed and
  clicking it brings up a partial display of the macros. Dragging the mouse
  down allows the user to see more.
  The problem is that one must hit the enter key after
  unclicking the macro. Execution upon unclicking the macro would have been
  nice.
  Since Windows 3.0 is basically an all-out attempt to clone the operating
  system of the Macintosh, (Good try MicroSoft but not quite !)
  it's only logical that a programmer who is intending to tackle the task
  of writing a Windows 3.0 based program look at what is available already
  for the Macintosh. Ideally the program would do everything "MacRatt" does -
  plus incorperate the fine features of the terminal program called
  "Microphone". Now there is a "Microphone II" version available. The most
  wanted feature from this program is it's ability for the user to build his
  own "programs" within the program to do all kinds of wonderful things like
  connect to a certain BBS at a designated time, download specified files
  - search for a key word or words, save to disk if it appears, delete if it
  does not and then disconnect. It uses simple "BASIC" style commands. These
  custom built macros allow the user extreme flexibility.
  This Super Program would also have to include provision to operate with
  Phil Karn's "NET" and "NOS" to round every thing out.
  I'd love to get my hands on the second version of this yet to exist program.

73 es lot's of luck,
Rich
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Internet:                |Pigeon:          |Land Line:  |Packet:|Heart:
[e-mail] |P.O. BOX 6457    |972-2-785578|4X1DA  |Cute blonde +
             |JERUSALEM, ISRAEL|            |@4Z4SV |big smile
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

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

End of Packet-Radio Digest
******************************
Date: Tue,  4 Dec 90 04:30:02 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #210
To: packet-radio


Packet-Radio Digest         Tue,  4 Dec 90       Volume 90 : Issue 210

Today's Topics:
       Using a TNC to `dial in' to a Unix box? (2 msgs)
      Where can I find more AX25 protocol descriptions?

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 90 23:25:30 GMT
From: swrinde!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!metro!usage.csd.unsw.oz.au!ccadfa!rodos2![e-mail]  (Warren Toomey)
Subject: Using a TNC to `dial in' to a Unix box?
To: [e-mail]

Just a quick question, has anybody set up a system to allow connections on
a TNC to be directed to  aserial port on a Unix box, with a login(1) running
on the port?

To be more specific, I have:

    an AEA PK-88 TNC, 2m rig
    a standalone Unix box, with a spare serial port.

I'd like:

    people connecting to my TNC to get a login: prompt
    not to use KA9Q or TCP [this is in fact Minix]
    multiple connections would be nice :-)

Initially, there will be a guest account with a restricted
environment & no password, so password transmission will not be a
worry.

I guess login(1) would need some rewriting to handle this. Has anybody
tried this, and what were their results? I don't want to reinvent the
wheel :-)

Thanks in advance,


     Warren Toomey VK1XWT, not yet post-cold.
     Deep in the bowels of ADFA Comp Science.
`I could, but I won't - just to see your reaction'

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

Date: 3 Dec 90 23:30:24 GMT
From: usc!samsung!munnari.oz.au!metro!usage.csd.unsw.oz.au!ccadfa![e-mail]  (Warren Toomey)
Subject: Using a TNC to `dial in' to a Unix box?
To: [e-mail]

Just a quick question, has anybody set up a system to allow connections on
a TNC to be directed to  aserial port on a Unix box, with a login(1) running
on the port?

To be more specific, I have:

    an AEA PK-88 TNC, 2m rig
    a standalone Unix box, with a spare serial port.

I'd like:

    people connecting to my TNC to get a login: prompt
    not to use KA9Q or TCP [this is in fact Minix]
    multiple connections would be nice :-)

Initially, there will be a guest account with a restricted
environment & no password, so password transmission will not be a
worry.

I guess login(1) would need some rewriting to handle this. Has anybody
tried this, and what were their results? I don't want to reinvent the
wheel :-)

Thanks in advance,


--
   Warren Toomey VK1XWT, rescreened.
Deep in the bowels of ADFA Comp Science.
      `What the hell is SIGTTIN?'

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

Date: 4 Dec 90 09:38:13 GMT
From: mcsun!hp4nl!tuegate.tue.nl!rc6.urc.tue.nl!rwb.urc.tue.nl![e-mail]  (Annard -Icon- Brouwer)
Subject: Where can I find more AX25 protocol descriptions?
To: [e-mail]

Hi there!

for a practical job here at the university I need all the info I can
get about the precise description of the AX25 protocol. Where can I
find it, get it (and if it's not available for nothing, how much
does it cost)?
Can anyone also give me the address for the mailing list which was
meant especially for people developing software for the packet-scene?
Thanks very much in advance!

73, Annard (pe1koo)
--
| Annard Brouwer                Bitnet             : rcgbbaab@heitue51
| Dreef 74                      UUCP               : [e-mail]
| NL-5504 LD  Veldhoven         packet-radio       : pe1koo@pi8mid
| The Netherlands                                    [44.137.28.6]

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

End of Packet-Radio Digest
******************************
Date: Wed,  5 Dec 90 04:30:03 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #211
To: packet-radio


Packet-Radio Digest         Wed,  5 Dec 90       Volume 90 : Issue 211

Today's Topics:
              How to get a KAM to work.
          ka9q SCC DRIVER INSTALLATION HELP
           Using a TNC to `dial in' to a Unix box?

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

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

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

Date: Tue, 04 Dec 90 15:53:20 CST
From: [e-mail]
Subject: How to get a KAM to work.
To: [e-mail]

I'm new to the packet radio scene and have a few too simple questions.


   1. How do I get the KAM (It's the all mode Kamtronics TNC) to "talk"
      to the computer?
    I'm using Procomm+ as the terminal program on an IBM computer.
    All cables are correct. I just never recieve a message from the TNC.
    According to the book it should send the cmd: prompt when I turn it
    on and the program is started.
   2. The options in the procomm+ program are too numourous to test one by
      one. What are the settings that should be used to start the TNC up?

    Is anyone out there familiar with procomm+ as a terminal program or
    does anyone have a suggestion on another program to use?

    The setup is an IBM computer with a monochrome monitor, a hard drive,
    one floppy drive, one serial port, and one parallel port.

    Any help would be GREATLY appreciated.
    Send mail to
              Jay Doster   [e-mail]

    thx.

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

Date: 4 Dec 90 13:45:39 GMT
From: cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!news.funet.fi!kannel![e-mail]  (Joni-Pekka Kurronen)
Subject: ka9q SCC DRIVER INSTALLATION HELP
To: [e-mail]

Hello fellows

I have tried to scc driver instead of eagle driver whit our ARTI
board.
For some reasons, which I do not know eagle works whit our card but
SCC dos not. I have used following initialisition line:

SCC 1 init 0x300 0x16 0x0 0x4 0x1 0 3 p7158913
scc 0 ax25 lta 512 1200 256

So our arti bases 82530 chip. Glue logic can determine all most any
base address. Any way A0 is tied D/C select and A1 tied to A/B.

Whit eagle driver following command line has worked.

attach eagle 0x300 3 ax25 lta 512 256 1200

Clock frequency is changed in eagle.h file.

I am happy I someone can give answer. Anyway next week I start reading
SCC source code if there is not answer.

Technical details from arti:
DRSI,EAGLE.... look a like internal modem card.
Suport for two switchable dma lines (not tested)
A/D converter chip whit 8 lines analog mux
Realay control for 8 relays
82530-10 chip
Clock from pc OSC line or external crystal.
82530 chip addressing:selectable base address
Chanel a/b selected by A1
Data or controll regiter by A0
Addressing example:
0300 Selected base address. IBM style 10bit I/O address
0300 - 305 first SCC 82530 CHIP
0700 ADC 0804 CHIP / AD CHANEL SELECT (RD to read, wr to start
     converions an select chanel)
0b00 CARD CONTROLL (74ls377 chip) (not well defined)
0f00 RELAY CONTROLL (74ls377 chip)

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

Date: 4 Dec 90 21:19:21 GMT
From: zephyr.ens.tek.com!tekchips!tekgvs![e-mail]  (Mike Horne)
Subject: Using a TNC to `dial in' to a Unix box?
To: [e-mail]

In a recent article by Warren Toomey ([e-mail]):

|> Just a quick question, has anybody set up a system to allow connections on
|> a TNC to be directed to  aserial port on a Unix box, with a login(1) running
|> on the port?...
|>
|> ...I guess login(1) would need some rewriting to handle this. Has anybody
|> tried this, and what were their results? I don't want to reinvent the
|> wheel :-)
|>

Many moons ago back when I was just a kid in College (i.e. in '85 :),
I had a similar setup between a Sun 2 at the Physics Department (where I
worked/hacked) and a TNC/terminal at home.  I was originally running a
GLB PK1 (gag!) on both ends, later migrating to the more elaborate TNC2
(snicker!).  In short, I wrote a homebrew BBS program (which shall live in
infamy in Eastern Washington :) that provided an interface to /bin/login
through the BSD pseudo terminal inteface (i.e. ptys).  It was quite simple
and very effective.  A process simply monitored the tty port for connections,
then setup a data handling link between the port and /bin/login via a pty.
Adding additional `channels' was possible with the streams interface on later
versions of the TNC 2 firmware.

Of course, as you mentioned, passwords are an issue.  I had a restricted
account for entry into the system; if I wanted to su as a more powerful
user (e.g. root), I used a challenge-reply authentication scheme using
a random seed for a polynomial.  Of course, there weren't all that many people
on packet at that time so an elaborate system wasn't really needed.

Writing a very simple interface should be trivial.  I don't recall if minix
has pseudo terminals; even so, you could probably write something using
pipes.

Good luck and enjoy!  That's what it's all about!

Mike -ka7axd
Advanced Video Digital Signal Processing
[e-mail]

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

End of Packet-Radio Digest
******************************
Date: Thu,  6 Dec 90 04:30:04 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #212
To: packet-radio


Packet-Radio Digest         Thu,  6 Dec 90       Volume 90 : Issue 212

Today's Topics:
          AA4RE PBBS - Where are the docs ??
          Anyone tried full-duplex packet? (2 msgs)
                pk232 software
              ROSE X.25 Specifications.
      Where can I find more AX25 protocol descriptions? (2 msgs)
        Where do I get an IP address? (2 msgs)

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

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

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

Date: 5 Dec 90 23:31:32 GMT
From: usc!elroy.jpl.nasa.gov!kilroy![e-mail]  (Gerald J. Walsh)
Subject: AA4RE PBBS - Where are the docs ??
To: [e-mail]

Recently, I got a copy of the AA4RE PBBS by FTP from tomcat.gsfc.nasa.gov.
There was a file on there called 'readme.210' and it gave the following
information:

     List of distribution files for AA4RE BBS Version 2.10

     BB210   .ZIP -- The program itself with some .DOC updates since 2.9

     2.9 Doc files still applicable to 2.10

     BB29DOCM.ZIP -- Documentation in the usual multiple small files
     BB29DOC1.ZIP -- Documentation as one big printable file
     BB29DWP .ZIP -- Same as DOC1 but in WordPerfect format

Unfortunately, the last three ZIP files were not on tomcat.  I tried
simtel also and they did not have them either.  Does anyone know where
I can get these doc files from?  I'm having a difficult time setting
up the PBBS from the sysop's standpoint.  Also, I am looking for anything
that describes the message file format for this PBBS.  I plan on
generating messages from another source and just putting them on the
hard disk of the machine that is running the PBBS, so I need to know
how to generate messages in the correct format.

Thanks in advance for any help!


Gerald J. Walsh                         | Internet: [e-mail]
Jet Propulsion Laboratory               | Phone   : [phone]
RF and Microwave Subsystems Section     | Fax     : [phone]
M/S 238-528                             |
4800 Oak Grove Drive                    |
Pasadena, CA  91109                     |

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

Date: Wed, 05 Dec 90 15:58:04 GMT
From: "Pete Lucas, NCS-TLC, Holbrook House, Swindon" <[e-mail]>
Subject: Anyone tried full-duplex packet?
To: [e-mail]

I started thinking last night... (dangerous!).
Has anyone tried using full-duplex packet (split-frequency working?) like
outbound on 2 meters, inbound on 440 ??
Of course to make full use of this, would require some smart code, but
consider the following:

Stations 'A' and 'B' are both working into station 'X'.
A cannot hear B, and B cannot hear A, so neither A nor B realise they are
colliding with each other (familiar scene is it not?)

Now if station 'X' could, on hearing a collision start to happen,
immediately, on another frequency, send an 'indication to abort'
to both 'A' and 'B', then both 'A' and 'B' could immediately stop
their transmissions and go about retrying later...

(This means that 'A' and 'B' must be able to abort a frame that is
already in transmission, rather than completing the transmission of the
whole frame).

It would also mean that, with suitable windowing, the transmission
of bulk data would be MUCH faster (no need to wait, you send the
frame-acknowledges back down the other channel.....)

 Am I having good ideas here, or should I go sit under a toadstool?

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

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+    There are those amongst us who believe that '777' is the only legal  +
+     first argument to the UNIX 'chmod' command. I have this wonderful   +
+       ability of being able to laugh at the foolishness of others.      +
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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

Date: 6 Dec 90 08:12:07 GMT
From: envy![e-mail]  (Phil R. Karn)
Subject: Anyone tried full-duplex packet?
To: [e-mail]

Pete,

Yes, this idea occurred to me several years ago. Using a split
frequency repeater (preferably crossband) makes it possible to provide
true collision detection in the Ethernet sense over packet radio.

This is not possible on regular simplex packet radio because of the
enormous disparity between the transmit and receive signal levels
(the reflection of your signal off the sidewalk is probably far
stronger than the signals from the other stations you talk with).

Ethernet owes its stability to its ability to detect collisions
quickly and abort them, before the stations involved have wasted much
time on the channel.  The same should work well on radio as long as
the propagation delays are short (i.e., on local terrestrial paths,
not satellite paths).

Phil

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

Date: 5 Dec 90 21:59:23 GMT
From: adm!lhc!lhc![e-mail]  (Larry Hunter)
Subject: pk232 software
To: [e-mail]

Hi folks,

I just got a PK232 to add to my SWL setup, and I'd like pointers to
software for displaying fax & RTTY stuff and/or controling the beast.
The controlling computer is an old sun, so source code pointers would
be appreciated, although any tips at all are welcome.  Also, if anyone
has written code for controling a Kenwood R5000 they'd be willing to
share, I'd be interested.

If I don't hear from anyone, I'll post again when I've written it all
:-).

BTW, I tried looking at the hamradio/packet directory of the ucsd.edu
anonymous ftp site, and there are two files pk232.arc and
pk232-com.arc, but they are both unreadable by the public.  Any idea
what they are and why they are unreadable?

                    Thanks,

                    Larry

--
Lawrence Hunter, PhD.
National Library of Medicine
Bldg. 38A, MS-54
Bethesda. MD 20894
[phone]
[phone] (fax)
[e-mail] (internet)
hunter%nlm.nih.gov@nihcu (bitnet/earn)

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

Date: 6 Dec 90 07:30:57 GMT
From: agate!bionet!uwm.edu!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!csc.anu.oz.au!csc3.anu.oz.au!csc.canberra.edu.au!echo![e-mail]  (Carl Makin)
Subject: ROSE X.25 Specifications.
To: [e-mail]

Hi,
Does wnyone know ehere I can get the specification for the X.25 links between
ROSE nodes.  I am interested in putting code similar to the NET/ROM code
into NOS for ROSE.

Unfortunately we have both ROSE and NET/ROM networks going in locally
and I would like to gateway between the two.

Carl
[e-mail]
[e-mail]

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

Date: 5 Dec 90 10:15:26 GMT
From: zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!news.funet.fi!kannel![e-mail]  (Joni-Pekka Kurronen)
Subject: Where can I find more AX25 protocol descriptions?
To: [e-mail]

Hi you !

I am  very sorry but i do not know where to find from internet.
ax.25 standards are published at 7:th Network Conference book. I hope
you get better answer.

73 kurre oh5bzr

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

Date: 5 Dec 90 21:34:28 GMT
From: csus.edu!wuarchive!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!cunixf.cc.columbia.edu!cunixd.cc.columbia.edu![e-mail]  (Meir)
Subject: Where can I find more AX25 protocol descriptions?
To: [e-mail]

In article <[e-mail]> [e-mail] (Joni-Pekka Kurronen) writes:
>Hi you !
>
>I am  very sorry but i do not know where to find from internet.
>ax.25 standards are published at 7:th Network Conference book. I hope
>you get better answer.
>
>73 kurre oh5bzr

There are many books written on the subject of Amateur Packet Radio including
a Radio Shack version and an American Radio relay League version.  The AX.25
info is probably also in the latest editions of the ARRL Handbook for the
Radio Amateur.  The ARRL is in Newington, CT (I don't have their address here).

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

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

Date: 5 Dec 90 22:14:35 GMT
From: usc!wuarchive!swbatl!synoptics![e-mail]  (Jerome Kaidor)
Subject: Where do I get an IP address?
To: [e-mail]

In article <[e-mail]> [e-mail] (Mark Monninger) writes:
>I would like to get into the TCP/IP packet world. How do I go about
>getting an IP address?

    I'd like an IP address too.  Who's the coordinator for Northern
California?  Also, is there a listing anywhere of gateway stations?
I.E., if I want to "get on the network", which station do I call?
What frequency do I use?  There are lists of IP addresses on the
packet BBS's, but that's not enough.  I need at least one magic
frequency...

     - Jerry Kaidor, KF6VB


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

Date: 6 Dec 90 04:31:12 GMT
From: [e-mail]  (Brian Kantor)
Subject: Where do I get an IP address?
To: [e-mail]

44.002  Bob Meyer               K6RTV   Calif: Sacramento
44.004  Douglas Thom            N6OYU   Calif: Silicon Valley - San Francisco
44.006  Don Jacob               WB5EKU  Calif: Santa Barbara/Ventura
44.008  Brian Kantor            WB6CYT  Calif: San Diego
44.010  Brian Roode             KA6CCF  Calif: Orange County
44.012  Steven King             KD7RO   Eastern Washington,Idaho
44.014  John Shalamskas         KJ9U    Hawaii & Pacific Islands
44.016  Don Jacob               WB5EKU  Calif: Los Angeles - S F Valley
44.018  Geoffrey Joy            KE6QH   Calif: San Bernardino & Riverside
44.020  Bill Flynn              AI0C    Colorado: Northeast
44.022  John Stannard           KL7JL   Alaska
44.024  Clifford Neuman         N1DMM   Washington state: Western (Puget Sound)
44.026  Ron Henderson           WA7TAS  Oregon
44.028  Don Adkins              KD5QN   Texas: Dallas
44.030  J Gary Bender           WS5N    New Mexico
44.032  Bdale Garbee            N3EUA   Colorado (Colorado Springs)
44.034  Jeff Pierce             WD4NMQ  Tennesee
44.036  Doug Drye               KD4NC   Georgia
44.038  Mike Abbott             N4QXV   South Carolina
44.040  Jeff Jacobsen           WA7MBL  Utah
44.042  Phil Akers              WA4DDE  Mississippi
44.044  Rolfe Tessem            W3VH    Massachusetts: western
44.046  William Simmons         WB0ROT  Missouri
44.048  Jacques Kubley          KA9FJS  Indiana
44.050  Ron Breitwisch          KC0OX   Iowa
44.052  Gary Grebus             K8LT    New Hampshire
44.054  Ralph Stetson           KD1R    Vermont
44.056  Don Hughes              KA1MF   Eastern Mass
44.058  Rich Clemens            KB8AOB  West Virginia
44.060  Howard Leadmon          WB3FFV  Maryland
44.062  Jim Dearras             WA4ONG  Virginia (not DC)
44.064  Dave Trulli             NN2Z    New Jersey: northern
44.065  John Pearce             WB2MNF  New Jersey: southern
44.068  Norm Sternberg          W2JUP   New York: Long Island
44.069  Paul Gerwitz            WA2WPI  New York: upstate
44.070  Gary Sanders            N8EMR   Ohio
44.072  Dick Gulbrandsen        WD9DBJ  Chicago - North Ill.
44.074  James Curran            KA4OJN  North Carolina
44.076  Kurt Freiberger         WB5BBW  Texas: central?
44.077  Rod Huckabay            KA5EJX  Texas: west
44.078  Joe Buswell             K5JB    Oklahoma
44.080  John Gayman             WA3WBU  Pennsylvania: eastern
44.082  Steven Elwood           N7GXP   Montana
44.084  Bob Ludtke              K9MWM   Colorado: western
44.086  Reid Fletcher           WB7CJO  Wyoming
44.088  Jon Bloom               KE3Z    Connecticut
44.090  Mike Nickolaus          NF0N    Nebraska
44.092  Pat Davis               KD9UU   Wisconsin, upper peninsula Michigan
44.094  Gary Sharp              WD0HEB  Minnesota
44.096  Don Bennett             K4NGC   District of Columbia
44.098  Garry Paxinos           (waiting)       Florida
44.100  Ken Adkisson            WB4FAY  Alabama
44.102  Jeff King               WB8WKA  Michigan (lower peninsula)
44.104  Ed Rasso                WA2FTC  Rhode Island
44.106  Bob Austin              N4CLH   Kentucky
44.108  James Dugal             N5KNX   Louisiana
44.110  Richard Duncan          WD5B    Arkansas
44.112  Bob Hoffman             N3CVL   Pennsylvania: western
44.114  Steven Elwood           N7GXP   N&S Dakota
44.116  Tom Kloos               WS7S    Oregon: NW&Portland,Vancouver WA
44.118  Jon Andrews             WA2YVL  Maine
44.122  Troy Majors             WI0R    Kansas
44.124  David Dodell            WB7TPY  Arizona
44.125  Earl Petersen           KF7TI   Nevada
44.126  Karl Wagner             KP4QG   Puerto Rico
#
# 44.128 is reserved for testing.  Do not use for operational networks.
# You may safely assume that any packets with 44.128 addresses are bogons
# unless you are using them for some sort of testing
#
44.128  TEST
#
# International subnet coordinators by country
#
44.129  Japan           JG1SLY Tak Kushida, JH3XCU Joly Kanbayashi
44.130  Germany         DL4TA
44.131  United Kingdom  G4CLI   Dave Lockwood
44.132  Indonesia       YB1BG   Robby Soebiakto
44.133  Spain           EA4DQX  Jose Antonio Garcia.  Madrid. (EA4DQX @ EA4DQX)
44.134  Italy           I2KFX
44.135  Canada          VE3GYQ  David Toth
44.136  Australia       VK2ZXQ  John Tanner
44.137  Holland         PA0GRI  Gerard Van Der Grinten
44.138  Israel          4X6OJ   Ofer Lapid
44.139  Finland         OH1MQK  Matti Aarnio
44.140  Sweden          SM0RGV  Anders Klemets
44.141  Norway          LA4JL   Per Eotang
44.142  Switzerland     HB9CAT  Marco Zollinger
44.143  Austria         OE1YSS  Irmela Gagern
44.144  Belgium         ON7LE
44.145  Denmark         OZ1EUI
44.146  Phillipines     DU1UJ   Eddie Manolo
44.147  New Zealand
44.148  Ecuador         HC5K    Ted
44.149  Hong Kong       VS6EL
44.150  Yugoslavia      YU3FK   Iztok Saje
44.151  France          FC1BQP  Pierre-Francois Monet
44.152  Venezuela       OA4KO/YV5       Luis Suarez
44.153  Argentina       LU7ABF  Pedro Converso
44.154  Greece          SV1IW   Manos
44.155  Ireland         EI9GL   Paul Healy
44.156  Hungary         HA5DI   Markus Bela
44.157  Chile           CE6EZB  Raul Burgos
44.158  Portugal        CT1DIA  Artur Gomes
44.159  Thailand        HS1JC   Kunchit Charmaraman
44.160  South Africa    ZS6BHD  John
44.161  Luxembourg      LX1YZ   Erny Tontlinger
44.162  Cyprus          5B4TX   C. Costis
44.163  Central America TI3DJT  Chuck Hast

44.193  Outer Space-AMSAT       W3IWI           Tom Clark

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

End of Packet-Radio Digest
******************************
Date: Fri,  7 Dec 90 04:30:04 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #213
To: packet-radio


Packet-Radio Digest         Fri,  7 Dec 90       Volume 90 : Issue 213

Today's Topics:
           Anyone tried full-duplex packet?

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

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

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

Date: 6 Dec 90 15:27:32 GMT
From: swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!crdgw1![e-mail]  (Donald P Perley)
Subject: Anyone tried full-duplex packet?
To: [e-mail]

In article <[e-mail]>, karn@envy (Phil R. Karn) writes:
 (pete had asked about full duplex links for collision avoidance)

>Pete,
>
>Yes, this idea occurred to me several years ago. Using a split
>frequency repeater (preferably crossband) makes it possible to provide
>true collision detection in the Ethernet sense over packet radio.

According do the guy who taught the packet class I took (wb2kmy),
some backbone point to point links are using crossband full duplex.

If you are primarily concerned with hidden transmitter collisions,
what you could do is have your mountain top network node transmit a
"channel busy" signal on another frequency/band.  Since this could be
just an on/off carrier (hmm. what about ID?), you could pack dozens in
the space that would be required by a normal data channel.  It would
help to have equipment that supports real short txdelays (and of
course, a random wait) to cut down the problem of 2 users starting at
the same time.

don perley - ke2tp
[e-mail]
Path: ucsd!swrinde!cs.utexas.edu!uunet!cbmvax!heimat!dan
From: [e-mail] (Dan 'Sneakers' Schein)
Newsgroups: rec.ham-radio,rec.ham-radio.packet,rec.ham-radio.swap
Subject: Re: Terminal / BBS program to packet radio
Message-ID: <[e-mail]>
Date: 7 Dec 90 00:59:11 GMT
References: <[e-mail]>
Reply-To: [e-mail] (Dan 'Sneakers' Schein)
Organization: Sneakers Computing, West Lawn, PA
Lines: 21
Xref: ucsd rec.ham-radio:16070 rec.ham-radio.packet:2561 rec.ham-radio.swap:1438

In article <[e-mail]> [e-mail] (Peter Sunesen) writes:
>
>I`am happy to anounce, that you now can get the best and most used
>packet radio program, from iesd.auc.dk (130.225.48.4)
>as anonymous ftp.
>
  Fine, so why did you have to post this message plus 5 parts of the actual
  program? Posting to all of the above list of newsgroups seems like a bit
  of overkill. In the future please post only the announcement and send the
  files by e-mail or post in a binary newsgroup. Not everyone needs or wants
  your software that reads these newsgroups, not to mention soem of us have
  computers that use other operating systems (Like AmigaDOS).
--
                   _____
     Dan 'Sneakers' Schein    /     \   Quote:
     Sneakers Computing     \/\/     |        Those who worked the hardest
     2455 McKinley Ave.      |  (o)(o)        are the last to surrender.
     West Lawn, PA 19609     C   .---_)            -= Gary Ward =-
                  | |.___|
                  |  \__/
     uunet!cbmvax!heimat!dan  /_____\  (or)  [e-mail]
Path: ucsd!usc!sdd.hp.com!wuarchive!uunet!w8grt!jim.grubs
From: [e-mail] (Jim Grubs)
Newsgroups: rec.ham-radio,rec.ham-radio.packet,rec.ham-radio.swap,rec.radio.shortwave,news.groups
Subject: CALL FOR DISCUSSION: rec.ham-radio reorganization
Message-ID: <[e-mail]>
Date: 6 Dec 90 18:26:35 GMT
Organization: QRV de W8GRT, Sylvania, OH
Lines: 57
Xref: ucsd rec.ham-radio:16052 rec.ham-radio.packet:2560 rec.ham-radio.swap:1437 rec.radio.shortwave:4487 news.groups:15207


 > From: [e-mail] (Wm E Davidsen Jr)
 > Date: 5 Dec 90 14:34:04 GMT
 > Organization: GE Corp R&D Center, Schenectady NY
 > Message-ID: <[e-mail]>
 > Newsgroups: news.groups,rec.ham-radio
 >
 > In article <[e-mail]> [e-mail] (paulf)
 > writes:
 >
 > | PROPOSED ADDITIONS:
 > |
 > | 1. rec.radio.ham
 > | 2. rec.radio.ham.legal
 > | 3. rec.radio.ham.packet
 > | 4. rec.radio.ham.swap
 >
 > | PROPOSED DELETIONS:
 > |
 > | 1. rec.ham-radio
 > | 2. rec.ham-radio.packet
 > | 3. rec.ham-radio.swap
 >
 >         [ note: I have not delete any explanation here ]
 >
 > | Commentary Period: Dec. 4 -14, 1990
 >
 >   A few comments: a few sentences about the other rec.radio groups would
 > have made it clear why you were changing ham-radio to radio.ham, and I
 > would like to see .misc used for the catch-all group.
 >
 >   Finally, I don't personally like the .legal name, as it encourages
 > thought of "what part is not legal?" If you can can think of a beter
 > name (ie. more descriptive) it might aid in identifying the group. I
 > don't really care for legal-issues or legalities, but perhaps
 > regulations would be better, since you will probably be talking mostly
 > about things which are not laws (passed by congress) but regulations
 > from the FCC.

How about rec.radio.amateur.policy?

My only objection to the new newsgroup is that it has all the earmarks of
sticking one's head in the sand rather than coming to grips with the fact
that when ham radio dies (and it probably will) it will be for political
reasons. We ignore that side of the hobby at our peril.

The technoids go on and on wonderfully about their ideas for the design of
the Phantasmagorical Data Engine with the blind faith assumption that when
they're done, we'll have amateur bands to use it in. I don't think we can
assume that, and sticking those who write about it in a "newsghetto" so they
can be ignored more easily will be counterproductive in the long run. Penny
wise and pound foolish, as it were.

--
Jim Grubs - via FidoNet node 1:234/1
UUCP: ...!uunet!w8grt!jim.grubs
INTERNET: [e-mail]
Path: ucsd!ucbvax!UMRVMA.UMR.EDU!S096049
From: [e-mail]
Newsgroups: rec.ham-radio.packet
Subject: Re: Packet-Radio Digest V90 #211
Message-ID: <901206.145739.CST.S096049@UMRVMA>
Date: 6 Dec 90 20:57:39 GMT
References: <[e-mail]>
Sender: [e-mail]
Organization: The Internet
Lines: 11


     Thnx to all out there that replied to my request for help on the
KAM. Your combined help got the the KAM to work. For some unknown reason
the computer thought that the serial port was COM2 and that COM1 didn't
exist. So I swicthed to COM2 and wham! just like you said it came up with
the KAMTRONICS message and cmd: prompt.
   I spent about 6 hours last night playing with it and am very pleased.
THANK YOU for all your help and thank you to this news group for being
in existance to help me.

      TNX    Jay Doster  [e-mail]
Path: ucsd!usc!wuarchive!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!cbnewsh!n2dsy
From: [e-mail] (j.gordon.beattie)
Newsgroups: rec.ham-radio.packet
Subject: Re: ROSE X.25 Specifications.
Summary: ROSE Specification is CCITT X.25 PLP or ISO 8208
Keywords: ROSE X.25 KA9Q
Message-ID: <[e-mail]>
Date: 6 Dec 90 20:50:46 GMT
References: <skcm.660468657@echo>
Organization: AT&T Bell Laboratories
Lines: 30

In article <skcm.660468657@echo>, [e-mail] (Carl Makin) writes:
> Does wnyone know ehere I can get the specification for the X.25 links between
> ROSE nodes.  I am interested in putting code similar to the NET/ROM code
> into NOS for ROSE.
>
Carl,
     I can not only supply you with a reference to the specification
for the ROSE Packet Layer Protocol (see Summary line above), but I can
also provide you with source code in very portable "C" which could make
your work much simpler.  The source code is the same "PROTOCOL" code as
is running today in the ROSE X.25 Switches.  Tom, W2VY provided RATS
(The Radio Amateur Telecommunications Society) with a complete set of
source code for the ROSE X.25 Switch as of 10/13/88.  I must emphasize
that his changes in the current software release are in the "SWITCH"
and "APPLICATION" modules, not the "PROTOCOL" module.
Please contact me via email or preferably telephone.  I can provide
the access information so that you can download the software when we
talk.

BTW: Anyone else interested please feel free to call.
73,
Gordon Beattie +1.908.615.4168 (office) +1.201.387.8896 (home)
n2dsy\@hou2d.att.com
n2dsy\@n2dsy.nj.usa.na   (Americans are geographical illiterates.
              This is the unspoken reason for the
              continent indicator.)

> Carl
> [e-mail]
> [e-mail]
Path: ucsd!pacbell.com!ames!sun-barr!apple!winter
From: [e-mail] (Patty Winter)
Newsgroups: rec.ham-radio.packet
Subject: Re: Where do I get an IP address?
Message-ID: <[e-mail]>
Date: 6 Dec 90 19:11:49 GMT
References: <[e-mail]> <[e-mail]>
Distribution: ba
Organization: Apple Computer Inc., Cupertino, CA
Lines: 25

In article <[e-mail]> [e-mail] (Jerome Kaidor) writes:
>
>    I'd like an IP address too.  Who's the coordinator for Northern
>California?  Also, is there a listing anywhere of gateway stations?
>I.E., if I want to "get on the network", which station do I call?
>What frequency do I use?  There are lists of IP addresses on the
>packet BBS's, but that's not enough.  I need at least one magic
>frequency...

Bay Area address coordinator: Doug Thom N6OYU  [e-mail]
    Send him your name, callsign, address, phone number, and
    the city in which your packet station will be located
    (some people run them from work instead of home)

Magic frequency in this area: 145.75.  The San Jose gateway and
all local individual users are there.


73,
Patty
--
*****************************************************************************
Patty Winter N6BIS                        INTERNET: [e-mail]
AMPR.ORG: [44.4.0.44]                     UUCP: {decwrl,nsc,sun}!apple!winter
*****************************************************************************
Path: ucsd!sdd.hp.com!wuarchive!cs.utexas.edu!news-server.csri.toronto.edu!utgpu!utzoo!henry
From: [e-mail] (Henry Spencer)
Newsgroups: rec.ham-radio,rec.ham-radio.packet,sci.space
Subject: Re: * SpaceNews 03-Dec-90 *
Message-ID: <[e-mail]>
Date: 6 Dec 90 17:36:28 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Organization: U of Toronto Zoology
Lines: 31
Xref: ucsd rec.ham-radio:16039 rec.ham-radio.packet:2556 sci.space:13649

In article <[e-mail]> [e-mail] (Franklin Antonio) writes:
>... How can this billions of years stability stuff be science
>if you can't test the result of the theory?  Meet me in two billion years
>for pizza.  If it turned out that the solar system WAS stable, i'll buy you
>a beer.

Seen in Usenet newsgroup sci.space.celmech.history, 6 Dec 2000001990:

    The adjudicating committee appointed last year has regretfully
    announced that the Two Billion Year Bet has had to be called off.
    The pizza was good, but everyone had to buy their own beers.
    (The management did, however, agree to a special rate, only
    $6945/liter for an excellent import from Heidelberg IV.  The
    local branches of the major US brewers offered to provide beer
    free, but everyone naturally ignored them.)  Citing impossible
    difficulties in deciding whether the solar system would have
    been stable if left alone, the committee concluded that no
    settlement of the bet was possible.  "Moving Venus and Mercury
    out was not that big a deal, and we think we could have allowed
    for that, but the Arts Council grant of 3476876 for rearranging
    the asteroids into aesthetically pleasing formations by modulating
    the orbit of Jupiter just caused hopeless confusion, and when the
    Flat Ecliptic Society started tidying the orbits up in preparation
    for the Galactic Fair of 78654379, well, that was the last straw.
    Not even the generous donation of five milliseconds of Cray-94673
    time by UUNET Intergalactic Communications Inc was sufficient to
    decide what would have happened if the upkeep of the solar system
    had been neglected for so long."
--
"The average pointer, statistically,    |Henry Spencer at U of Toronto Zoology
points somewhere in X." -Hugh Redelmeier| [e-mail]   utzoo!henry
Path: ucsd!usc!zaphod.mps.ohio-state.edu!rpi!uupsi!uhasun!jbloom
From: [e-mail] (Jon Bloom)
Newsgroups: rec.ham-radio.packet
Subject: Re: Where can I find more AX25 protocol descriptions?
Summary: Standard available from ARRL
Message-ID: <[e-mail]>
Date: 6 Dec 90 13:59:49 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: The University of Hartford
Lines: 30

In article <[e-mail]>, [e-mail] (Meir) writes:
> In article <[e-mail]> [e-mail] (Joni-Pekka Kurronen) writes:
> >Hi you !
> >
> >I am  very sorry but i do not know where to find from internet.
> >ax.25 standards are published at 7:th Network Conference book. I hope
> >you get better answer.
> >
> >73 kurre oh5bzr

No, the material in the 7th Computer Networking Conference Proceedings is
*not* the standard.  That information is about proposed changes.  The
actual changes adopted differ somewhat from what is published in the
7th CNC.  The new version isn't yet published, and until it is version
2.0 of AX.25 remains the official ARRL standard.

> There are many books written on the subject of Amateur Packet Radio including
> a Radio Shack version and an American Radio relay League version.  The AX.25
> info is probably also in the latest editions of the ARRL Handbook for the
> Radio Amateur.  The ARRL is in Newington, CT (I don't have their address here).

The standard is entitled, "AX.25 Amateur Packet-Radio Link-Layer
Protocol."  ARRL can be contacted at 225 Main St., Newington, CT 06111
tel: [phone]


--
Jon Bloom, KE3Z                              | American Radio Relay League
Internet: [e-mail]         |
Snail:    225 Main St., Newington, CT 06111  | "I have no opinions."
Path: ucsd!usc!zaphod.mps.ohio-state.edu!rpi!masscomp!ocpt!tsdiag!davet
From: [e-mail] (Dave Tiller N2KAU)
Newsgroups: rec.ham-radio.packet
Subject: Re: Using a TNC to `dial in' to a Unix box?
Keywords: tnc packet unix
Message-ID: <[e-mail]>
Date: 6 Dec 90 16:33:43 GMT
References: <[e-mail]>
Organization: Concurrent Computer Corp. Oceanport NJ
Lines: 31

In article <[e-mail]> [e-mail] (Warren Toomey) writes:
-Just a quick question, has anybody set up a system to allow connections on
-a TNC to be directed to  aserial port on a Unix box, with a login(1) running
-on the port?
-I'd like people connecting to my TNC to get a login: prompt not to use KA9Q
-or TCP [this is in fact Minix] multiple connections would be nice :-)
-Initially, there will be a guest account with a restricted
-environment & no password, so password transmission will not be a
-worry.


Yes, it has been done. A friend of mine, ka2qhd, runs a unix bbs here in
central (New) Jersey that does just that.  Note that you might want to put
the tnc in transparent mode, and enable the periodic timer that sends packets
every second or so, even if there hasn't been a <cr> sent. This allows things
like vi and the shell to output non-<cr> terminated lines. (Like your prompt.)
Another thing - if your TNC has DCDCONN, use it. This will cause the users
session to be aborted if they forget to log out and just disconnect. This
command causes the DCD line on the tnc/computer connection to follow the state
of the connection.  You may have to tell login() or getty() to listen to DCD.
Multiple connections are possible when running ka9q on a unix system with
pseudo ttys. (ttyp0...vtty0).  Note that ka9q can be run in the background -
you don't need to tie up the machine with just net.  You can also have the
xobbs running at the same time, and allow simultaneous telnet logins, ftp
sessions, and bbs connections.  Pretty powerful! Good luck, see ya on the air!
If you'd like more details, send me email at [e-mail].
--
David E. Tiller         [e-mail]  | Concurrent Computer Corp.
FAX:  [phone]      Ph: [phone] (w) | 2 Crescent Place, M/S 117
UUCP: ucbvax!rutgers!petsd!tsdiag!davet        | Oceanport NJ, 07757
ICBM: 40 16' 52" N      73 59' 00" W           | N2KAU @ NN2Z

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

End of Packet-Radio Digest
******************************
Date: Sat,  8 Dec 90 04:30:05 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #214
To: packet-radio


Packet-Radio Digest         Sat,  8 Dec 90       Volume 90 : Issue 214

Today's Topics:
          Anyone tried full-duplex packet? (2 msgs)
          AX25 CRC Polynomial, what is it? (2 msgs)
              Ka9q Net software.
                 mac 512K s/w
              Packet in Germany
                pk232 software
        ROSE X.25 Switch distribution (2 msgs)
             Source for HARN, PC-100, NOS
                tower
           Using a TNC to `dial in' to a Unix box?

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 90 13:36:34 GMT
From: swrinde!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!sics.se!sics.se![e-mail]  (Anders Klemets)
Subject: Anyone tried full-duplex packet?
To: [e-mail]

> Using a split
> frequency repeater (preferably crossband) makes it possible to provide
> true collision detection in the Ethernet sense over packet radio.

How is one supposed to detect the collision using AFSK? Won't it in
most cases be impossible to determine if there has been a collision
unless the checksum test has failed?
Busy Tone Multiple Access, BTMA, is easier to implement and probably
more efficient since the collsions are avoided rather than detected.
A drawback with BTMA is that the capture effect in the receivers may
cause one to defer from transmitting when it isn't really necessary.

Anders

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

Date: 7 Dec 90 17:38:15 GMT
From: deccrl!news.crl.dec.com!shlump.nac.dec.com!delni.enet.dec.com![e-mail]  (Fred R. Goldstein)
Subject: Anyone tried full-duplex packet?
To: [e-mail]

In article <[e-mail]>, [e-mail] (Anders Klemets) writes...
>> Using a split
>> frequency repeater (preferably crossband) makes it possible to provide
>> true collision detection in the Ethernet sense over packet radio.
>
>How is one supposed to detect the collision using AFSK? Won't it in
>most cases be impossible to determine if there has been a collision
>unless the checksum test has failed?

Please clarify that effect for me.  As I see it, and I may be wrong,
a FDX repeater allows the node to hear what it's transmitting.  True,
it's not like Ethernet where collision = 6V instead of 3V.  So you
may have to wait to hear the checksum to know that collision didn't
occur.  Thus it doesn't really pass the "CD" test for "CSMA/CD".

But it does do away with Hidden Transmitter Syndrome, within the
limits imposed by propagation delays (300km/s).  So you do have carrier
sense, making collision MUCH less likely.  And if you do have collision,
and capture occurs, then at least that party gets its packet through,
something you don't get on Ethernet.

If the sending node had some kind of comparator for received-bits and
transmitted-bits, taking the turnaround delay into acount, then
CSMA/CD might be essentially possible.  But it would not be trivial
to implement, and would be needed at every end node.  Offhand, then,
I'd say straight CSMA (listen before transmitting, FDX repeater) is
about the best we're likely to get for a while for "access" users.

Since the present HTS-laden channels are barely Aloha quality,
CSMA would probably deliver MORE THAN TWICE the throughput than
we get now, using only twice the bandwidth, so our bandwidth efficiency
would go UP by using repeaters.  Of course the FM yakkers who pretend to
be spectrum managers often make this difficult, but we had that flame
war last year on this newsgroup so I needn't raise it again.
---
Fred R. Goldstein     k1io     Digital Equipment Corp., Littleton MA
[e-mail]   voice: [phone]
 Do you think anyone else on the planet would share my opinions, let
 alone a multi-billion dollar corporation?

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

Date: 6 Dec 90 18:42:21 GMT
From: mcsun!ukc!uos-ee![e-mail]  (Elec. Eng. Amateur Radio Society)
Subject: AX25 CRC Polynomial, what is it?
To: [e-mail]

I am intending to implement a TNC using an Intel 83C152. This chip has an
on board serial interface which supports SDLC. I have a copy of the AX25
protocol spec but if refers to another document for the CRC polynomial,
therefor could someone please post the polynomial used in AX25 so that I
can check if the 83C152's CRC polynomial is correct,

    thanks,
        DF.   (G7FVS)

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

Date: 7 Dec 90 19:54:56 GMT
From: mintaka!think.com!sdd.hp.com!zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!ux1.cso.uiuc.edu![e-mail]  (Phil Howard KA9WGN)
Subject: AX25 CRC Polynomial, what is it?
To: [e-mail]

[e-mail] (Elec. Eng. Amateur Radio Society) writes:
>I am intending to implement a TNC using an Intel 83C152. This chip has an
>on board serial interface which supports SDLC. I have a copy of the AX25
>protocol spec but if refers to another document for the CRC polynomial,
>therefor could someone please post the polynomial used in AX25 so that I
>can check if the 83C152's CRC polynomial is correct,

I find this practice of leaving out things that can be explained without
a great deal of text, especially in a publication not (formally) intended
for engineers and professors, disgusting.

It would have been trivial to simply give the binary value for the
polynomial in the text of AX25.  I also believe it would not have been
that much more text to explain how it works.  This explaination would
be better in a tutorial on packet, but it definitely belongs somewhere.

Of course you can't get entirely away from making some subtle references
to other technology.  But when it is necessary to expressly make such a
reference, consideration should always be made as to the worth of using
full text instead of a reference.

Whenever any publication does make critical references such as the case
with the AX25 CRC polynomial, there should be included an appendix that
explains where to get the necessary publication and including its price
as of the date of publication of the reference.
--

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

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

Date: 8 Dec 90 03:57:36 GMT
From: ogicse!clark![e-mail]  (Adrian Miranda)
Subject: Ka9q Net software.
To: [e-mail]

I have an application where I would like ka9q to come up, starting
it's smtp demon, run for a few minutes, then exit gracefully.  Is this
possible?  Also, is there a mailing list for discussing ka9q?

Adrian Miranda
uunet!clark!ade  or  [e-mail]

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

Date: 7 Dec 90 13:15:04 GMT
From: usc!hacgate!wlbr!lonex.radc.af.mil![e-mail]  (William J. Szarek)
Subject: mac 512K s/w
To: [e-mail]

I just got started in packet and have an MFJ 1278 and an old mac (512K).

does anyone have any software that i can use?

I am currently using a terminal program but this won't allow me to 'play'
with fax sstv etc.  I would also like something to use the mac to run the
mailbox and such since it is more powerful that the 1278.

thanks
buzz
WM1W
[e-mail]

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

Date: Fri, 7 Dec 90 13:22:12 CET
From: [e-mail] (Captain McCartin)
Subject: Packet in Germany
To: [e-mail]

 Greetings,

 Sorry if this has been asked a million times, but I'm new to this list
 and to Packet Radio.  I live in Stuttgart, Germany, and I've already
 sent off for my "DA" license (i.e. an American military license for
 operating in Germany).  While I'm waiting for my ticket, I'd like to ask
 a few questions about packet radio.

 Specifically:

    a.  What type of packet activity is there in Southern
        Germany?  I'm specifically interested in TCP/IP and
        internetworking.

    b.  The only rig I have is an ICOM 735.  Are there any problems
        using this radio with a TNC?  Additionally, what type of
        TNC is best for HF packet work.

    c.  Is there a Packet Radio Club in Southern Germany?  I'll
        probably need some help getting started.

    d.  Finally, is there any packet activity with MARS?  I'm in the
        military, but there isn't a MARS station at my base yet.
        Maybe I could get something started.

 Thanks in advance,

    WB1BQF
 --
 ***********************************************************************
 *  Capt Joe McCartin                   [e-mail]    *
 *  System Engineer, ECJ6-CD            (COMM) [49]-711-680-7168       *
 *  HQ US European Command              (AV)   430-7168                *
 *  Stuttgart, West Germany                                            *
 ***********************************************************************

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

Date: 6 Dec 90 17:01:53 GMT
From: infopiz!lupine!hansen![e-mail]  (Phil Graham)
Subject: pk232 software
To: [e-mail]

In article <[e-mail]>,
[e-mail] (Larry Hunter) writes:
|> I just got a PK232 to add to my SWL setup, and I'd like pointers to
|> software for displaying fax & RTTY stuff and/or controling the beast.
|> The controlling computer is an old sun, so source code pointers would
|> be appreciated, although any tips at all are welcome.  Also, if anyone
|> has written code for controling a Kenwood R5000 they'd be willing to
|> share, I'd be interested.
|>
AEA markets software that will run on several hardware bases.  I
understand that they have a new version of the
RTTY/AMTOR/PACKET/MORSE/etc software due out any day...  They also sell
with this an old version of the PK-FAX software that will allow you to
receive/store to disk/print FAX pictures!

|> BTW, I tried looking at the hamradio/packet directory of the ucsd.edu
|> anonymous ftp site, and there are two files pk232.arc and
|> pk232-com.arc, but they are both unreadable by the public.  Any idea
|> what they are and why they are unreadable?
Hmmmm... Sounds interesting!



Phil
KJ6NN

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

Date: 7 Dec 90 22:07:15 GMT
From: att!cbnewsh![e-mail]  (j.gordon.beattie)
Subject: ROSE X.25 Switch distribution
To: [e-mail]

I just posted the ROSE X.25 Switch code version RSWD1111.ZIP
and realized that it may arrive at some sites in a truncated
state.  If this is the case send me an email or call me on
the telephone and I will either resend it cut into pieces,
or I'll send you a copy via email or postal mail.
Thanks,
Gordon Beattie n2dsy  +1.201.387.8896 (Home)  +1.908.615.4168 (Office)
[e-mail]  or packet: [e-mail]

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

Date: 7 Dec 90 22:25:22 GMT
From: [e-mail]  (Brian Kantor)
Subject: ROSE X.25 Switch distribution
To: [e-mail]

In article <[e-mail]> [e-mail] (j.gordon.beattie) writes:
>I just posted the ROSE X.25 Switch code version RSWD1111.ZIP
>and realized that it may arrive at some sites in a truncated
>state.

It will arrive truncated at some sites, and it won't appear in the
digest at all.  Nothing over 500 lines long does.

Look, dudes, the proper way to distribute software is to put it out
where people who want it can grab it, not to send it to thousands of
sites in the hope that one out of a hundred may care about it.

Anonymous UUCP and FTP, plus telephone BBSs do this well.

    Brian Kantor    WB6CYT  UC San Diego   [e-mail]

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

Date: 7 Dec 90 23:40:32 GMT
From: sunriv![e-mail]  (Ronnie Hughes)
Subject: Source for HARN, PC-100, NOS
To: [e-mail]

In article <[e-mail]> [e-mail] (Phil R. Karn) writes:
>
>You can buy cards that provide both the HDLC framing and modem functions.
>DRSI has the PC Packet Adaptor, while PACCOMM has the PC-100 and Hamilton
>Area Packet Radio has their HAPN card. A new group in Ottawa has just
>come out with an HDLC card that supports DMA (invaluable for high speed
>modems) but it does not have an on-card low speed modem.
>
>Phil

Where can one can purchase the HAPN and the PC-100 card?  I've
seen the ads for the DRSI card and the recent posting about the
Ottawa card, but I would like to look at the other two before
buying one.

Also, where can a non-ftp site obtain the lastest source for
NOS?  Anything available via uucp?  What happened to uucp site
"winfree" as described in the doc that came with KA9Q NET?

Ronnie, N5CSE   [e-mail] -or- uunet!sunriv!ronh

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

Date: 6 Dec 90 18:40:16 GMT
From: csus.edu!wuarchive!zaphod.mps.ohio-state.edu!van-bc!ubc-cs!alberta!herald.usask.ca!weyr![e-mail]  (Vernon Geddes)
Subject: tower
To: [e-mail]

is there a tower that will come down (automatic) when the winds
go above say 50 mph. then go backup when the winds decrease.

if there is, where can i get one, and (the normal question) how much.


--
Vernon Geddes - via FidoNet node 1:140/22
UUCP: ...!herald!weyr!Vernon.Geddes
Domain: [e-mail]
Standard Disclaimers Apply...

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

Date: 7 Dec 90 11:52:44 GMT
From: mcsun!ukc!axion!uzi-9mm.fulcrum.bt.co.uk!beta.its.bt.co.uk![e-mail]  (John Trickey)
Subject: Using a TNC to `dial in' to a Unix box?
To: [e-mail]

I did this with SysVR0.  It required nothing special.  I modified
/etc/gettydefs to include a banner to tell the uninitiated how to
log in and set the TNC220 to TRANSPARENT mode.

John
--
John Trickey <[e-mail]> || ..!mcsun!ukc!axion!its
          G4REV @ GB7SUT      Voice: [phone]
#include <std/disclaimer>

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

End of Packet-Radio Digest
******************************
Date: Mon, 10 Dec 90 04:30:04 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #215
To: packet-radio


Packet-Radio Digest         Mon, 10 Dec 90       Volume 90 : Issue 215

Today's Topics:
                JA WP server .

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

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

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

Date: Mon, 10 Dec 90 16:00:48 JST
From: KOMATSU Toshiki <[e-mail]>
Subject: JA WP server .
To: [e-mail]

     Hello , OM.

     RLI/MBL Network is popular in JA packet . Then someone asked me
calls of WP server . Now , JR1YDM.JNET1.JPN is storing many data
of user / sysop .
     I forgot his name , so that posted mailing list .

     CUL

/ KOMATSU Toshiki
Coll.of Phisical Sci.(chem.) ,The Univ.of Tsukuba ,Tsukuba-city .
Phone :[phone]  S-mail:P.O.Box 53,Tsukuba-Gakuen,305,JAPAN
RLInet:JF7WED@JF7WED.#14.JNET1.JPN.AS  ( MBX98 , Loc.QM06BC )

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

End of Packet-Radio Digest
******************************
Date: Tue, 11 Dec 90 04:30:04 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #216
To: packet-radio


Packet-Radio Digest         Tue, 11 Dec 90       Volume 90 : Issue 216

Today's Topics:
           Anyone tried full-duplex packet?
          AX25 CRC Polynomial, what is it? (2 msgs)
            commodore 64 keyboard
     I wish to subscribe to packet radio list (puhleeze!)
            Need some info on Hams
              Packet/Amtor with TS-130S
        ROSE X.25 Switch distribution (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: 10 Dec 90 22:32:00 GMT
From: envy![e-mail]  (Phil R. Karn)
Subject: Anyone tried full-duplex packet?
To: [e-mail]

Fred Goldstein and Anders Klemets both ask how collision detection can
be done when a full-duplex RF repeater is used.

Fred says:

|> If the sending node had some kind of comparator for received-bits and
|> transmitted-bits, taking the turnaround delay into acount, then
|> CSMA/CD might be essentially possible.

This is what I had in mind. If you simply compare the incoming
characters with those in the transmit buffer, then you can quickly
detect a collision that keeps you from hearing your own data through
the repeater. You can also use framing errors (aborts, premature
flags, etc) as an indication that you have not captured the repeater.

I don't think this is a particularly difficult scheme. You do have to
handle the monitored data in software (unless somebody has a
controller that can do a "receive verify" operation in hardware) but
at least the transmitter can be DMA-driven.

Phil

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

Date: 10 Dec 90 21:02:29 GMT
From: deccrl!news.crl.dec.com!shlump.nac.dec.com!koning.enet.dec.com![e-mail]  (Paul Koning)
Subject: AX25 CRC Polynomial, what is it?
To: [e-mail]

|> I am intending to implement a TNC using an Intel 83C152. This chip has an
|> on board serial interface which supports SDLC. I have a copy of the AX25
|> protocol spec but if refers to another document for the CRC polynomial,
|> therefor could someone please post the polynomial used in AX25 so that I
|> can check if the 83C152's CRC polynomial is correct,
|>
|>      thanks,
|>              DF.   (G7FVS)

I assume you want the name or the like of the CRC, not a tutorial on what
a CRC is.  If so, the answer is simple:  AX.25 uses the same one that
LAPB uses, which is generally known as "CRC-CCITT".

    paul, ni1d

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

Date: 11 Dec 90 02:58:23 GMT
From: agate!shelby!neon![e-mail]  (Marc T. Kaufman)
Subject: AX25 CRC Polynomial, what is it?
To: [e-mail]

In article <[e-mail]> [e-mail] (Paul Koning) writes:
-|> I am intending to implement a TNC using an Intel 83C152. This chip has an
-|> on board serial interface which supports SDLC. I have a copy of the AX25
-|> protocol spec but if refers to another document for the CRC polynomial,
-|> therefor could someone please post the polynomial used in AX25 so that I
-|> can check if the 83C152's CRC polynomial is correct,
-|>
-|>     thanks,
-|>             DF.   (G7FVS)

>I assume you want the name or the like of the CRC, not a tutorial on what
>a CRC is.  If so, the answer is simple:  AX.25 uses the same one that
>LAPB uses, which is generally known as "CRC-CCITT".

Which is X^16 + X^12 + X^5 + 1
How come I have seen 3 replies to the above request, NONE of which bothered
to give the answer the man wanted?

Marc Kaufman ([e-mail])

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

Date: 7 Dec 90 18:50:24 GMT
From: van-bc!ubc-cs!alberta!herald.usask.ca!weyr!f31.n140.z1.FIDONET.ORG![e-mail]  (Dan Garret)
Subject: commodore 64 keyboard
To: [e-mail]

hi there as you can see from the head title i am selling a commodore c64 key board. i will be willing to sell it for around $60-80. sounds good??? leave me a message if your interested. BBfn.

--
Dan Garret - via FidoNet node 1:140/22
UUCP: ...!herald!weyr!31!Dan.Garret
Domain: [e-mail]
Standard Disclaimers Apply...

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

Date: 8 Dec 90 22:42:05 GMT
From: att!bu.edu!wang!tosspot![e-mail]  (Lee Reynolds)
Subject: I wish to subscribe to packet radio list (puhleeze!)
To: [e-mail]

Hi.

Would any kind soul out there tell me the address to which to send a request
 for subscribing to the packet radio digest???

        Thanks,
               Lee

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

Date: 10 Dec 90 02:06:06 GMT
From: tronsbox![e-mail]  (Freddy Balady)
Subject: Need some info on Hams
To: [e-mail]

I heard about Ham Radio from a couple of my friends, and i'm started to get
interested in it.  Can someone send me mail explaining ham radio and packet
in general? I'm not very knowlegable about ham so any info would be great!
Thanks.

-Fred

--

----------------------------------------------------------------------------
Freddy Balady                                       [e-mail]
----------------------------------------------------------------------------

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

Date: 10 Dec 90 18:46:28 GMT
From: eru!hagbard!sunic!isgate!krafla![e-mail]  (Saemundur Thorsteinsson)
Subject: Packet/Amtor with TS-130S
To: [e-mail]

I just got an AEA-232 MBX which I intend to use with my
Kenwood TS-130S transceiver.  I wonder if anyone out there
has used this combination before, and if any OM/YL has suggestions
or advice regarding interfacing or T/R-switching.  I'm not
sure if the T/R-relays are fast enough for packet or
AMTOR.

73's de TF3UA    ([e-mail])

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

Date: 10 Dec 90 18:49:57 GMT
From: netnews.upenn.edu!platypus![e-mail]  (Bill Gunshannon)
Subject: ROSE X.25 Switch distribution
To: [e-mail]

In article <[e-mail]>, [e-mail] (Brian Kantor) writes:
>
> Look, dudes, the proper way to distribute software is to put it out
> where people who want it can grab it, not to send it to thousands of
> sites in the hope that one out of a hundred may care about it.
>
> Anonymous UUCP and FTP, plus telephone BBSs do this well.
>

I agree!!

And I have put it up for anonymous FTP at platypus.uofs.edu in pub/HAM-RADIO.

There are other goodies there also (even for MAC Users ;-) so feel free to
look around.  I also hope to have a phone line (only 1200 baud though :-( )
shortly and plan on offering anonymous UUCP as well.

I have limited space but will consider adding things of general interest
to Amateur Radio.
Just send me Email.

Enjoy.

bill    KB3YV


--

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

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

Date: 11 Dec 90 05:34:00 GMT
From: elroy.jpl.nasa.gov!usc!samsung!umich!vela![e-mail]  (Keith Petersen)
Subject: ROSE X.25 Switch distribution
To: [e-mail]

Now available from WSMR-SIMTEL20.ARMY.MIL [26.2.0.74]

Directory PD1:<MSDOS.PACKET>
 Filename   Type Length   Date    Description
==============================================
RSWD1111.ZIP  B   65996  901208  Hams: ROSE X.25 packet radio switch for TNC2

Keith
--
Keith Petersen
Maintainer of SIMTEL20's MSDOS, MISC & CP/M archives [IP address 26.2.0.74]
Internet: [e-mail]    or     [e-mail]
Uucp: uunet!umich!vela!w8sdz                          BITNET: w8sdz@OAKLAND

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

End of Packet-Radio Digest
******************************
Date: Wed, 12 Dec 90 04:30:04 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #217
To: packet-radio


Packet-Radio Digest         Wed, 12 Dec 90       Volume 90 : Issue 217

Today's Topics:
               Amateur Packet Radio PR
           AX25 CRC Polynomial, what is it?
         info on packet switching and ham BBS
           looking for satellite decoding software

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

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

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

Date: Tue, 11 Dec 90 16:29:36 MST
From: [e-mail] (Walter R Fletcher)
Subject: Amateur Packet Radio PR
To: [e-mail]

A quick note to those interested:
    The  "Ask Mr. Protocol"  column in the December 1990 (V 1 n.14) issue
of SunExpert has an above average article about amateur packet radio for those
of you looking for something to set in front of those  "types of people you'd
like to see become amateurs"  but are trying to get thier attention without
thrashing them about the head.  The article briefly goes over  "something the
hams are up to nowadays".

  Reid Fletcher, WB7CJO
  University of Wyoming Dept. of Geology and Geophysics/EORI/ISC

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

Date: 11 Dec 90 22:13:48 GMT
From: deccrl!news.crl.dec.com!shlump.nac.dec.com!koning.enet.dec.com![e-mail]  (Paul Koning)
Subject: AX25 CRC Polynomial, what is it?
To: [e-mail]

|> >I assume you want the name or the like of the CRC, not a tutorial on what
|> >a CRC is.  If so, the answer is simple:  AX.25 uses the same one that
|> >LAPB uses, which is generally known as "CRC-CCITT".
|>
|> Which is X^16 + X^12 + X^5 + 1
|> How come I have seen 3 replies to the above request, NONE of which bothered
|> to give the answer the man wanted?
|>
|> Marc Kaufman ([e-mail])
|>

Simple.  Because the databooks I have looked at tell you how to select the
CRC the chip will do, based on the NAME, not based on the polynomial.

    paul

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

Date: 11 Dec 90 16:16:07 GMT
From: uswat!csn![e-mail]  (GORDON ALLEN R)
Subject: info on packet switching and ham BBS
To: [e-mail]

I've posted a similar message on rec.ham-radio.  Having been away from amateur
radio for (embarrassingly) many years, I would like to get info on packet
switching, ham BBS and posible HAM links to internet/usenet.  Please reply by
email and I can post a summary.  Thanks a lot.

Allen Gordon

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

Date: 12 Dec 90 04:45:24 GMT
From: sdd.hp.com!news.cs.indiana.edu!ariel.unm.edu!nmsu!opus![e-mail]  (smouldering dog)
Subject: looking for satellite decoding software
To: [e-mail]

I am (still) trying to locate software that can be used to decode
satellite data on my amiga.  I have heard through friend-of-a-
friend-type references that such software exists but so far I have not
yet gotten anything into my hands.  any information would be useful.
    gratefully,
    owen white
--

-=-*-=-=-*-=-=-*-=-=-*-=-=-*-=-=-*-=-=-*-=-=-*-=-=-*-=-=-*-=-=-*-=-
    rebaptize your badness as the best in you
-=-*-=-=-*-=-=-*-=-=-*-=-=-*-=-=-*-=-=-*-=-=-*-=-=-*-=-=-*-=-=-*-=-

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

End of Packet-Radio Digest
******************************
Date: Thu, 13 Dec 90 04:30:04 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #218
To: packet-radio


Packet-Radio Digest         Thu, 13 Dec 90       Volume 90 : Issue 218

Today's Topics:
               Amateur Packet Radio PR
        Error correction on corrupted received packets

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

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

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

Date: 12 Dec 90 10:56:04 GMT
From: ogicse!uwm.edu!rpi!clarkson!@ucsd.edu  (Tadd, ,0,0)
Subject: Amateur Packet Radio PR
To: [e-mail]



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

Date: 12 Dec 90 02:36:12 GMT
From: agate!linus!philabs!briar![e-mail]  (Robert Casey)
Subject: Error correction on corrupted received packets
To: [e-mail]

I'm definitely no packet gruru, but I was wondering, if your TNC receives two
bad packets (the second was a failed attempt to resend the first), you could
do some processing to make it good.  Basically, do a compare between the two,
and locate where they differ (errors due to noise not likely to be identical).
And if the CRC that was received from the transmitting TNC match in both bad
packets, you could figure out how to correct the errors, and make a good
packet.

Sequence:

-receive first packet, CRC says that it is in error, so save it to a buffer.
-receive second try, this one bad too.
-compare CRCs of both packets.  If they match, assume that CRCs are not
   corrupted, and proceed.
-compare both bad packets, find errors (where the compare don't match)
-try various values at the errors until the CRC is happy, or figure out what
  values would make the CRC happy.
-use new values to repair the packet.
-then you can avoid having to tell the transmitting station to try sending the
   packet again.

I would think that this might improve things in somewhat noisy environments.
Don't know how big of errors can be fixed by the above, or if you might get
fooled into thinking you corrected things when you haven't.  But you wouldn't
have to change the transmitting standard, here the receiver TNC becomes a
little smarter.
---------------------------------------------------------------------
send e-mail to WA2ISE@KD6TH on packet, as my account (and my job!) may die
soon.  Also, if you know anyone looking for a person who knows HDTV, regular
NTSC TV, DSP circuit design, and high speed logic circuit design, have them
call me at 201-261-4066.  Also, point any and all headhunters my way.
I have 11 patents in the TV field.
Thanks in advance.   73 de WA2ISE

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

End of Packet-Radio Digest
******************************
Date: Fri, 14 Dec 90 04:30:03 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #219
To: packet-radio


Packet-Radio Digest         Fri, 14 Dec 90       Volume 90 : Issue 219

Today's Topics:
          56KB 70KHz modem vs 3KHz land-line modems
            AX25 CRC Poly., thanks
        Error correction on corrupted received packets
               ICOM R1 for sale
                   I sub x2
            Rose software? where? (2 msgs)
             Source for HARN, PC-100, NOS

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 90 15:56:37 GMT
From: mcsun!ukc!uos-ee![e-mail]  (Mike Willis)
Subject: 56KB 70KHz modem vs 3KHz land-line modems
To: [e-mail]

In article <[e-mail]> [e-mail] (Dan Keizer) writes:
>I see that the 56Kbaud modem operates with 70KHz.  That seems to be the
>same as the 2400 baud rates at the land-line 3KHz.  I also noticed that
>with the land-line systems today, you can get 19.2KB over 3KHz voice-line.
>Is it safe to assume that with the same type of technology applied that
>you can get 440KBaud at 70KHz?  I don't know that much about spectrum
>and bandwidth, but the figures look correct.  Anyone care to explain some of
>this to me?
>
>Dan
>+---------------------------------+-------------------------------------------+
>| Dan Keizer                      | To each his own ... thoughts included.    |
>| Western Software Solutions      |                                           |
>| ...!cpsc.ucalgary.ca!wsscal!dan |                                           |
>+---------------------------------+-------------------------------------------+

I tried to reply to this earlier, but as usual, our computer system
crashed, sysops messing with the operating system again, why they cant
leave things alone beats me. Anyway, the answer to the question is Yes.

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

Date: 11 Dec 90 18:44:06 GMT
From: mcsun!ukc!uos-ee![e-mail]  (Elec. Eng. Amateur Radio Society)
Subject: AX25 CRC Poly., thanks
To: [e-mail]

Thanks to Paul Korning (NI1D) and Marc Kaufman for replying, I now know that
my TNC should work, as the 80C152 uses the CCITT CRC polynomial. I say should
as I can still get the software wrong! :-)

Sorry about posting this thankyou but I cannot send mail outside the UK from
this account.

    DF. (G7FVS)

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

Date: 12 Dec 90 19:09:57 GMT
From: envy![e-mail]  (Phil R. Karn)
Subject: Error correction on corrupted received packets
To: [e-mail]

In article <[e-mail]> [e-mail] (Robert Casey) writes:
>I'm definitely no packet gruru, but I was wondering, if your TNC receives two
>bad packets (the second was a failed attempt to resend the first), you could
>do some processing to make it good.

Given the way HDLC works, this is easier said than done. Errors could
easily upset the bit-stuffing logic, so bits might be added or deleted
and you might not know where you are in the packet. This would make it
difficult to compare bits between packets. And if the errors lose (or
create) flags, you're pretty much hosed.

The right way to do forward error correction (which is what you're describing)
is to design a completely new framing scheme that is intended to work with
a convolutional or block-coded FEC code. This means having special "sync"
sequences at the beginning of each frame that can be recognized even if
some bits are damaged, among other things. It also assumes that your
errors are gaussian, which may not be a valid assumption given that most
packets are lost due to collisions with other stations.

One FEC scheme that would retain the current framing method would work at
a somewhat higher layer. Send your message as a series of HDLC frames, as
you do now. Append to this a series of "parity" frames generated with a
Reed-Solomon block code. At the receiver, you discard all frames with CRC
errors. Then use the Reed-Solomon code to regenerate the missing frames
from the frames you got.

This is known as an "erasure correcting" (as opposed to "error correcting")
code because you still use the individual frame CRCs to detect the errors,
i.e., to generate "erased" frames. The nice thing about the Reed Solomon
code when used this way is that it can regenerate ANY combination of
erased frames, up to the number of parity frames that were originally
sent.

For example, if your transmission consists of 10 message frames and 4
parity frames (a total of 14 frames) then you could lose any combination
of up to 4 frames out of this transmission and still not lose any data.

To be able to recover from the loss of any 4 frames in a transmission
that uses simple "repetition coding" (i.e., sending everything
multiple times) you'd have to send each data frame 5 times, for a
total of 50 frames on the channel. And of course given the larger
number of frames, this would be a frame loss rate of only 4/50 = 8%,
compared to a tolerable loss rate for the Reed-Solomon case of 4/14 = 28%.

The same Reed-Solomon software could be used at the transmitter and
receiver; consider that the generation of the parity frames at the
transmitter is exactly the same operation as regenerating them at the
receiver when they're lost in transit. Of course, a receiver need not
always invoke the erasure-correcting code; if it gets all of the data
frames OK, it can simply ignore the parity frames since they're not
needed.

This scheme is still not as effective against random (gaussian) noise as
a bit-level FEC code would be, but it is something that could be implemented
in amateur packet radio without any hardware changes. It would be especially
effective in a broadcast protocol; I've recommended it for use in the
Microsat/Pacsat satellite broadcast protocol.

Much of the credit for this idea goes to my Bellcore colleague Tony
McAuley, who originally suggested this scheme for use on broadband
ISDN in his SIGCOMM '90 paper. When I read it I realized that the
exact same scheme could be applied to amateur packet radio.

Phil

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

Date: 13 Dec 90 04:47:02 GMT
From: csn![e-mail]  (Bob Coggeshall)
Subject: ICOM R1 for sale
To: [e-mail]

This is the amazing, tiny, hand-held 150khz to over 1GHZ continous
coverage scanner. It receives AM, narrow and wideband FM. Unavailable
in the US not only because it gets cell phone, but also due to patent
infringments.

My friend just brought one back fresh from Japan.  He is asking $600.

----
Bob Coggeshall
[e-mail]
303/492-6096

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

Date: Thu, 13 Dec 90 18:23:23 EST
From: "Ken Wieringo [e-mail]" <[e-mail]>
Subject: I sub x2
To: Adminstrator <[e-mail]>

I subscribed twice, I meant to sub to pacKrad not a second time to I-pacrad.
Can you take me off the double or does listserver double check(no pun intended)
for two timers:-)  ?   Ken

     >>[e-mail]< AND.BITNET<  >OR IP#, 128.173.4.1<<
 >>PHONES COMMERCIAL AND SCATS 703-857-7584<<  >>VATECH CAMPUS 13855<<
 >>FAX [phone]<< >>SYSM AT UVA MERCURY U820<< >>IBMMAIL(USVPITMA)<<
 2M PACKET AX.25 N4LYO @ N4MGQ.VA.USA.NA<<>>ARMY MARS AAT3PK/VA >TEXN<<
         ROANOKE VALLEY GRADUATE CENTER
          POST MAIL: 117 W. CHURCH AVE.
            ROANOKE, VA. 24011-1905

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

Date: 12 Dec 90 15:47:31 GMT
From: van-bc!ubc-cs!news-server.csri.toronto.edu!utgpu!watserv1!ria!uwovax![e-mail]  (Mark Bramwell 1-519-661-3714)
Subject: Rose software? where?
To: [e-mail]

I think I missed something somewhere.  As a true hacker willing to try
anything once, I grab the RSWD1111.ZIP file.  I thought I would burn a
chip to try in one of my spare TNCs.  When I unZIP the file, it is all
TXT files.  There were no .EXE .BIN or anything else.

I am still interested in trying the rose software.  Is there someplace
other than simtel20 that has the .ZIP file?   (simtel20 is  ALWAYS busy)

thanks in advance,    mjb.--


..........................................................................
.  Mark Bramwell,    VE3PZR                                              .
.                                                                        .
.  The University of Western Ontario           Bitnet:  [e-mail]  .
.  School of Business Administration           Packet:  VE3PZR @ VE3GYQ  .
.  London, Ontario, N6A 3K7                    Phone:   (519)  661-3714  .
..........................................................................

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

Date: 13 Dec 90 13:31:58 GMT
From: bagate!dsinc!netnews.upenn.edu!platypus![e-mail]  (Bill Gunshannon)
Subject: Rose software? where?
To: [e-mail]

In article <[e-mail]>, [e-mail] (Mark Bramwell 1-519-661-3714) writes:
>
> I am still interested in trying the rose software.  Is there someplace
> other than simtel20 that has the .ZIP file?   (simtel20 is  ALWAYS busy)

As soon as I get them from Gordon (N2DSY) they will be available for
ANONYMOUS FTP from platypus.uofs.edu.  It's never busy.  :-)

I will post when I put them up.

bill    KB3YV

--

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

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

Date: 10 Dec 90 22:36:49 GMT
From: hpfcso!hpfcmdd!hpbbrd!hpbbn!hpcc05!col![e-mail]  (Bdale Garbee)
Subject: Source for HARN, PC-100, NOS
To: [e-mail]

>Where can one can purchase the HAPN and the PC-100 card?

Dunno about the HAPN card.  The PC-100 is a product of PacComm.

>Also, where can a non-ftp site obtain the lastest source for
>NOS?  Anything available via uucp?  What happened to uucp site
>"winfree" as described in the doc that came with KA9Q NET?

The machine 'winfree' is my personal unix machine at home.  At one time it
ran a BBS and provided anonymous uucp access, but the work for me to maintain
the service ceased to be acceptable, so I stopped.

Bdale

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

Date: (null)
From: (null)
The number of bits a symbol represents depends on the alphabet (ie how
many different symbols there are). In computing circles we are normally
only concerned with two symbols, 0 and 5V in TTL or +12 and -12V in RS232.
If you imagine a system that had four states, say 0V 1V 2V 3V, then it
would be possible to send two bits at once. This is because two bits can
represent a maximum of four states (00 01 11 10). If we were to transmit
one of these symbols each second, then we would be sending at 1 baud, but
at 2 bits/sec. I am sorry if this is overly simplified, I am trying to
make it as clear as possible.

Telephone modems use a transmission technique with an alphabet of many
symbols. If for example you consider a QPSK modem, this has four symbols,
represented by the phase of the carrier. A channel at 2400 baud QPSK,
carries 4800 bits per second, but only requires a minimum of 2.4 kHz
bandwidth. If 64 phase modulation is used, then 8 bits can be sent at
once, and the bit rate would be 19.2 kbits per second. (This is not how
the telephone modems do it). To prevent inter symbol interference, and
make use of real filters, the bandwidth for phase shift keying needs to be
about 1.4 times the baud rate, so 2400 baud will work down a 3.4 kHz
telephone channel. As you increase the number of symbols, there is a
greater chance of noise causing one symbol to be mistaken for another. As
a general rule, doubling the number of symbols requires a doubling in the
signal to noise ratio to maintain the same error rate. Assuming that the
SNR is infinate, the any data rate can be supported in a channel of
arbitarily small bandwidth. In the real world, 8 bits per baud is about
the limit, though 256 and 512 symbol alphabets are possible in complex
(read expensive) systems.

All this is based on Shannons' theory. For maore information, look up
Shannon in the local library.
73 Mike

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

End of Packet-Radio Digest
******************************
Date: Sat, 15 Dec 90 04:30:04 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #220
To: packet-radio


Packet-Radio Digest         Sat, 15 Dec 90       Volume 90 : Issue 220

Today's Topics:
                   Gateway

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

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

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

Date: Fri, 14 Dec 90 12:43:14 ARG
From: [e-mail] ("Galanternik Adolfo <[e-mail]>")
Subject: Gateway
To: atina!ucsd.edu![e-mail]

I'd like to know the existence a gateway between packet-radio and Internet.
Adolfo. LU8EGI
===============================================================================
      Departamento de Quimica Clinica - Facultad de Farmacia y Bioquimica
        Universidad de Buenos Aires - ARGENTINA
             Postmaster: Adolfo Galanternik

UUCP    : ...uunet!atina!opsarg!dacfyb!adolfo    Phone: [phone]
Internet: [e-mail]               FAX:   [phone]
Bitnet  : [e-mail]  Packet: [e-mail]

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

End of Packet-Radio Digest
******************************
Date: Mon, 17 Dec 90 04:30:04 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #221
To: packet-radio


Packet-Radio Digest         Mon, 17 Dec 90       Volume 90 : Issue 221

Today's Topics:
     Anybody using integrated microprocessor & serial I/O chips?
       Error correction on corrupted received packets (3 msgs)
               Full Duplex Kiss on TNC1
         HOW DOES ONE GET STARTED WITH AMPR ?
               ICOM R1 for sale
           KAM LED's in KISS MODE (3 msgs)
          netrom routing and multiport nodes
              scc initialization
             Source for HARN, PC-100, NOS
         Where can I get Mac version of NOS? (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: 7 Dec 90 17:36:07 GMT
From: hpda!hpcuha!aspen!hpcc05!col![e-mail]  (Bdale Garbee)
Subject: Anybody using integrated microprocessor & serial I/O chips?
To: [e-mail]

>Has anyone done anything with the integrated microprocessor and serial I/O chips
>(like the 68302:  68k core + ISDN style serial I/O, or the Z80181:  Z180 core + 1
>SCC-style channel)?
>
>These chips (especially the '302) look like a great way to build small, cheap,
>low-power packet-radio gadgets.

The fine folks at Grace Communications have built a very nice 68302-based
packet switch board that blows everything else in the amateur market away.
Contact them for more info...

Work Address:   Grace Communications
        623 Palace Street
        Aurora, IL  60506
Work Phone:     [phone]

73 - Bdale, N3EUA

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

Date: 14 Dec 90 21:17:43 GMT
From: hpl-opus!hpnmdla![e-mail]  (Alan Bloom)
Subject: Error correction on corrupted received packets
To: [e-mail]

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

>[e-mail] (Alan Bloom) writes:
>>I would be happy with something much simpler.  Why can't I set my TNC to
>>monitor a channel and display every packet, whether the CRC checks or not?
>>In other words, go ahead and print the corrupted packets.  You would still
>>be able to make out part of the message.  (Wouldn't you?)

>YOU might be able to decipher it, but if the TNC can't, it can't
>acknowledge the packet and the sender will resend it anyway, so
>why use packet if all you want is the poor reliability of rtty?

>But if you want to, just turn PASSALL on.  Most TNCs will cheerfully
>deliver garbage if you ask them.

My TNC (KPC-2) doesn't have PASSALL.  Do all TNC-2 clones have this?
What I want to do is be in monitor mode (not connected to anyone) and
see what is going on on the channel.

AL N1AL

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

Date: 14 Dec 90 20:43:00 GMT
From: hpcc05!col![e-mail]  (Bdale Garbee)
Subject: Error correction on corrupted received packets
To: [e-mail]

>I would be happy with something much simpler.  Why can't I set my TNC to
>monitor a channel and display every packet, whether the CRC checks or not?
>In other words, go ahead and print the corrupted packets.  You would still
>be able to make out part of the message.  (Wouldn't you?)
>
>This would be like the old days of Baudot RTTY where a static crash might
>take out a word or two, but you could still understand the gist of the
>message.

This would work to the extent that you want it to, but it is counter to the
overall philosophy of packet radio, specifically the concept of reliable
delivery.

If your definition of packet radio is interactively qso'ing or "reading the
mail", then this may be a good thing to be able to do.  If your definition
of packet radio is more like mine, doing lots of sophisticated computer to
computer communications in support of qualitatively different applications
than keyboard to keyboard or keyboard to bbs operation... then you really do
want to drop packets with errors as soon as the error is detected, to
minimize the impact on system resources of processing trashed packets.

So, once again, the answer is both yes and no.

Bdale

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

Date: 14 Dec 90 21:34:22 GMT
From: envy![e-mail]  (Phil R. Karn)
Subject: Error correction on corrupted received packets
To: [e-mail]

In article <[e-mail]>, [e-mail] (Brian Kantor) writes:
|> But if you want to, just turn PASSALL on.  Most TNCs will cheerfully
|> deliver garbage if you ask them.

Yeah, and you won't believe just how MUCH garbage they'll deliver
until you actually try this. Especially on HF, carrier detect circuits
don't work very well, so most stations end up feeding continuous raw
noise from the receiver into their HDLC chips between each packet.
Most of this stuff is normally filtered out by the CRC check.  But a
surprising number of small garbage frames (e.g., < 3 bytes) will make
it past the CRC check. That's because the CRC is only 16 bits wide, so
any random pattern of bits has a 1/65536 chance of being accepted as a
valid frame. Even at 1200 baud, it doesn't take long for this to
happen.

However, these garbage packets are invariably discarded because they
don't have your callsign at the beginning.  Consider that the chances
of your callsign appearing by chance in the destination field of a
purely random packet are something like 1 in 2^56. (There are 7 bytes
or 56 bits in an AX.25 address field.)  This is a MUCH smaller number
than 1 in 2^16. It's equal to the chance of guessing a 56-bit DES
encryption key - i.e., small enough to not worry about.

Nevertheless, turning off your CRC check in the hopes of getting only
slightly errored frames is not likely to work all that well. Most
real-world errors are bursty (e.g., caused by QRM or static crashes)
so quite a few bits are wiped out. This type of interference almost
always screws up the HDLC bit-stuffing logic, sometimes aborting the
frame entirely (it takes only 7 or more contiguous 1s to cause a frame
abort).

The right way to do bit-level FEC is to switch to an entirely
different frame format. The frame should start with a relatively long,
pseudo-random "synch vector" instead of the short HDLC "flag" (0x7e).
This vector should be long enough that the chances of it occurring in
random noise (or user data) is vanishingly small. It should also be
chosen such that it can be reliably recognized even when a few of the
bits are corrupted in transit without appreciably increasing the
chances of a false alarm. Because the synch vector is long, there is
no need for bit-stuffing.

The receipt of a synch vector initializes a forward error correction
decoder, either of the convolutional (e.g., Viterbi) or block (e.g.,
Reed-Solomon) type. Bits are clocked from the channel into the decoder,
and some smaller number of corrected bits emerge some time later. Burst
errors can be handled by interleaving the encoded bits on the channel,
e.g., turning a burst of adjacent errors into a more widely distributed
pattern of single-bit errors that can be more easily corrected by the
decoder.

Many real-world coding schemes make use of both a block and a
convolutional code in series. The data is first block coded and then
convolutionally coded. The receiver uncodes in reverse order. This
highly effective scheme is especially popular in deep space
communications (e.g., Voyager).

The 400 bps telemetry on Oscar-13 uses a framing scheme similar to
what I just described. The synch vector is 32 bits long. Convolutional
coding is available, but it has never been used; normally the links
are good enough that it isn't required. In my opinion, the main
drawbacks to the Oscar-13 scheme as currently implemented are a) the
synch vector isn't long enough, and b) the blocks are of fixed length
(512 bytes). These could be readily fixed in any new framing scheme
designed specifically for use with bit-level FEC.

Phil

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

Date: 16 Dec 90 01:47:27 GMT
From: psuvm![e-mail]  (James C Mankin)
Subject: Full Duplex Kiss on TNC1
To: [e-mail]

I would like to use my tnc1 in kiss mode with the microsats but
have been having trouble getting full duplex mode to work properly.
All the tnc1 kiss roms I have been able to find seem to just key the
transmitter and leave it forever keyed when given the full duplex
command ( 5 1 ), rather than key it for each packet.  Has anyone
else had this problem (and found a solution)??  73's Jim KB3KJ

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

Date: 15 Dec 90 02:24:20 GMT
From: munnari.oz.au!darwin.ntu.edu.au![e-mail]
Subject: HOW DOES ONE GET STARTED WITH AMPR ?
To: [e-mail]

We know nothing about Packet Radio at all, but we are connected to the IP. We
think that Packet Radion could be a real boon to our remote learning programs
as cooms lines in our part of the world are rare and expensive.

The problem is how do we start ??

Would someone mail us directly with some suggestions on books, publications,
FTP sites etc that could give us a start.

We have done some work with using KA9Q etc as a router between AppleTalk and
ethernet so we are aware of and sort of comfortable with TCP/IP but the packet
radio side is all new.

In addition I believe that there is a mailing list called

    [e-mail]


anyone advise me on how to subscibe.

All help and suggestions gratefully received.



Tery Anstey
Computer Services
Northern Territory University
Darwin
Australia

INTERNET: [e-mail]

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

Date: 14 Dec 90 21:19:15 GMT
From: hpl-opus!hpnmdla![e-mail]  (Alan Bloom)
Subject: ICOM R1 for sale
To: [e-mail]

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

>This is the amazing, tiny, hand-held 150khz to over 1GHZ continous
etc...

This should be in rec.ham-radio.swap

AL N1AL

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

Date: 14 Dec 90 17:55:36 GMT
From: crash!ipars![e-mail]  (Scott O'Connell)
Subject: KAM LED's in KISS MODE
To: [e-mail]

I've recently started using KA9Q's NET software.  My KAM (3.01 firmware)
is now in KISS mode and the LED's don't have the same meaning.

About all I can positively conclude is that XMIT remains XMIT and RCV
remains RCV/DCD.  CON and STA blink during a RCV, so I assume they're
maybe protocol identifiers.

I can't find the answer in the manuals and the Kantronics tech support
line is busy, busy, busy.

Any definitive answers?

In my last post I was looking for KA9Q's software for SCO Xenix.  I never
found a Xenix specific, but was able to compile the 890421.1a version of
NET with little change.  This was a great accomplishment for a non C
programmer like myself. (toot toot) I have also established a SLIP link
to my MS-DOS PC.  It works, but I still have a *lot* to learn.

Could someone advise me of possible problems I will encounter with NET?

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

Date: 15 Dec 90 01:40:28 GMT
From: envy![e-mail]  (Phil R. Karn)
Subject: KAM LED's in KISS MODE
To: [e-mail]

In article <[e-mail]>, [e-mail] (Scott O'Connell) asks
about the CON and STA lights when operating his KAM in KISS mode.

The general convention for these lights (originally established by
K3MC in his KISS implementation for the TNC-2) is that STA flashes
whenever the TNC receives a frame from the host for transmission, and
CON flashes whenever the TNC correctly receives a frame from the
radio.

These two lights are under software control, so it's possible that
Kantronics has implemented them differently. However, from your
description it sounds like they followed the original convention.

Phil

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

Date: 16 Dec 90 01:45:28 GMT
From: usenet.ins.cwru.edu!ncoast![e-mail]  (Brandon S. Allbery KB8JRR)
Subject: KAM LED's in KISS MODE
To: [e-mail]

As quoted from <[e-mail]> by [e-mail] (Scott O'Connell):
+---------------
| In my last post I was looking for KA9Q's software for SCO Xenix.  I never
| found a Xenix specific, but was able to compile the 890421.1a version of
| NET with little change.  This was a great accomplishment for a non C
| programmer like myself. (toot toot) I have also established a SLIP link
| to my MS-DOS PC.  It works, but I still have a *lot* to learn.
|
| Could someone advise me of possible problems I will encounter with NET?
+---------------

Locally, we run G1EMM with the works --- RIP, RSPF, and soon NNTP.  The old
NET software won't understand RIP or RSPF, and won't be able to do anything
with NNTP.

I am planning to write a packet TCP/IP package for UNIX/XENIX when I get a
multiuser box to replace this lobotomized PC I'm using now.  It will be
*loosely* based on G1EMM, but will be a rewrite to use UNIX features when
available.  I will probably include the ability to use native TCP/IP, which
will require kernel-level drivers; since I'm thinking in terms of pushable
Streams drivers for KISS, AX.25, and NET/ROM anyway, this isn't a problem.
I don't suggest asking me any sooner than a year from now, though, the way my
free time has been going.  :-(

++Brandon
--
Me: Brandon S. Allbery                      VHF/UHF: KB8JRR on 220, 2m, 440
Internet: [e-mail]                Packet: KB8JRR @ WA8BXN
America OnLine: KB8JRR                      AMPR: KB8JRR.AmPR.ORG [44.70.4.88]
uunet!usenet.ins.cwru.edu!ncoast!allbery    Delphi: ALLBERY

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

Date: 15 Dec 90 21:18:12 GMT
From: [e-mail]  (Brian Kantor)
Subject: netrom routing and multiport nodes
To: [e-mail]

Whilst trying to clean up the incredible mess/mesh that the SoCal
net/rom network is the other night, I ran into a problem that hadn't
occured to me before.

There are several nodes on the network with multiple ports - ie, a
G8BPQ switch with radios on 145.01 and 223.42.  Both of those ports are
currently assigned the same callsign-ssid and nodename.

There are also several other nodes around the area that are on those
frequencies, but they each have different call-ssid and nodenames.

The confusion comes when trying to assign quality values to the various
paths.  It's not possible to tell node A that XXX-1 on 145.01 is a
different beast than XXX-1 on 223.42, and the same for node B, yet
because both node A and node B can also talk to each other over another
link, they both think they have prime quality RF routes to XXX-1,
although because the 223.42 channel is backbone, we want to direct all
the traffic to there rather than to 145.01.  I can't lock out XXX-1 on
node A on 145.01, because that marks the route bad even through node B.
Not only that, but the actual case is a FIVE-PORT bbs here in town
that's on just about every packet channel there is, or so it seems.
Routes to it just keep swapping around as the nodes broadcasts happen,
and nobody seems to know what talks to where anymore.

ARRRGGHH!  It's pretty clear to me that it is MANDATORY that multiport
nodes that don't exist in isolation MUST have different nodenames and
call-ssid on each port, or the poor little net/rom routing algorithm
gets incredibly confused.

Am *I* confused, is this obvious to even the most casual observer, or
what?  Comments, please!

    - Brian

(And no smart-guy remarks about net/rom.  It's not MY choice.)

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

Date: 16 Dec 90 00:17:49 GMT
From: wuarchive!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!pitt!cs.pitt.edu![e-mail]
Subject: scc initialization
To: [e-mail]

This is to the person looking for help on initializing an 8530
board with the scc driver - my mail to you bounced, so I am
forced to post this:


If A0 is tied to D/C and A1 is tied to A/B then:

  Channel A Control = 302
  Channel A Data = 303
  Channel B Control = 300
  Channel B Data = 301

The initialization line should be:

attach scc 1 init 300 16 2 0 1 3 p7158913
scc 0 ax25 lta 512 1200 256

You might want to try mtu of 576 instead of 512.

Let me know if this works for you. There is a documentation file
for the driver that I can send if you don't have it.


  Ken Mitchum KY3B
  [e-mail]

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

Date: 14 Dec 90 02:56:39 GMT
From: VAX1.CC.UAKRON.EDU!mcs.kent.edu!usenet.ins.cwru.edu!ncoast![e-mail]  (Brandon S. Allbery KB8JRR)
Subject: Source for HARN, PC-100, NOS
To: [e-mail]

As quoted from <[e-mail]> by [e-mail] (Bdale Garbee):
+---------------
| >Also, where can a non-ftp site obtain the lastest source for
| >NOS?  Anything available via uucp?  What happened to uucp site
+---------------

N8EMR in Columbus runs XBBS and I believe has anonymous uucp.  Unfortunately,
I've lost the phone numbers (again --- aargh!!!).  If I can get caught up the
rest of the way on my life, I'll try to arrange for archives on ncoast,
possibly jointly maintained with N8HSP Terry Bell.

73,
++Brandon
--
Me: Brandon S. Allbery                      VHF/UHF: KB8JRR on 220, 2m, 440
Internet: [e-mail]                Packet: KB8JRR @ WA8BXN
America OnLine: KB8JRR                      AMPR: KB8JRR.AmPR.ORG [44.70.4.88]
uunet!usenet.ins.cwru.edu!ncoast!allbery    Delphi: ALLBERY

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

Date: 14 Dec 90 18:03:36 GMT
From: csus.edu!wuarchive!cs.utexas.edu!oakhill!nddsun1![e-mail]  (Mark Monninger)
Subject: Where can I get Mac version of NOS?
To: [e-mail]

I understand there is a Macintosh version of the KA9Q NOS package.

If that it true, where can I get a copy, preferably via anonymous FTP?

All assistance will be appreciated.

Many thanks.

Mark    KG7JL

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

Date: 14 Dec 90 20:04:38 GMT
From: [e-mail]  (Patty Winter)
Subject: Where can I get Mac version of NOS?
To: [e-mail]

In article <[e-mail]> [e-mail] (Mark Monninger) writes:
>I understand there is a Macintosh version of the KA9Q NOS package.
>
>If that it true, where can I get a copy, preferably via anonymous FTP?

No, there's no Mac version of NOS. But if you want NET, it's available
in the /pub/ham-radio directory of apple.com. (And probably in a couple
of other places, such as thumper.bellcore.com and platypus.uofs.edu.)


Patty

p.s. The /pub/ka9q/incoming directory on thumper also now has a
fascinating GIF file called "philmick.gif" that folks may want
to check out. In answer to your next question, Phil is the one
on the left. :-)
--
*****************************************************************************
Patty Winter N6BIS                        INTERNET: [e-mail]
AMPR.ORG: [44.4.0.44]                     UUCP: {decwrl,nsc,sun}!apple!winter
*****************************************************************************

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

End of Packet-Radio Digest
******************************
Date: Tue, 18 Dec 90 04:30:04 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #222
To: packet-radio


Packet-Radio Digest         Tue, 18 Dec 90       Volume 90 : Issue 222

Today's Topics:
                 KAM
            KAM LED's in KISS MODE
      Mickey Mouse (was Re: Where can I get Mac version of NOS?)
                ROSE (2 msgs)
               router hardware question
            test.  don't read this
         Where can I get Mac version of NOS?

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

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

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

Date: Mon, 17 Dec 90 10:55:00 EST
From: [e-mail] (ase)
Subject: KAM
To: [e-mail]

Has anyone had a problem with Kantronics version 3.0 in KISS mode?
The symptoms I see on my KAM are intermittent. The symptoms are
that the STA light stays lit, and may be accompanied by the mark/
space display being dark (as if the hf rig had been xmitting).
Although this may be subtle, Phil Karns book says to run at 4800 baud
and I am running 9600 baud. Could this be a flow control issue with
symptoms that point to data loss between the computer and TNC? Any
help that someone could shed would be appreciated.


-Jay-  -KA1SNA-

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

Date: 17 Dec 90 18:55:00 GMT
From: swrinde!zaphod.mps.ohio-state.edu!sdd.hp.com!apollo![e-mail]  (John Hays)
Subject: KAM LED's in KISS MODE
To: [e-mail]

The kh113013 version (G1EMM) of KA9Q has support for the KAM/KPC-4 multi-port
KISS.  I have used it with my KAM and run NOS with ports on ETHERNET, HF, and
VHF simultaneously.  If you have a KAM, I think Kelvin's code is the way to go.

Anyone interested in an HF IP testbed network  (I nominate 18 Mhz. band)

John
KD7UW [44.40.1.3]

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

Date: 17 Dec 90 22:56:57 GMT
From: [e-mail]  (Patty Winter)
Subject: Mickey Mouse (was Re: Where can I get Mac version of NOS?)
To: [e-mail]

In article <[e-mail]> [e-mail] (Bill Gunshannon) writes:
>In article <[e-mail]>, [e-mail] (Patty Winter) writes:
>> fascinating GIF file called "philmick.gif" that folks may want
>> to check out. In answer to your next question, Phil is the one
>> on the left. :-)
>
>I recognized him.  But who was the one on the right?? And does he know CW??


Well, he never spoke, so I presume he prefers key and keyboard modes
if he's licensed. Perhaps he's a packeteer as well as a mouseketeer. :-)

Just to throw a little bit of actual informational content into this
discussion, I will mention that the Disneyland hams run a 2-meter repeater
on 146.94 (-600 input). Evidently the receiver is on the Matterhorn and
the transmitter is in the Small World building. I didn't find out about
this until after the last time I was down there, so I don't know any
more details.


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

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

Date: 17 Dec 90 22:12:18 GMT
From: pilchuck!ssc![e-mail]  (Tad Cook)
Subject: ROSE
To: [e-mail]

Does anyone have a file that they can send me which describes
what a ROSE switch it?


Tad Cook
Seattle, WA
Packet: KT7H @ N7HFZ.WA.USA.NA
Phone: [phone]
MCI Mail: 3288544
Telex: 6503288544 MCI UW
USENET:...uw-beaver!sumax!amc-gw!ssc!tad
or, [e-mail]

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

Date: 17 Dec 90 22:16:10 GMT
From: pilchuck!ssc![e-mail]  (Tad Cook)
Subject: ROSE
To: [e-mail]

In article <[e-mail]>, [e-mail] (Tad Cook) writes:
>
> Does anyone have a file that they can send me which describes
> what a ROSE switch it?
             ^^OOPS!  Should say "IS".




Tad Cook
Seattle, WA
Packet: KT7H @ N7HFZ.WA.USA.NA
Phone: [phone]
MCI Mail: 3288544
Telex: 6503288544 MCI UW
USENET:...uw-beaver!sumax!amc-gw!ssc!tad
or, [e-mail]

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

Date: Mon, 17 Dec 90 10:29:43 -0800
From: brian (Brian Kantor)
Subject: router hardware question
To: tcp-group

I'm in the process of building a router for the local network.  It is
PC based, and the question to be solved immediately is one of I/O
bandwidth.

(BTW, the software involved will probably be G8BPQ front-ending NOS as
a combined netrom and IP router.  This works, even though it's rather
baroque to set up.)

We have two 9600 bps ports, one 4800 bps port, and one 1200 bps port.

Right now the choice is between using two DRSI PCPA cards or using four
KISS TNCs on async ports (with 16550 uarts).  The DRSI cards are the
lower cost solution, but I'm a bit concerned about the interrupt
service required eating all the cpu and i/o bandwidth of the PClone.

Has anyone done any comparisons or can speak to the limitations of the
two schemes, or suggest alternative solutions?
    - Brian

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

Date: 17 Dec 90 22:14:00 GMT
From: pilchuck!ssc![e-mail]  (Tad Cook)
Subject: test.  don't read this
To: [e-mail]

test

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

Date: 17 Dec 90 20:34:41 GMT
From: sdd.hp.com!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!netnews.upenn.edu!platypus![e-mail]  (Bill Gunshannon)
Subject: Where can I get Mac version of NOS?
To: [e-mail]

In article <[e-mail]>, [e-mail] (Patty Winter) writes:
> fascinating GIF file called "philmick.gif" that folks may want
> to check out. In answer to your next question, Phil is the one
> on the left. :-)

I recognized him.  But who was the one on the right?? And does he know CW??


bill    KB3YV

--


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


--

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

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

End of Packet-Radio Digest
******************************
Date: Wed, 19 Dec 90 04:30:03 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #223
To: packet-radio


Packet-Radio Digest         Wed, 19 Dec 90       Volume 90 : Issue 223

Today's Topics:
        Error correction on corrupted received packets

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 90 13:35:58 GMT
From: usc!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!netnews.upenn.edu!platypus![e-mail]  (Bill Gunshannon)
Subject: Error correction on corrupted received packets
To: [e-mail]

In article <[e-mail]>, [e-mail] (Alan Bloom) writes:
>
> My TNC (KPC-2) doesn't have PASSALL.  Do all TNC-2 clones have this?

My KPC-2 has PASSALL.  I can't imagine why yours wouldn't.
Of course, I also can't imagine why you reall want it.
If you set all the MONITOR commands to ON, you will see everything
except the damaged packetsd which would display as garbage anyway.
But then again, I can't imagine why you want to.  It's just as
thrilling as "reading the mail" on 75 meteres.

bill    KB3YV


--

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

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

End of Packet-Radio Digest
******************************
Date: Thu, 20 Dec 90 04:30:03 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #224
To: packet-radio


Packet-Radio Digest         Thu, 20 Dec 90       Volume 90 : Issue 224

Today's Topics:
          Amateur spread-spectrum projects? (6 msgs)
          Current status of 56kbps projects?
           High speed point to point Backbones ...
                 KAM
               PK-232 Memory poke/peek

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

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

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

Date: 19 Dec 90 15:19:00 GMT
From: sdd.hp.com!news.cs.indiana.edu!msi.umn.edu!cs.umn.edu!uc!nachos.SSESCO.com!SSESCO.com![e-mail]  (Chris Elmquist)
Subject: Amateur spread-spectrum projects?
To: [e-mail]

As long as I've got everyone's attention....

What's going on with amateur spread-spectrum data transmission?

I've seen these new wireless LAN products from places like LAWN
and Motorola...

Is there any activity in this field for amateur use?  Has anyone
looked into converting a LAWN unit for 902 MHz?  (Maybe it already
works there...)  Does it use the right kind of spreading sequence for
amateur use?

I've seen several articles in QST and QEX about the subject but
it didn't seem to me like the whole system was completed.  So,
I guess I'm checking here to see what progress has been made
since those articles.

Thanks.

Chris

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

Date: 19 Dec 90 18:27:21 GMT
From: agate!shelby![e-mail]  (paulf)
Subject: Amateur spread-spectrum projects?
To: [e-mail]

I've had some interest for a while now (but no time, ugh) in developing
a rate 1/10 system for 75 baud RTTY.  Now, before you gag, realize that
such a system will fit quite easily into SSB bandwidths, and could be
done with fairly cheap equipment (bell 202 modems, even).  The resulting
10db coding gain would do worlds of wonder for RTTY.  Of course, it would
have to be developed at VHF initially, but the real utility would be
on HF...

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

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

Date: 19 Dec 90 20:49:39 GMT
From: agate!darkstar!ucscc.UCSC.EDU![e-mail]  (99700000)
Subject: Amateur spread-spectrum projects?
To: [e-mail]

In article <[e-mail]> [e-mail] (paulf) writes:
>I've had some interest for a while now (but no time, ugh) in developing
>a rate 1/10 system for 75 baud RTTY.  Now, before you gag, realize that
>such a system will fit quite easily into SSB bandwidths, and could be
>done with fairly cheap equipment (bell 202 modems, even).  The resulting
>10db coding gain would do worlds of wonder for RTTY.  Of course, it would
>have to be developed at VHF initially, but the real utility would be
>on HF...
Yes, but... I wonder if we couldn't get more gain easier by other means.
For one thing, Bell 202 modems are optimized for wire lines, and we're
talking about radio.  For another thing, start/stop RTTY loses a lot
from its asynchronous nature.  Back when we used mechanical hardware
a mutilated stop pulse that failed to latch up the receive clutch at
the right time was good for several character errors in a row. So
the character error rate was something like (foggy memory) 17db worse
than you would expect from a given bit error rate.  I guess modern
UARTS are a lot more forgiving of lost stop pulses; but we're still
using simple envelope detection and sampling.

Years ago I started playing with compatible synchronous transmission:
sending 7.0 unit code at constant rate, with a fill character (ltrs
or figs) when there was nothing available from the keyboard.  I was
too lazy, and my collaborator was too busy, for us to ever get a
real synchronous receiver going that would lock on to the signals.
Meanwhile some other folks discovered that the constant stream of
characters was helpful even in simpler detection schemes (e.g.
slideback detectors) so other people started using 'diddle' in
their transmissions.  But I'd still like to see how a receiver
would perform if it could integrate all the energy in a pulse.

I wonder how spread spectrum performs in the presence of multipath
at HF?
[e-mail]
[e-mail]

"Any clod can have the facts, but having opinions is an Art."
    Charles McCabe, San Francisco Chronicle

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

Date: 19 Dec 90 23:06:51 GMT
From: [e-mail]  (Kok Chen)
Subject: Amateur spread-spectrum projects?
To: [e-mail]

[e-mail] (99700000) writes:

>Yes, but... I wonder if we couldn't get more gain easier by other means.
>For one thing, Bell 202 modems are optimized for wire lines, and we're
>talking about radio.


How many people have also stumble on this weird Russian book
on HF modems?  It's been a decade or two now since I came across
it, but not too long ago saw it at a local tech bookstore (Computer
Literacy - I call it Computer Bankruptcy since I tend to spend too
much there each time I pass through their portals).  The book is
only maybe 1/4" thick, soft cover, horrible paper,..., but VERY
interesting reading.

Apparently, in addition to the usual tricks played with coding
for fading channels and all that non-BSC stuff, it would periodically
send a prearranged "perfect" impulse as a frame sync and the receiving
end would recover and store away the impulse response of this "perfect"
frame-sync.  This impulse response is then used to perform a deconvolution
of the information-carrying waveforms that follows.  With this, they
take care of dispersive channels.

All circuits given were with valves and delay-lines, by the way.  This
was done way before DSP became real, I am sure.

Any work in this area among Hams?

73,

Kok Chen, AA6TY                         [e-mail]
Apple Computer, Inc.

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

Date: 19 Dec 90 23:21:04 GMT
From: usc!zaphod.mps.ohio-state.edu!maverick.ksu.ksu.edu!ux1.cso.uiuc.edu![e-mail]  (Phil Howard KA9WGN)
Subject: Amateur spread-spectrum projects?
To: [e-mail]

With regard to amateur spread spectrum systems, does anyone have any
technical information on or specific references for:

1.  Techniques to syncronize spread spectrum sequencers.

2.  Techniques to use spread spectrum without any syncronization.

This is for the direction of designing spread spectrum systems, as an
amateur, rather than adapting existing systems, such as LAWN, for amateur
use.  However this does not mean that I believe such things are not worth
doing.  I think it would be very interesting because they could potentially
be a cheaper way of doing things.  I just am also interested in trying to
push the boundary of innovation, as well.  Gotta be informed to even start.

Every article I have seen in amateur publications on spread spectrum tells
the basic fundamentals, but doesn't really cover all that needs to be covered
in the matter, such as how things are syncronized or made asyncronous.

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

Date: 20 Dec 90 00:32:47 GMT
From: agate!shelby![e-mail]  (paulf)
Subject: Amateur spread-spectrum projects?
To: [e-mail]

In article <[e-mail]> [e-mail] (Jim Haynes) writes:
>Yes, but... I wonder if we couldn't get more gain easier by other means.
>For one thing, Bell 202 modems are optimized for wire lines, and we're
>talking about radio.

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

Date: 19 Dec 90 15:11:56 GMT
From: usc!zaphod.mps.ohio-state.edu!mips!news.cs.indiana.edu!msi.umn.edu!cs.umn.edu!uc!nachos.SSESCO.com!SSESCO.com![e-mail]  (Chris Elmquist)
Subject: Current status of 56kbps projects?
To: [e-mail]

I've been able to spark some interest in a couple guys here...for
playing with 56kbps packet.  I'm familiar with the WA4DSY modem
(although I don't know how to get one) but am interested in what
kinds of transverters people are using with this modem.  Do any
28MHz to 1.2GHz transverters exist?  or do we have to make an
intermediate stop at 2m?  This project would also be an attempt
to get some action on the microwave bands around here, so I'd
like to get them running on 1.2GHz or higher.

Are people running these full-duplex on two bands?  How about
full duplex on one band?

Is it best to use something like the DRSI card in the PC or
has anyone connected the 'DSY to an outboard TNC?

Any tips, clues, cautions would be appreciated.

Thanks and 73, Chris

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

Date: 18 Dec 90 14:46:00 GMT
From: munnari.oz.au!yoyo.aarnet.edu.au!sirius.ucs.adelaide.edu.au!levels![e-mail]
Subject: High speed point to point Backbones ...
To: [e-mail]

We are looking at the possibility of installing some high speed trunks for
our network backbone, and the concept of using mod'd ethernet type cards on
shf has been raised. There is talk that some people here in vk use similar
systems, but information seems to be fairly scant.
One of the main concerns is whether it is possible to plug a new ethernet
address prom into the card with the callsign burnt in rather than the
standard ethernet address for station id purposes. We can see no reason why
progression to higher speeds cant be relatively painless if a band is selected
where it wont worry people ...
If anyone has any experience in this area, some pointers would be greatly
appreciated.
73's .... Rob VK5XXX/ZEU
--
Rob Mayfield    -  ASC Network Support, VK5XXX/ZEU, 44.136.171.1/44.136.171.2
Internet/AARNet -  [e-mail]             [AMPRIP VK5 Co-ordinator]
Applelink       -  AUST0177
AMPR            -  VK5XXX@VK5WI.#SA.AUS.OC     or     VK5ZEU@VK5WI.#SA.AUS.OC
OZPost          -  Post Office Box 46,  Henley Beach,  South Australia,  5022
Voice or Pix    -  Home : [phone]  Work : [phone]/7001 Voic/Fax
One thing is for sure; the sheep is not a creature of the air       [- MPFS.]

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

Date: 19 Dec 90 08:03:35 GMT
From: crash!ipars![e-mail]  (Scott O'Connell)
Subject: KAM
To: [e-mail]

In article <[e-mail].> [e-mail] (ase) writes:
>
>Has anyone had a problem with Kantronics version 3.0 in KISS mode?

I have 3.01 firmware and haven't seen any problems.  I've been running
mine in KISS mode for about 3 weeks.  I'm always use caution when running
a xxx.0 release.
      ^
>The symptoms I see on my KAM are intermittent. The symptoms are
>that the STA light stays lit, and may be accompanied by the mark/
>space display being dark (as if the hf rig had been xmitting).

I've not used mine on HF since I changed to KISS mode.

>Although this may be subtle, Phil Karns book says to run at 4800 baud
>and I am running 9600 baud. Could this be a flow control issue with
>symptoms that point to data loss between the computer and TNC? Any
>help that someone could shed would be appreciated.

I've been running mine at 9600 since before using KISS mode.  Currently
I'm using it on an SCO Xenix machine on a port that does no RTS/CTS
flow control.  I kinda expected problems but haven't had any....yet.

Call Kantronics at 913/842-4476.  I've *never* made it through to
technical support even after several attempts.  The lines to _technical
support_ are either busy or no answer.  Not even a receptionist.  They
say their hours are 9am-12 and 2pm-5 Central Time, M-F.

Good luck!

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

Date: 19 Dec 90 16:54:49 GMT
From: sbi!zeus!newt![e-mail]  (Jean-Louis Ecochard)
Subject: PK-232 Memory poke/peek
To: [e-mail]

 Does anyone has experience "programming" a PK-232 using
the Peek/poke and address functions ?
Did anyone dissaemble the Z80 ROM code ?
Are the Baud clock value tables in RAM or in ROM ?
I would like to change the baud rate at the baud or tenth
of baud level for weird RTTY and other FSK stuff.

Does anyone has modification information on the PK-232 ?
I heard about a RFI protection mod.


--
Jean-Louis Ecochard                 O
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~./_\.~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                 (__Y__)                 uunet!sbi!chi!jl

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

Date: Wed, 19 Dec 90 15:01:12 EST
From: uunet!bywater!acheron!orioneb!wardc
To: acheron!ucsd.edu!packet-radio

I am trying to run NOS to replace my current system (MSYS) and am having
trouble getting NOS to work with my setup. I am running 3 comm ports in
an MS-400 async card with the AA4RE modification to allow the 3 ports to\
share the same intrupt (IRQ2). Now, this card works with MSYS as it has
a built in interupt handler. It also works when you load MBBIOS (another
AA4RE product) which is a TSR interupt handler. Using MBBIOS and the
modifed card allows you to run the standard bbs programs RLI/MBL etc
on the shared port. It also worked with the old NET.EXE (before NOS).

Now, when I try to run NOS with this card and put the correct information
in the autoexec.net file, NOS talks to one of the ports but can't hear
anything. I can issue a connect command and you see the station trying
to answer (on the s meter) but NOS won't hear it. And, the other ports
don't work at all. With or without MBBIOS, this problem exists. When using
a standard comm port (1 or 2) NOS works fine.

Is anyone using NOS with the MS-400 card (or any other multi-port async
card with the diode modification that AA4RE came out with) with or without
MBBIOS out there, I am at my wits end (whatever that is...... grin..)

thanks!!


Ward Carpenter
N1CUI @ N1CUI-8
44.88.0.13
Rigdefield, CT

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

Date: (null)
From: (null)
>  For another thing, start/stop RTTY loses a lot
>from its asynchronous nature.  Back when we used mechanical hardware
>a mutilated stop pulse that failed to latch up the receive clutch at
>the right time was good for several character errors in a row. So
>the character error rate was something like (foggy memory) 17db worse
>than you would expect from a given bit error rate.  I guess modern
>UARTS are a lot more forgiving of lost stop pulses; but we're still
>using simple envelope detection and sampling.

What would be sort of idea would be perhaps to design a mod or add-on to
the TAPR TNCs (new code, new modem).  So we could play with the bits
a little.  Remember, half the goal is *cheap*.

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

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

End of Packet-Radio Digest
******************************
Date: Fri, 21 Dec 90 04:30:02 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #225
To: packet-radio


Packet-Radio Digest         Fri, 21 Dec 90       Volume 90 : Issue 225

Today's Topics:
           CommodorDIR/ALLe Software wanted
         Current status of 56kbps projects? (2 msgs)
       High speed point to point Backbones ... (5 msgs)
      Setting up multi-port NET/ROM or TheNet. (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: 20 Dec 90 17:44:19 GMT
From: uoft02.utoledo.edu![e-mail]
Subject: CommodorDIR/ALLe Software wanted
To: [e-mail]

I own a Commodore 128 and I am looking for software for the C64 or C128 that
will help me learn my code......I am trying to earn my first ticket....

Thanks in advance,

Tony

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

Date: 20 Dec 90 12:15:00 GMT
From: usc!wuarchive!emory!wa4mei!ke4zv![e-mail]  (Gary Coffman)
Subject: Current status of 56kbps projects?
To: [e-mail]

In article <[e-mail]> [e-mail] (Chris Elmquist) writes:
>I've been able to spark some interest in a couple guys here...for
>playing with 56kbps packet.  I'm familiar with the WA4DSY modem
>(although I don't know how to get one) but am interested in what
>kinds of transverters people are using with this modem.  Do any
>28MHz to 1.2GHz transverters exist?  or do we have to make an
>intermediate stop at 2m?  This project would also be an attempt
>to get some action on the microwave bands around here, so I'd
>like to get them running on 1.2GHz or higher.

Those of us in the GRAPES network are using Microwave Modules MMT432
transverters. The 220 version of this transverter has also been used as
has the Hamtronics XV4 and a receive converter. I have the SSB Electronics
902 and 1296 transverters and I am considering getting a Hamtronics XV2
to drive their 144 Mhz inputs.

>Are people running these full-duplex on two bands?  How about
>full duplex on one band?

We have heard reports of cross band work. Nothing on single band duplex.

>Is it best to use something like the DRSI card in the PC or
>has anyone connected the 'DSY to an outboard TNC?

All but two of us locally are using modified TNC2s to drive the modems.
The instructions and a special KISS chip come with the modem kit. We
had some initial problems with the DRSI cards, but they seem to be coming
along nicely now. There appear to be better cards coming along to drive
the modem. The Grace Packet Ten card seems to work well and we hear that
the group in Ottawa have a good card too. The Kantronics Data Engine should
work, but we aren't aware of anybody using it yet.

Email Doug Drye KD4NC at ...gatech!kd4nc!dug  for more info on the modem
kits.

Gary KE4ZV

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

Date: 20 Dec 90 19:58:01 GMT
From: van-bc!mdivax1![e-mail]
Subject: Current status of 56kbps projects?
To: [e-mail]

In article <[e-mail]> [e-mail] (Chris Elmquist) writes:
>I've been able to spark some interest in a couple guys here...for
>playing with 56kbps packet.  I'm familiar with the WA4DSY modem
>(although I don't know how to get one) but am interested in what
>kinds of transverters people are using with this modem.  Do any
>28MHz to 1.2GHz transverters exist?  or do we have to make an
>intermediate stop at 2m?  This project would also be an attempt
>to get some action on the microwave bands around here, so I'd
>like to get them running on 1.2GHz or higher.
>
>Are people running these full-duplex on two bands?  How about
>full duplex on one band?
>
>Is it best to use something like the DRSI card in the PC or
>has anyone connected the 'DSY to an outboard TNC?
>
>Any tips, clues, cautions would be appreciated.
>
>Thanks and 73, Chris

I can't answer about how others are using the modems, but I can say how
I have been using them, and where to get them. Let me start by bragging
about the 56K network in Georgia. It stretches from South of Atlanta up to
the Tennessee border, from almost to Alabama to past Athens. It runs on
the 430 band somewhere (don't remember the frequency), and is simplex. This
is a backbone used for hauling LOTS of data around between the LANs. There
is also a high-speed LAN in the Atlanta area with about 10 or so stations
on it. Sure is nice. Doing FTPs across the net is wonderful. Sure beats
the landline...

Now, the downside of this is the fact that I recently moved out to the
Seattle area where there is no high-speed activity (yet). There is, however,
8 - 10 inches of snow on the ground here at present (both points make me
wish I was still in Atlanta where the temp is about 40 degrees higher.).

For info on the modems, send email to [e-mail]. Doug will
respond with the info you request, although as busy as he is, it may take
a short time. Please do not send him mail over packet. We don't wish to
even come close to abusing the "commercial traffic ban" rule.

Jack Brindle WA4FIB/7

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

Date: 20 Dec 90 14:31:39 GMT
From: swrinde!zaphod.mps.ohio-state.edu!rpi!masscomp!ocpt!tsdiag![e-mail]  (Dave Tiller N2KAU)
Subject: High speed point to point Backbones ...
To: [e-mail]

In article <[e-mail]> [e-mail] writes:
-We are looking at the possibility of installing some high speed trunks for
-our network backbone, and the concept of using mod'd ethernet type cards on
-shf has been raised.
-One of the main concerns is whether it is possible to plug a new ethernet
-address prom into the card with the callsign burnt in rather than the
-standard ethernet address for station id purposes.

An excellent idea!  Most cards allow something variously called "promiscuous
mode", or "destination address insert mode" where you (in each packet sent to
the board) supply the source and destination addresses.  Another really neat
feature in the ability of some cards to define 'groups', whereby one packet
can be selectively received by multiple stations on a group basis.  You
could even impliment arp, since broadcast packets are legit over ethernet.
I'd love to see this happen - now I know what I'll use my 10GHz Gunneplexers
for!
--
David E. Tiller         [e-mail]  | Concurrent Computer Corp.
FAX:  [phone]      Ph: [phone] (w) | 2 Crescent Place, M/S 117
UUCP: ucbvax!rutgers!petsd!tsdiag!davet        | Oceanport NJ, 07757
ICBM: 40 16' 52" N      73 59' 00" W           | N2KAU @ NN2Z

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

Date: 20 Dec 90 17:06:16 GMT
From: swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!samsung!interlan.InterLan.COM!interlan.interlan.com![e-mail]  (Mike Yetsko)
Subject: High speed point to point Backbones ...
To: [e-mail]

I'm interested in following this lie also!!!

But first off, has anyone looked into the ramifications of pulling the
ethernet address ROMs and inserting callsigns?  The IEEE might get pretty
pissed!  Although, that means the first byte of the address field would
be restriced to an ASCII uppercase letter.

Perhaps a specific address block could be obtained from the IEEE for this
purpose, and a petition made to the FCC to allow COMPRESSED ID of the call
sign used, that way it would possibly fit into 4 bytes.  6 bits with a
possibility of 6 characters, that 36 bits compressed.  And that even leaves
up to 4 bits for a 1-of-16 designator for multiple transmitters on the
same call.  Of course, this would be an easy way to get onto the RF with
as few as possibly changes to the packet info.  Otherwise, a new protocol
stack needs to be come up with.

Mike Yetsko
N1DVJ

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

Date: 20 Dec 90 19:21:07 GMT
From: sdd.hp.com!zaphod.mps.ohio-state.edu!samsung!interlan.InterLan.COM!interlan.interlan.com![e-mail]  (Mike Yetsko)
Subject: High speed point to point Backbones ...
To: [e-mail]

Before the re-programming of ethernet addresses to reflect the HAM
callsign is considered, an algorithm for the implementation of that
number needs to be established.  I propose this start a discussion to
try to come up with a scheme NOW to figure out what to do.

The address is contained as a unique number of 6 bytes.  These numbers
are sold in 'blocks' by the IEEE, and while you don't 'legally' need
one, everyone in the game plays by the rules.  Also, the addresss needs
to contain the FCC licensed callsign of the transmitting station.  In 6
bytes, that can be tough.

The FCC approval may be minor, as if everybody does this, then it is
the format used, and as long as it is made public, no problem.  Perhaps
someone more familiar with the rules could comment.

The address 'block' number, if obtained from the IEEE, will probably be
2 digits.  Following that, will be be 4 bytes, or 32 bits.  If we need
to keep up to 4 bits available for a station sub-designator that leaves
28 bits.  Now, the question becomes how to compress a call sign to 28
bits, and handle the 'worst case' call of 2x3?

If a 1-byte header was usable, then there would be 40 bits left over.
The callsign could easily be compressed to 36 bits using straight 6 bit
reps of the characters and chaining them, or even to 31 bits by
compressing to 5 bits for letters, and 4 for the number, with a 2 bit
pointer as to where the number might be in position from the start.
With 31 bits in the address, that only leaves 1 bit for numerical
address selection of multiple transmitters if we are looking at a 32
bit limit.

The only other possibility is to use standard ethernet addresses, and
imbed the FCC callsign elsewhere in the packet, or at periodic times in
the data stream with a 'control' packet that would tie that ethernet
address to that callsign.

Of course, all caution could be thrown to the wind, and the callsign
just burnt in to the ROM in the clear as ASCII.  If these were just for
dedicated HAM use, then there is no big problem, but in that case, I
would suggest you NOT burn the ROM, but modify the driver to pick up
the HAM call and insert it that way.

HMMmm...  NI5210's with a packet driver using the KA9Q stuff, over a
microwave link........

Mike Yetsko
N1DVJ

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

Date: 20 Dec 90 20:42:25 GMT
From: mcsun!hp4nl!nikhefk![e-mail]  (Henk Peek)
Subject: High speed point to point Backbones ...
To: [e-mail]

In article <[e-mail]   [e-mail] writes:
>We are looking at the possibility of installing some high speed trunks for
>our network backbone, and the concept of using mod'd ethernet type cards on
>shf has been raised. There is talk that some people here in vk use similar
>systems, but information seems to be fairly scant.
The use of commercial network boards for a backborn the cheapest way to go.
See: Bdale at all in the 1 Mbit/sec gunplexer link in 73 and Hamradio. We
can use ethernet boards, but I think that a performance of 1 Mbit/sec is a better
balance between used rf bandwidth, rf power and network traffic.
You could find starlan or systek boards of old networks at very low prices.
I found a lot of starlan boards for $3 a board, but I haven't started
to construct the RF hardware.
>One of the main concerns is whether it is possible to plug a new ethernet
>address prom into the card with the callsign burnt in rather than the
>standard ethernet address for station id purposes. We can see no reason why
>progression to higher speeds cant be relatively painless if a band is selected
>where it wont worry people ...
I think that identification isn't a real problem. Include in the begin of the
data field the call of the source and destination station. You could also
send broadcast packets those are filed with a bit pattern of your call in morse.
When you do this in a maximum length ethernet packet of 1500 bytes on a 1 Mbit/sec
link, the morse speed is 500 chars/sec (6000 words/min). :-)

 73's .... Henk, PA0HZP

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

Date: 20 Dec 90 23:28:13 GMT
From: hpl-opus!hpnmdla![e-mail]  (Glenn Elmore)
Subject: High speed point to point Backbones ...
To: [e-mail]

When the 2 Mbps 10 GHz microwave link hardware was first built by n6rce
and myself, we  had hoped to be able to slow Ethernet cards down and use them
directly, as per n3eua's suggestion. It turned out that 10 Mbps and
a 20 MHz clock was frimly entrenched in the silicon. In addition, I
believe the propagation delays associated with the 1-2 kM (whatever it
is exactly) maximum DX specification (related to packet length and the
certainty that all users recognize a collision)  are similarly ingrained.
I think it might work over short distances and probably using the
10 GHz hardware with a few minor changes, but I think there may be
problems if you try to go further. Perhaps with only two hosts sharing
the "cable" the propagation delays and CD stuff can be tricked... I dunno.


Glenn Elmore -N6GN-

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

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

Date: 20 Dec 90 16:39:54 GMT
From: att!cbnewsj![e-mail]  (thomas.kenny)
Subject: Setting up multi-port NET/ROM or TheNet.
To: [e-mail]

I've been using NET/ROM or TheNet nodes as a user but would like to correspond
with somebody regarding how to setup a dual (or tri) port cross band digipeater.

I'm a bit new to this so I have alot of questions. If there is alot of
interest I'll summarize any responses I get from the net...

1 What's the differences between NET/ROM and TheNet from a user as well as
    network administrator point of view?

2 Do they have a buddy list or definable limit on number of users of the
    network?

3 How much does NET/ROM cost and where what's there address?

4 How and where do I get TheNet ROMS. Can I purchased them burned or do
    I have to roll my own EPROMS? Can I get documentation via anonymous
    FTP so I can learn about it?

5 Which is better? Which is used more often?

6 Do I interface the TNCs via the serial port? Can I still have a computer
    on the serial line to monitor activity?

I have other questions as well but these are the major ones I have at this
point. Thanks in advance for your reply. 73 DE KB2GLO.

--
Tom Kenny, KB2GLO
uucp:   att!lzatt!tek          internet: [e-mail]
packet: [e-mail]  ampr: [e-mail] [44.64.0.10]

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

Date: 20 Dec 90 19:57:07 GMT
From: [e-mail]  (Brian Kantor)
Subject: Setting up multi-port NET/ROM or TheNet.
To: [e-mail]

In reply to [e-mail] (thomas.kenny):

Net/rom(r) is a proprietary product of Software 2000 Inc and is
marketed in the USA through Amatech International.  It costs around $65
for one PROM with your desired callsign-ssid encrypted into it (not
user changeable), with additional PROMs ordered as part of the same
system being cheaper.  Depending on who you talk to and believe, TheNet
is variously a) a very similar product independently written, or b) a
result of reverse-engineering net/rom, or c) the result of software
theft of net/rom, or d) the result of a falling-out over an initial
work-together agreement, or e) none of the above.  I have no idea which
of these is the truth and I suspect that I will never know.  Judge for
yourself and act accordingly.  Archives of the various debates over
these matters are in the old info-hams and packet-radio mailing list
archives on UCSD.EDU and other places.

>1 What's the differences between NET/ROM and TheNet from a user as well as
>       network administrator point of view?

Almost no user difference; NR has an 'IDENT' command that lists or sets the
nodename; 'TN' has an INFO command that can return a string.  From the
administrator point of view, since you burn your own TN proms, you can
set the callsign yourself instead of having to buy a new prom.

>2 Do they have a buddy list or definable limit on number of users of the
>       network?

You can set limits and horizons and nodecounts, and tune a large number
of network operational parameters.

>3 How much does NET/ROM cost and where what's there address?

See above.

>4 How and where do I get TheNet ROMS. Can I purchased them burned or do
>       I have to roll my own EPROMS? Can I get documentation via anonymous
>       FTP so I can learn about it?

Source and images of TN are available by anonymous FTP from several
European sites.  Lots of people in the USA either believe it's a ripoff
or wish to avoid the controversy and so do not make it available.

>5 Which is better? Which is used more often?

I hear they're pretty much the same.  They interoperate ok (i.e., a
network that is a mixture of TN and NR works).

>6 Do I interface the TNCs via the serial port? Can I still have a computer
>       on the serial line to monitor activity?

There's no 'monitor' mode that I know of.  You can use it to connect to
places sorta like a TNC, but few people use it that way; most are set
up as dedicated networking nodes.  You can connect multiple nodes
back-to-back to form crossband networking clusters if you want, or
connect two of them with landlines or modems or satellites to form
wormholes to connect communities together over commercial circuits.

You may wish to investigate the use of KISS TNCs or DRSI cards and the
G8BPQ software; assuming you have a PC/XT class of machine to dedicate
to networking, it would probably be a better fit to what it sounds like
you want to do.
    - Brian

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

Date: Thu, 20 Dec 90 18:27:02 PST
From: uunet!m2xenix!puddle!f4.n494.z5.fidonet.org!RKWDP.PUKVM1
To: [e-mail]

Subject: ICOM 725 HF ALL MODE TRANCEIVER - MODULATION LOW

Hi fellow HAMS

I wonder if someone can help me/give me some more info.  Sorry to
ask a non-packet question here but I hope you will forgive me.

A month or so ago I bought myself a ICOM 725 HF T/CEIVER with the
AM/FM option included.  Everything is working 100% except the
modulation on SSB.  On FM and AM the modulationlevel is fine - I am
using the MIC GAIN in the 12 o'clock position (50%) - that is sufficient.
But on SSB I have to turn up the MIC GAIN 100% to get sufficient modulation.
Now I am used to my KENWOOD TS120S - very lively on modulation - never need
more than 50 % on MIC GAIN CONTROL.  I phoned the local supplier of
ICOM equipment (where I bought the rig) and he told me that
he knows of other HAMS who experienced the same problem (on SSB).  He said
that it is a characteristic of the ICOM 725 - you have to drive it hard
on SSB by using a amplified MIC.  To me that is not the answer.  Why
doesn't ICOM supply such a mic with te rig then?.   Somewhere
there must be a mod that can be done to get a bit of gain on the mic side.

Thanks for all the trouble - hope to here from you soon.

Best 73 and Merry Xtmas and Happy New year to all.

Dan Pretorius (ZS4VG)

My E-MAIL ADRESS:

RKWDP@[e-mail]
--
uucp: uunet!m2xenix!puddle!5!494!4!RKWDP.PUKVM1
Internet: [e-mail]

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

End of Packet-Radio Digest
******************************
Date: Sat, 22 Dec 90 04:30:04 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #226
To: packet-radio


Packet-Radio Digest         Sat, 22 Dec 90       Volume 90 : Issue 226

Today's Topics:
          Current status of 56kbps projects?
       High speed point to point Backbones ... (5 msgs)
                 KAM
           NOS and Shared Interruptson MS-400 Card
             Source for HARN, PC-100, NOS
             The PACCOMM TNC 220

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

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

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

Date: Fri, 21 Dec 90 14:26:02 EST
From: [e-mail] (Barry McLarnon DGBT/DIP)
Subject: Current status of 56kbps projects?
To: [e-mail]

>I've been able to spark some interest in a couple guys here...for
>playing with 56kbps packet.  I'm familiar with the WA4DSY modem
>(although I don't know how to get one) but am interested in what
>kinds of transverters people are using with this modem.  Do any
>28MHz to 1.2GHz transverters exist?  or do we have to make an
>intermediate stop at 2m?  This project would also be an attempt
>to get some action on the microwave bands around here, so I'd
>like to get them running on 1.2GHz or higher.

I doubt if any 28MHz/1.2GHz transverters exist, since such a beast would
only give you access to 2 MHz chunks of 1.2GHz (one per crystal).

>Are people running these full-duplex on two bands?  How about
>full duplex on one band?

In Ottawa, we've had a cross-band full-duplex 56kb repeater on the air
for about a year.  There are some full-duplex 56kb point-to-point links
in the Chicago area... I believe they are in the 70 cm band.

>Is it best to use something like the DRSI card in the PC or
>has anyone connected the 'DSY to an outboard TNC?

Neither of these is a good solution.  The former can't run at 56kb unless
you turn off interrupts, so any other interrupt-driven interfaces fall on
the floor when you're processing 56kb packets.  The latter can't run at
56kb on the PC interface, period.  In my humble (and slightly biased :-)
opinion, the best choice currently available for interfacing the 56kb
modem to a PC is the Ottawa PI DMA board.  You can e-mail me for details.
The Cadillac of PC interfaces is the Grace PackeTen board, but it has far
more firepower than you need for a 56kb end user or small packet switch,
and it costs about 6 times as much as the PI.  The Kantronics Data Engine
might do for a small switch, but it is crippled for end user applications
by having only a 19.2kb host interface.

>Any tips, clues, cautions would be appreciated.

Go for it!  There's plenty of folks on the net who can give you a helping
hand with getting 56kb gear up and running.

>Thanks and 73, Chris

Barry VE3JF


| Barry McLarnon     Communications Research Center, Ottawa, ON, Canada |
| Internet: [e-mail]                                           |
| Packet BBS: VE3JF@VE3JF        AMPRnet: [e-mail]3jf [44.135.96.6] |

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

Date: 21 Dec 90 13:52:48 GMT
From: mintaka!ai-lab!life![e-mail]  (Pace Willisson)
Subject: High speed point to point Backbones ...
To: [e-mail]

Instead of modifying the 48 bit ethernet address, how about appending
a 6 byte ASCII call sign to the end of the real data in the packet?
All of the protocols are prepared for trash after the end of the data,
since small packets must be padded to the ethernet minimum of about 60
bytes.

Pace Willisson
WD4JQQ
[e-mail]   uunet!blitz!pace

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

Date: 21 Dec 90 14:58:59 GMT
From: usc!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!netnews.upenn.edu!platypus![e-mail]  (Bill Gunshannon)
Subject: High speed point to point Backbones ...
To: [e-mail]

In article <[e-mail]>, [e-mail] (Mike Yetsko) writes:
> Before the re-programming of ethernet addresses to reflect the HAM
> callsign is considered, an algorithm for the implementation of that
> number needs to be established.  I propose this start a discussion to
> try to come up with a scheme NOW to figure out what to do.

I have already given it some consideration although not in the context
of using Ethernet cards for packet.  I have been looking into the
possibility of using a form of IEEE 802 framing for packet.  The reasoning
for this being the generally accepted concept that AX.25 offers little
except overhead and the fact that protocols like TCPIP (my main interest)
use UI frames which makes no use of the features of AX.25 anyway.

>
> The address is contained as a unique number of 6 bytes.  These numbers
> are sold in 'blocks' by the IEEE, and while you don't 'legally' need
> one, everyone in the game plays by the rules.  Also, the addresss needs
> to contain the FCC licensed callsign of the transmitting station.  In 6
> bytes, that can be tough.

I believe that coordination with the IEEE would only be necessary if you
planned on using this identifier on an Ethernet with other vendors equipment.
Because every interface has it's own address, I think this is not likely
and conflicts could only occur when a serious mistake happens.  By the way,
this is theoretically possible today when you use things like DECNET where
addresses are generated in software and not contained in a prom on the
card.

>
> The FCC approval may be minor, as if everybody does this, then it is
> the format used, and as long as it is made public, no problem.  Perhaps
> someone more familiar with the rules could comment.
>
COMPLEX SCHEME DELETED

I propose a much simpler system that will not require any FCC approval
because it already meets their approval.

There are six bytes available for an address.  The exact same number as
for AX.25 callsigns.  It only takes 7 bits to encode the callsigen using
straight ASCII.  Therefore, just put the callsign in ASCII and blank fill
the unused bytes using the ASCII SPACE character (decimal 32 -- hex 20).
Use the 8th bit for coding SSID's.  That will not only keep the callsign
in plain ASCII for the sake of the FCC, but will allow for more SSID's than
we currently have (6 bits = 64 SSID's.)

I think changing to this method would allow us to use modified versions
of a lot of what is already out there in networking software.  Just
imagine, PCBridge running in that mountain top repeater site.  Runs easily
in 128K from a floppy.  How long before somebody EPROMS it and makes a
bridge from an AMPRO clone board??

Comments??

bill    KB3YV


--

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

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

Date: 21 Dec 90 16:45:40 GMT
From: usc!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!bagate!cbmvax!atha!aupair.cs.athabascau.ca![e-mail]  (Ross Alexander)
Subject: High speed point to point Backbones ...
To: [e-mail]

[e-mail] (Mike Yetsko) writes:

>Before the re-programming of ethernet addresses to reflect the HAM
>callsign is considered, an algorithm for the implementation of that

Good grief.  Forget all that nonsense.  There's no need to go to all
that trouble.  You're going to be encapsulating some other protocol's
packets inside the raw ethernet packets, aren't you?  Just stick the
calling/called station's IDs *after* the encapsulated protocol's
packet, in plain ASCII.  thusly:

    enet header & size
        encapsulated protocol's header & size
            encapsulated protocol's data
        encapsulated protocol's trailer(s)
        Called & Calling station's id's
    enet trailer info

Much simpler all around.

--
--
Ross Alexander    [e-mail]    [phone]    ve6pdq

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

Date: 22 Dec 90 00:40:14 GMT
From: dog.ee.lbl.gov![e-mail]  (Alan Biocca)
Subject: High speed point to point Backbones ...
To: [e-mail]

In article <[e-mail]> [e-mail] writes:

>One of the main concerns is whether it is possible to plug a new ethernet
>address prom into the card with the callsign burnt in rather than the
>standard ethernet address for station id purposes...

It really isn't necessary to burn anything.  The actual ethernet address
used by the interface is initially loaded from a prom -- but it is used
out of a register in the chip.  Some protocols (DECNET) actually change
the ethernet address of the board based on their addressing scheme.

Additionally, it is not quite one ethernet address per interface -- it is
one address per processor.  It is legal and normal for a machine to use
the same ethernet address on all of its interfaces (on different networks).

Alan K Biocca
WB6ZQZ

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

Date: 20 Dec 90 19:56:30 GMT
From: unixhub!shelby![e-mail]  (paulf)
Subject: High speed point to point Backbones ...
To: [e-mail]

Simpler yet.  Have a daemon kick out a packet every ten minutes that says
"Hi.  You're watching packets form W6YX".   Legal, too.

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

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

Date: Fri, 21 Dec 90 09:09:00 EST
From: [e-mail] (ase)
Subject: KAM
To: [e-mail], [e-mail]

To those who have responded to the problems I have had with my KAM in
KISS MODE, thanks. Here is an update:


My configuration is as follows:

computer 16Mhz AT<------50 Feet shielded full modem cable--->KAM
Only using VHF/ No HF

PLM: Intermittent STA light stays lit

I discovered yesterday that if I exit NET and bring up a term pgm
like PCPLUS (STA light still on), if I enter a sequence 192 the
STA light goes off and the TNC xmit light cycles up as if to send out
ack. I am still coming up to speed on the light sequences and what
they mean? Does this have to do with an FEND? I noticed in the
Kantronics manual that C0 is a fend and also if I were to pop out
of kiss I would issue a 192 255 192. mmm? What does someone think

about this? Again my thanks for your help in this matter.

Jay

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

Date: Fri, 21 Dec 90 12:45:26 EST
From: "Ward Carpenter" <[e-mail]>
Subject: NOS and Shared Interruptson MS-400 Card
To: [e-mail]

I am trying to run NOS to replace my current system (MSYS) and am having
trouble getting NOS to work with my setup. I am running 3 comm ports in
an MS-400 async card with the AA4RE modification to allow the 3 ports to\
share the same intrupt (IRQ2). Now, this card works with MSYS as it has
a built in interupt handler. It also works when you load MBBIOS (another
AA4RE product) which is a TSR interupt handler. Using MBBIOS and the
modifed card allows you to run the standard bbs programs RLI/MBL etc
on the shared port. It also worked with the old NET.EXE (before NOS).

Now, when I try to run NOS with this card and put the correct information
in the autoexec.net file, NOS talks to one of the ports but can't hear
anything. I can issue a connect command and you see the station trying
to answer (on the s meter) but NOS won't hear it. And, the other ports
don't work at all. With or without MBBIOS, this problem exists. When using
a standard comm port (1 or 2) NOS works fine.

Is anyone using NOS with the MS-400 card (or any other multi-port async
card with the diode modification that AA4RE came out with) with or without
MBBIOS out there, I am at my wits end (whatever that is...... grin..)

thanks!!


Ward Carpenter
N1CUI @ N1CUI-8
44.88.0.13
Rigdefield, CT

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

Date: 20 Dec 90 15:37:48 GMT
From: n8emr![e-mail]  (Gary Sanders)
Subject: Source for HARN, PC-100, NOS
To: [e-mail]

In article <[e-mail]> [e-mail] (Brandon S. Allbery KB8JRR) writes:
>As quoted from <[e-mail]> by [e-mail] (Bdale Garbee):
>
>N8EMR in Columbus runs XBBS and I believe has anonymous uucp.  Unfortunately,
>I've lost the phone numbers (again --- aargh!!!).  If I can get caught up the

My BBS can be reached at 614-895-2553 (1200/2400/9600(v.32)/PEP with MNP L5
No anonymous uucp on the system, but do support zmodem,ymodem-batch,xmodem
on a telebit t2500. All of the latest nos source/exe plus MB of ham related
softwate.


--
Gary W. Sanders (gws@n8emr or ...!osu-cis!n8emr!gws), 72277,1325
N8EMR @ W8CQK (ip addr) 44.70.0.1 [Ohio AMPR address coordinator]
HAM BBS (1200/2400/9600/V.32/PEP/MNP=L5) 614-895-2553
Voice: 614-895-2552 (eves/weekends)

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

Date: 21 Dec 90 20:01:06 GMT
From: swrinde!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!netnews.upenn.edu!platypus![e-mail]  (Bill Gunshannon)
Subject: The PACCOMM TNC 220
To: [e-mail]

Does anyone have a version of TNC220 firmware that supports KISS??

Does anyone have programming information on the TNC220 that would
allow me to modify the TNC2 version of the KISS EPROM to work in the
TNC220??

I realize that it really doesn't have 2 ports like the KAM and won't
be able to listen\talk on both channels, but I sure would like to use
it as a KISS TNC for VHF.  I don't get on HF enough that I really care.

Anybody in Florida that can ask PACCOMM for programming info??

bill   KB3YV


--

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

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

End of Packet-Radio Digest
******************************
Date: Sun, 23 Dec 90 04:30:03 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #227
To: packet-radio


Packet-Radio Digest         Sun, 23 Dec 90       Volume 90 : Issue 227

Today's Topics:
        Any USENET sites reachable by packet?
           DSP Designs and Packet Protocols
     MSYS 1.09 |and| Re: High speed point to point Backbones ...
        Need Help Setting up a TCP/IP Station.
           NOS and Shared Interrupts on MS-400 Card
             Paccomm Tiny 2 Plus
          Packet Software/Hardware for the Macintosh
             The PACCOMM TNC 220

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 90 22:37:30 GMT
From: tippy![e-mail]
Subject: Any USENET sites reachable by packet?
To: [e-mail]

Does anyone know of any public access unix sites reachable by packet radio? My
father-in-law has just set-up a packet site, and since he's in a rural area it
would be great if I could exchange mail and files with him without having to
make long-distance phone calls.

Thanks!


______________________________________________________________________________
| Jonathan Neuenschwander                        |"My views on evolution?    |
| USENET:   tippy![e-mail] | I think Darwin was        |
| AMERICA ONLINE:  Buzz Lee                      | adopted." --Steven Wright |
|________________________________________________|___________________________|
|DISCLAIMER:  The opinions and views depicted here are completely fictious.  |
|Any resemblence to any actual opinions or views, either living or dead, is  |
|purely coincidental.                                                        |
|____________________________________________________________________________|

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

Date: 23 Dec 90 07:14:30 GMT
From: cs.utexas.edu!ut-emx![e-mail]  (Brett Jacobson)
Subject: DSP Designs and Packet Protocols
To: [e-mail]

[Note: This is forwarded for a friend of mine who's UseNet access is
questionably reliable. ]

Set-up info:  I am currently working on a DSP design project with a
friend of mine (he has a license, I can't get CW high enough to qualify,
my brain doesn't cut it some times) that we plan to encompass most (if
not all) packet protocols (actually just data protocols, with packet
being one of them).

We have reached the point, where an AI based CW interpreter has been
designed (and implemented), however, we are seriously lacking in
information on other protocols.  The following is a list of protocols we
are currently looking at, thought any other suggestions are of-course,
welcome:

Morse Code
Baudot RTTY
Variable Baudot RTTY
Bit inverted Baudot RTTY
ASCII High and Low Speed
SITOR Mode A (also ARQ)
SITOR Mode B (also FEC)
ARQ 2 and 4 channel (TDM)
ARQ-E
ARQ-E3
VFT Mode (FDM)
Russian Third Shift Cryillic
FAX AM/FM
Packet 300/1200 AX.25
V26.b 2400bps Packet
K9NG 9600bps direct FSK

This is of-course a small list of what the chips are capable of.
Current development is being done on a NeXT machine, however, we are
contemplating moving to the TI series of chips (primarily the 340C25 and
340C30), even though it would require a redisign from the MC56001 series
we are currently working on.

Does anyone know where we can get COMPREHENSIVE information on these
protocols, and also on the protocols being used in HIGH SPEED (over
2400bps) communications, especially the recently mentioned 56Kbps and
2Mbps designs.

Thanks,
Chris Petrilli
[e-mail]
[e-mail]

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

Date: 22 Dec 90 16:59:09 GMT
From: munnari.oz.au!yoyo.aarnet.edu.au!sirius.ucs.adelaide.edu.au!levels![e-mail]
Subject: MSYS 1.09 |and| Re: High speed point to point Backbones ...
To: [e-mail]

A while back we got MSYS 1.08 from an ftp site, I cant remember which it was
either tomcat or thumper, anyway, does anyone know of, or can anyone provide
an ftp site for 1.09 of this package as well as the patch(s?) that followed
this versions release.

Regarding the discussion on 10baseR (Can we coin a new term here??, should it
be M for Microwave ?? :-) ).
1. Would there be any serious problems with the suggestion of giving the once
   10 minute broadcast of your staions call for id purposes ?? Seems like this
   would be easy to incorporate in most of the software around, eg NOS ??
   it sounds too simple, but if its ok for voice !!?
2. If it were lobbied at the correct level internationally, the concept of
   getting IP addresses recogised as legal identification, based on the fairly
   well defined way in which they are allocated, would probably be a better
   idea !? Im assuming here that most stations using this link speed would use
   a level 3 protocol of some description, and IP would probably be the
   easiest to establish a case for, Any idea's ??

Im pleasantly surprised to see that there is a significant amount of interest
in this area, I wasnt sure if it was a bit of a dream on my part.
I get the feeling that the id requirements OS are easier than those in VK land
, I may be wrong, but ive heard that level3  netrom and routed tcp/ip are both
non-conformant to our DOTC regulations at this time. I understand that there
are moves a-foot to do in VK the same as what ive passed on in comment 2.

Ill collect all the postings on these and related spin-off subjects, and try to
get together a combined posting of the options suggested.

73's ... Rob VK5XXX

--
Rob Mayfield    -  ASC Network Support, VK5XXX/ZEU
Internet/AARNet -  [e-mail]        [AMPR_TCP/IP VK5 Co-ordinator]
Applelink       -  AUST0177
AMPR            -  VK5XXX@VK5WI.#SA.AUS.OC  [ or     VK5ZEU@VK5WI.#SA.AUS.OC]
OZPost          -  Post Office Box 46,  Henley Beach,  South Australia,  5022
Voice or Pix    -  Home : [phone]  Work : [phone]/7001 Voic/Fax

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

Date: 22 Dec 90 20:16:14 GMT
From: [e-mail]  (Scott R. Weis KB2EAR)
Subject: Need Help Setting up a TCP/IP Station.
To: [e-mail]

Can some on help me? I am tring to set up a link between my Unix
computer and my MSDOS computer and also link it to the packet world via
the dos box.

At this piint I'm totaly lost so any help would be a great help. the
versions of the ka9q software are

UNIX: v890421.1
DOS:  v901130

Tnx, 73,

Scott Weis KB2EAR
kb2ear![e-mail]

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

Date: Sat, 22 Dec 90 22:39:47 EST
From: [e-mail] (Barry McLarnon DGBT/DIP)
Subject: NOS and Shared Interrupts on MS-400 Card
To: [e-mail]

I don't think anyone has ported the shared interrupt code from NET to NOS.
The author, Dan Frank W9NK, now lives in the Ottawa area... next time I talk
to him, I'll ask him if he's interested in doing it, or knows someone who's
already working on it.  In the meantime, consider another possibility: the
G8BPQ code supports the MS-400 in shared interrupt mode (I think), and it
also has a KISS TNC emulator which allows it to run as a front end to NOS.
G8BPQ also has some advantages in its NET/ROM support over NOS, such as
greater configuration flexibility and a familiar interface for the AX.25
users.  This combination might be what you're after.

Barry

| Barry McLarnon     Communications Research Center, Ottawa, ON, Canada |
| Internet: [e-mail]                                           |
| Packet BBS: VE3JF@VE3JF        AMPRnet: [e-mail]3jf [44.135.96.6] |

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

Date: 22 Dec 90 15:24:49 GMT
From: att!cbnewsj![e-mail]  (thomas.kenny)
Subject: Paccomm Tiny 2 Plus
To: [e-mail]

I see that Paccomm has an upgrade to the Tiny 2 (and Micro 2) TNCs.
Since I have one I'm wondering if it is worth it. I'm also wondering
how the multi EPROM arrangement works. Anybody have any comments?
73 DE KB2GLO, Tom.

--
Tom Kenny, KB2GLO
uucp:   att!lzatt!tek          internet: [e-mail]
packet: [e-mail]  ampr: [e-mail] [44.64.0.10]

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

Date: 22 Dec 90 10:00:24 GMT
From: mcsun!ukc!slxsys!ibmpcug![e-mail]  (David Johnson)
Subject: Packet Software/Hardware for the Macintosh
To: [e-mail]

I would like to get into packet radio, but it appears that
most of the software/hardware availble is for PC's. Is there
any avaiable for the Mac.

THanks in advance



Dave G4DPZ
--
Automatic Disclaimer:
The views expressed above are those of the author alone and may not
represent the views of the IBM PC User Group.
--

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

Date: Sat, 22 Dec 90 22:27:39 EST
From: [e-mail] (Barry McLarnon DGBT/DIP)
Subject: The PACCOMM TNC 220
To: [e-mail]

A version of KISS for the TNC-220 is included in the G8BPQ package.  Grab
the file bpq359.zip from tomcat.gsfc.nasa.gov, and you'll find it therein.

Barry

| Barry McLarnon     Communications Research Center, Ottawa, ON, Canada |
| Internet: [e-mail]                                           |
| Packet BBS: VE3JF@VE3JF        AMPRnet: [e-mail]3jf [44.135.96.6] |

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

End of Packet-Radio Digest
******************************
Date: Mon, 24 Dec 90 04:30:03 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #228
To: packet-radio


Packet-Radio Digest         Mon, 24 Dec 90       Volume 90 : Issue 228

Today's Topics:
           High speed point to point Backbones ...
          MAC HARDWARE/SOFT WARE FOR PACKET
     MSYS 1.09 |and| Re: High speed point to point Backbones ...
        Open Letter to ARRL Pres. Larry Price
          Packet Software/Hardware for the Macintosh

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 90 18:03:09 GMT
From: usenet.ins.cwru.edu!ncoast![e-mail]  (Brandon S. Allbery KB8JRR)
Subject: High speed point to point Backbones ...
To: [e-mail]

As quoted from <[e-mail]> by [e-mail] (paulf):
+---------------
| Simpler yet.  Have a daemon kick out a packet every ten minutes that says
| "Hi.  You're watching packets form W6YX".   Legal, too.
+---------------

Heck, yes.  That's how I operated 2m packet while I was still /KT:

cmd: unproto id via wa8bxn
UNproto was CQ
UNproto now CQ via WA8BXN
cmd: btext KB8JRR/KT, Mentor, OH.
BText   was
BText   now KB8JRR/KT, Mentor, OH.
cmd: beacon every 57
Beacon  was EVERY 0
Beacon  now EVERY 57 (570 sec.)
WARNING: Beacon too often
cmd:

The warning before every prompt (blame AEA...) was a small price to pay for
the assurance of legality.  And it can be applied to any other situations
where a packet station needs to give a guaranteed ID.  (Well, most.  IP
stations require either a TNC that will beacon in KISS mode, or recent
versions of G1EMM and possibly the other variants.  I found it easier to
operate on 220 until I had my license in hand, even though my TNC does beacon
in KISS mode.)

++Brandon
--
Me: Brandon S. Allbery                      VHF/UHF: KB8JRR on 220, 2m, 440
Internet: [e-mail]                Packet: KB8JRR @ WA8BXN
America OnLine: KB8JRR                      AMPR: KB8JRR.AmPR.ORG [44.70.4.88]
uunet!usenet.ins.cwru.edu!ncoast!allbery    Delphi: ALLBERY

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

Date: Sun, 23 Dec 90 15:20:34 MST
From: Larry L. Springstee <[e-mail]>
Subject: MAC HARDWARE/SOFT WARE FOR PACKET
To: [e-mail]

RE: Packet Software/Hardware for the Macintosh

David Johnson  Writes:
>I would like to get into packet radio, but it appears that
>most of the software/hardware availble is for PC's. Is there
>any avaiable for the Mac.

Hi David,
  Getting on Packet using a Mac is not hard. You will need to decide on a
TNC to use. The TNC is a personal choice, I'm using a PacCom TNC-220 and
used a PacCom Tiny 2 as a loaner. I used a modem cable from the Mac to the
TNC and had to HOME BREW (yes I did) the cable from the TNC to the radio.

  You will need a terminal program. I am using RedRyder 9.2 for Packet.
I have tried White Knight 11.?? and RedRyder 10.3 on Packet as well. If you
use a terminal program for your landline communications it will also work
for you on Packet. If you go with a Multimode TNC then you will want
software to take advantage of the TNC's extra functions. I have no
experience with the Multimode TNC's.

  I hope this answers one or more of your questions. If not give me a
shout. I know of other Ham goodies for the Mac as well.

e mail--> LSPRINGSTEEN @ WSMR-SIMTEL20.ARMY.MIL
Packet--> LARRY WB8LBZ @ K5WPH-2.NM.USA.NA
Ma Bell-> w [phone]/1913/2330/2039   any one
      h [phone] after 1600 before 2000 MST(MDT)
        1200/2400  by prior arangement only

>THanks in advance
>Dave G4DPZ

You are welcome in advance too!
Larry  WB8LBZ in El Paso, TX (the Real West Texas)
-------

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

Date: 23 Dec 90 19:24:24 GMT
From: usenet.ins.cwru.edu!ncoast![e-mail]  (Brandon S. Allbery KB8JRR)
Subject: MSYS 1.09 |and| Re: High speed point to point Backbones ...
To: [e-mail]

As quoted from <[e-mail]> by [e-mail]:
+---------------
| A while back we got MSYS 1.08 from an ftp site, I cant remember which it was
| either tomcat or thumper, anyway, does anyone know of, or can anyone provide
| an ftp site for 1.09 of this package as well as the patch(s?) that followed
| this versions release.
+---------------

I'll talk to Mike WA8BXN.  In fact, I think I saw something with an HID of
[MSYS-1.10-H$], so things may be even farther along than we all thought....

++Brandon
(P.S.  Confirmed; I just connected to BXN, and it's IDing with version 1.10.)
(P.P.S.  I just dropped a note to Mike, after a half hour and being blasted
off ncoast by line noise in the middle of editing this message.  If he comes
through with it, I'll try get it to Simtel-20 and maybe thumper (Phil?).)
--
Me: Brandon S. Allbery                      VHF/UHF: KB8JRR on 220, 2m, 440
Internet: [e-mail]                Packet: KB8JRR @ WA8BXN
America OnLine: KB8JRR                      AMPR: KB8JRR.AmPR.ORG [44.70.4.88]
uunet!usenet.ins.cwru.edu!ncoast!allbery    Delphi: ALLBERY

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

Date: 24 Dec 90 04:11:13 GMT
From: w8grt![e-mail]  (Jim Grubs)
Subject: Open Letter to ARRL Pres. Larry Price
To: [e-mail]

      On Decemer 13th, the FCC modified the requirements for the Technician
Class license with a code test. This bold move offers great hope to all of us
who are deeply concerned with the possibility that amateur radio will one day
soon be crushed under the weight of the spectrum needs of other services.

      I was disturbed to note, however, that you were reported to be
considering asking the FCC to reconsider this action to the extent of
confining the new codeless Technicians to 222 mhz and up. I consider this
most unwise for the following reasons:

      One basic Technician Class license with one written exam + a CW
endorsement for those who want to operate on HF would be easier and cheaper
for the FCC to administer.

      "Ghetto-izing" the codefree Technician Class licensees provides no
regulatory or technological benefit. Rather, it serves only to codify social
discrimination by preventing the newcomers from coming into contact with the
majority of their fellow amateur operators.

      Amateur radio constitutes the United States' first National Park of the
Mind, and broad, open access to that public resource will provide
intellectually stimulating and spiritually refreshing benefits to the nation
that narrow, inhibitory access by the privileged few cannot. I believe that
that is the basic reason the FCC made its decision.

      Amateur radio's greatest contributions to the state of the art occurred
during the period of its early history when it was not straight-jacketed by
complex regulations and licensing structures not based on compelling need.
Preventing or inhibiting the freest possible exploration of the National Park
of the Mind consistent with conserving its meaningful existence would tend
toward reducing it to the site for historical tableaux similar to those re-
enactments of medieval jousting.

      There is no compelling need for creating your proposed codefree ghetto.
Therefore, any request for reconsideration will doubtlessly be rejected out
of hand. The only result of a Petition for Reconsideration will be to make
the League look foolish.

      Moreover, since the new codefree amateurs are going to revitalize the
future of ham radio, resentment against the organization that attempted to
cause part of the original promise to be withdrawn would no doubt result in
very few of them joining the League, which would very likely become little
more than the custodians for its Antique Wireless Museum.

      To summarize, it's a dumb idea.

73 de Jim Grubs, W8GRT
Copies: Michael Covington, Wayne Green, Fred Maia, Don Stoner, Phil Karn,
Scott Loftesness

---
 * Origin: HAM RADIO - The 1st National Park of the Mind! (1:234/1)

--
Jim Grubs - via the friendly folks at UUNET
UUCP: ...!uunet!w8grt!jim.grubs
INTERNET: [e-mail]

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

Date: 23 Dec 90 18:17:22 GMT
From: usenet.ins.cwru.edu!ncoast![e-mail]  (Brandon S. Allbery KB8JRR)
Subject: Packet Software/Hardware for the Macintosh
To: [e-mail]

As quoted from <[e-mail]> by [e-mail] (David Johnson):
+---------------
| I would like to get into packet radio, but it appears that
| most of the software/hardware availble is for PC's. Is there
| any avaiable for the Mac.
+---------------

For straight packet, any TNC (aside from the PC bus cards, of course) works
and any Mac comm package can be used.  I started out using a PK88 and ZTerm
0.85; the PK88 and most other TNCs can be connected with an ordinary modem
cable.

Anything else is harder or impossible, unfortunately:  I don't think ROSE is
available for the Mac, and the only version of the KA9Q software is an old
version of NET; the NOS port is still in progress.  In any case, I suspect
that for ROSE and KA9Q you'd want more serial ports than the Mac provides.
But if all you're after is straight AX.25 packet, you don't need anything
except a modem cable and any comm software.

AEA has MacRATT and MFJ has MultiCom for the Mac, if you want a fancier
interface.  I believe you can buy a package from MFJ that includes the modem
cable and MultiCom, for the MFJ 1270/1274/1278.

73,
++Brandon
--
Me: Brandon S. Allbery                      VHF/UHF: KB8JRR on 220, 2m, 440
Internet: [e-mail]                Packet: KB8JRR @ WA8BXN
America OnLine: KB8JRR                      AMPR: KB8JRR.AmPR.ORG [44.70.4.88]
uunet!usenet.ins.cwru.edu!ncoast!allbery    Delphi: ALLBERY

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

End of Packet-Radio Digest
******************************
Date: Tue, 25 Dec 90 04:30:04 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #229
To: packet-radio


Packet-Radio Digest         Tue, 25 Dec 90       Volume 90 : Issue 229

Today's Topics:
              Just a reminder...
             MSYS - send it now or later?
              Need Amiga/PK232 Software
        PACKET SOFTWARE/HARDWARE FOR THE MACI
            The Amateur Radio BBS - UPDATE

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 90 01:31:14 GMT
From: w8grt![e-mail]  (Jim Grubs)
Subject: Just a reminder...
To: [e-mail]

(72)    Sun 4 Nov 90 10:42p
By: "CAL-LAB ", MS:JER2-85 TEL:7589
To: All
Re: MARS Traffic to Gulf Region
St:
------------------------------------------------------------------------------
@UFGATE newsin 1.27
From: [e-mail] ("CAL-LAB ", MS:JER2-85 TEL:7589)
Date: 4 Nov 90 14:41:00 GMT
Organization: The Internet
Message-ID: <[e-mail]>
Newsgroups: rec.ham-radio

>>From: sdd.hp.com!wuarchive!emory!auc![e-mail]  (Daniel Gibson )
>>Subject: Finding a MARS operator close to Saudi Arabia with an account on the
network

>>HELP!!!!!!!! I am looking for a MARS operator that is on
>>the network. The reason is that I am hoping that I could
>>send my messages to that person and that later on
>>they could deliver it. I am trying I guess to be innovative
>>a little(well maybe not) in doing this. Hopefully this person or
>>persons will be closer to Saudi Arabia than I am now when I
>>send a MARS message.

>>Is there anybody out there?

>>Thank-You

>>Dan Gibson


Hello Dan,

      There is a packet BBS running out of the American Embassy in Saudi Arabia
using the callsign 7Z1AB. The BBS is intended for handling mail only traffic
for deployed U.S. military personel stationed in the Gulf region.
      If you're intentions are to pass traffic through the net, you can E-mail
a note to Jim Stone - who set up the link, explaining how much traffic
will be passed and work out the logistics.
the E-Mail address for Jim Stone is:

"[e-mail]"

Good luck
es 73,
Rich

--
Jim Grubs - via the friendly folks at UUNET
UUCP: ...!uunet!w8grt!jim.grubs
INTERNET: [e-mail]

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

Date: 24 Dec 90 22:36:14 GMT
From: usenet.ins.cwru.edu!ncoast![e-mail]  (Brandon S. Allbery KB8JRR)
Subject: MSYS - send it now or later?
To: [e-mail]

As per my earlier message to the newsgroup, I have secured a copy of the
latest released MSYS.  However, I'm not sure I want to send it to the archive
sites just yet.

The problem is that the version I have is 1.09 (with the patches).  Mike
WA8BXN is currently beta-testing 1.10, however.  The question is, should I
send out 1.09 now or wait a week or so for the release of 1.10?

(For those who don't want to wait, I can email it --- a uuencoded file in 8
parts comprising MSYS109.EXE, a self-unpacking archive.  Please hold the
number of requests down, however, as ncoast is having some mailer problems at
the moment and I have to make sure they go out only after I make some manual
patches to the maps after each pathalias run.)

73,
++Brandon


--
Me: Brandon S. Allbery                      VHF/UHF: KB8JRR on 220, 2m, 440
Internet: [e-mail]                Packet: KB8JRR @ WA8BXN
America OnLine: KB8JRR                      AMPR: KB8JRR.AmPR.ORG [44.70.4.88]
uunet!usenet.ins.cwru.edu!ncoast!allbery    Delphi: ALLBERY

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

Date: 24 Dec 90 13:36:06 GMT
From: zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!dali.cs.montana.edu!caen!uflorida!kluge!serss0![e-mail]  (Hamilton Davies)
Subject: Need Amiga/PK232 Software
To: [e-mail]

A friend of mine, w/o net access, has an Amiga 500 and a PK232.  He would
like a dedicated packet program for this setup.  He is currently using
the PK with a C64 and cart based software.  Any assistance would be greatly
appreciated.

--Ham

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

Date: 24 Dec 90 21:11:02 GMT
From: w8grt!f470.n101.z1.fidonet.org![e-mail]  (Tom Mcgee)
Subject: PACKET SOFTWARE/HARDWARE FOR THE MACI
To: [e-mail]

In response to David Johnson's article:

>> get into packet radio, but it appears that
most of the software/hardware availble is for PC's. Is there
any avaiable for the Mac. <<

All you need is a telecommunication package like Zterm, White Knight, or
other and a TNC connected to your Mac with a regular modem cable....and then
you just connect the TNC to your radio. Works like a charm.

73, de KA1TOX
--- TBBS v2.1/NM
 * Origin: Tom's BBS - Wollaston, MA - 617/471-3009  (1:101/470)

--
Tom Mcgee - via the friendly folks at UUNET
UUCP: ...!uunet!w8grt!101!470!Tom.Mcgee
INTERNET: [e-mail]

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

Date: 24 Dec 90 20:04:02 GMT
From: zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!wb3ffv![e-mail]  ( WB3FFV)
Subject: The Amateur Radio BBS - UPDATE
To: [e-mail]

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


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

 System Name: WB3FFV
 User Login: bbs
 Number: (301)-625-0817 -- 1200 & 2400 (Non-MNP)
 Number: (301)-625-9482 -- 1200 & 2400 (MNP5), 4800 & 9600 V.32 (V.42/MNP5)
 Number: (301)-625-9663 -- 1200 & 2400 (MNP5), 9600 & 19200 (PEP)
 Data Settings: 8 Bits, NO Parity, 1 Stop Bit
 Times: 24hrs/365days  (except for routine maintenance)
 Software: XBBS  (UNIX/Xenix Multiuser BBS)
 IP Address: 44.60.128.1 {wb3ffv.ampr.org} [for FTP access on 145.650 mhz ONLY]
 Misc. Info: Machine is an 80486 computer running UNIX V.3.2 and features 700
         Meg of on-line storage. Most transfer protocols are available!!


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

 KA9Q TCP/IP Software for the PC (Latest OFFICIAL release + TEST Versions)
 KA9Q TCP/IP for the Atari-ST, MAC, & Amiga
 KA9Q TCP/IP for UNIX based systems
 KA9Q TCP/IP (The NOS release)  [UNIX, MS/DOS, Amiga]
 KA9Q TCP/IP (Version by G1EMM, PE1CHL, PA0GRI, Etc.)
 WA7MBL BBS for the PC (Versions 3.31, 4.31 & 5.1[2,3,4])
 W0RLI BBS for the PC (Versions 6.xx, 7.xx, 8.xx, 9.xx, 10.xx)
 MSYS BBS for the PC running KISS TNC's  (Version 1.09)
 AA4RE BBS for the PC (Version 2.10)
 Various BBS utilities and enhancements
 Several MORSE CODE Tutors
 TheNet software by NORD><LINK  (Version 1.01)
 Modifications for many HAM Rigs and Scanners
 Digital Signal Processing software (DSP)
 DX and contesting programs
 ARRL Newsletters & Gateway
 W5YI Electronic Edition

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

If you are interested in using UUCP to connect to the BBS, this can also be
done as I support Anon-uucp. The login to the system is 'uucpanon', and there
is NO password. The listing of avalible archives are stored in a file called
'FILES', and it is located in the /usr/spool/uucppublic. To retrieve the files
listing just use the following command:

uucp wb3ffv!~/FILES /usr/spool/uucppublic

This will move a copy of my files listing into your uucppublic directory.  If
you have any questions or problems, feel free to contact me at one of the
numbers/adresses below. Good Luck...

            H A P P Y   H O L I D A Y S !!

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

End of Packet-Radio Digest
******************************
Date: Wed, 26 Dec 90 04:30:03 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #230
To: packet-radio


Packet-Radio Digest         Wed, 26 Dec 90       Volume 90 : Issue 230

Today's Topics:
                 RTTY

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 90 06:46:19 GMT
From: van-bc!ubc-cs!alberta!herald.usask.ca!weyr!f31.n140.z1.FIDONET.ORG![e-mail]  (Shaun Hase)
Subject: RTTY
To: [e-mail]

I'm leaving this message for a friend who is interested in finding a decent radio teletype and other related programs (?) for a Sony ICF2010 radio and a XT-turbo computer.  Any replies will be greatly appreciated.

--
Shaun Hase - via FidoNet node 1:140/22
UUCP: ...!herald!weyr!31!Shaun.Hase
Domain: [e-mail]
Standard Disclaimers Apply...

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

End of Packet-Radio Digest
******************************
Date: Thu, 27 Dec 90 04:30:03 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #231
To: packet-radio


Packet-Radio Digest         Thu, 27 Dec 90       Volume 90 : Issue 231

Today's Topics:
              TNC-1 in 300 bps KISS-mode

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

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

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

Date: Thu, 27 Dec 90 09:58:48 +0100
From: [e-mail]
Subject: TNC-1 in 300 bps KISS-mode
To: [e-mail]

Hello all,

I have tried to put one of my TNC-1's in KISS on HF...
The TNC works fine in 300 bps when in TARP-mode, but when I install a KISS
EPROM I can see everybody on the frequency, but nobody seems to understand
my transmissions. Could this be a problem similar to the ** HDLC can't init **
message I get when HBAUD is set to 300 bps in TAPR-mode, and a RESET is
done? Does anyone know of a version of KISS that will work on 300 bps?
Is anyone using a TNC-1 in KISS at 300 bps?

Have a good 1991!

73 de
   __
  / /   /
 /-/ __/ __/ ____
/ / (_/ (_/ / / /


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

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

End of Packet-Radio Digest
******************************
Date: Fri, 28 Dec 90 04:30:02 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #232
To: packet-radio


Packet-Radio Digest         Fri, 28 Dec 90       Volume 90 : Issue 232

Today's Topics:
         no-code license -- is it soup yet? (2 msgs)
           Warning -- packet-demo,plus,gold

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 90 16:21:59 GMT
From: zaphod.mps.ohio-state.edu!rpi!masscomp!westford.ccur.com![e-mail]  (Robert Chesler)
Subject: no-code license -- is it soup yet?
To: [e-mail]

I read a post in another newsgroup that said "...now that we have
a no code license..."   Do we really have this yet?

If we do, where can I get tested in Southern NH?

--Robert

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

Date: 27 Dec 90 19:37:09 GMT
From: cs.utexas.edu!usc!wuarchive!rex!uflorida!mailer.cc.fsu.edu!sun13![e-mail]  (John Murray)
Subject: no-code license -- is it soup yet?
To: [e-mail]

In article <[e-mail]> [e-mail] writes:
>
>I read a post in another newsgroup that said "...now that we have
>a no code license..."   Do we really have this yet?

The FCC has proposed dropping the 5wpm Morse requirement for the Technical
class license. No-code techs would have all tech priviledges above 30MHz.
Old techs, and new techs who take and pass the 5wpm test, will retain all
current tech priviledges. As for date effective, I have heard early '91,
like Jan. or Feb, HOWEVER the ARRL is currently deciding whether to petition
the FCC to reconsider. The ARRL wants to make it (I think) 220MHz and up.

Do you have a problem with the ARRL's position on this? Let them know!!
I'm going to..

>If we do, where can I get tested in Southern NH?

Same place as always. It's a plain old Tech test, but written only..

This was posted instead of mailed, since there might be some other non-
readers of rec.ham-radio out there (I don't blame them at all) unaware
of the FCC decision. However, rec.ham-radio.packet is not the appropriate
place for discussion of this subject. Followups directed to rec.ham-radio

>--Robert

--
Disclaimer: Yeah, right, like you really believe I run this place.
John R. Murray              |        "Never code anything
[e-mail]   |          bigger than your head.."
Supercomputer Research Inst.|               - Me

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

Date: 27 Dec 90 18:18:32 GMT
From: [e-mail]  (Ted Medin)
Subject: Warning -- packet-demo,plus,gold
To: [e-mail]

 Got the pgm packet-demo and tried to see how it worked. After lots of
problems decided that any pgm that wouldnt let one do a "mh" wasnt of any
use to me. THEN i found out the pgm had locked up my tnc so i couldnt
run mskermit or kermit-65 to talk to the tnc anymore. Looked all thru
the doc (but didnt read it all) for some help but found none. HAD to
reset the tnc and start over again :-(. So im recommending this pgm to
all my enemys :-).
 Anyone got any ideas on what i did wrong.
73, ted
n6trf

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

End of Packet-Radio Digest
******************************
Date: Sat, 29 Dec 90 04:30:02 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #233
To: packet-radio


Packet-Radio Digest         Sat, 29 Dec 90       Volume 90 : Issue 233

Today's Topics:
           Warning -- packet-demo,plus,gold

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

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

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

Date: 28 Dec 90 22:23:41 GMT
From: netcom![e-mail]  (Edward Greenberg)
Subject: Warning -- packet-demo,plus,gold
To: [e-mail]

In article <[e-mail]> [e-mail] (Ted Medin) writes:
>
> Got the pgm packet-demo and tried to see how it worked. After lots of
>problems decided that any pgm that wouldnt let one do a "mh" wasnt of any
>use to me. THEN i found out the pgm had locked up my tnc so i couldnt
>run mskermit or kermit-65 to talk to the tnc anymore. Looked all thru
>the doc (but didnt read it all) for some help but found none. HAD to
>reset the tnc and start over again :-(. So im recommending this pgm to
>all my enemys :-).
> Anyone got any ideas on what i did wrong.
>73, ted
>n6trf

I use Packet Plus, and can speak to some of your problems....

1.  The demo doesn't do an MH, but the full program does.  You have to
request it with ALT-F2 though, since the TNC doesn't seem to understand it
when you do MH<F10>  I believe that it's a function of the way the data comes
back when in host mode.

2.  Packet Plus or Gold should reset your TNC to normal on the way out.  Mine
does.  If you BOMB out, you can regain control of the TNC with three
^C's sent within one second.

You need to tweak the STARTUP and SHUTDOWN.TNC files for the way you want the
TNC left when you're done.

PP works well for me, and I use it for most of my conversational and BB
related packet work.
--
Ed Greenberg                    WB2GOH/6
edg@netcom                      {amdahl | amdcad | apple}!netcom!edg
CompuServe: 76703,1070          Packet Radio: WB2GOH @ N6LDL.CA.USA.NA

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

End of Packet-Radio Digest
******************************
Date: Mon, 31 Dec 90 04:30:02 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #234
To: packet-radio


Packet-Radio Digest         Mon, 31 Dec 90       Volume 90 : Issue 234

Today's Topics:
            DX Cluster protocol? (3 msgs)

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

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

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

Date: 30 Dec 90 04:54:31 GMT
From: cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!news.funet.fi!ousrvr!ousrvr![e-mail]  (Ari Husa OH8NUP)
Subject: DX Cluster protocol?
To: [e-mail]

TCP/IP packet radio can provide almost everything the "traditional"
AX.25 service can. We now have NNTP going with NOS; UNIX systems
speaking TCP/IP can offer various multi-user chat programs (like
CONVERS node); and NOS is now successfully stepping on the toes of the
PAU's by mimicing the traditional store & forward BBS..

.. however, there is one service that we don't have yet, namely the DX
Cluster - or similar - for TCP/IP. I've been thinking about a simple
service where the user connects a certain telnet port for the goodies.
Maybe a simple server-client -relationship, even? In a small scale,
this seems to be sufficient. Yet it would be a great advantage if this
program could talk with the existing DX Clusters and exchange
information.

So, is the description of the protocol available in public domain?

Does someone have spare documentation of the Cluster system so we
could have some idea of the desired features?

    Luru
--
    ///
    o-o    Ham Radio Operators Do It In Higher Frequency
     o

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

Date: 30 Dec 90 23:51:04 GMT
From: envy![e-mail]  (Phil R. Karn)
Subject: DX Cluster protocol?
To: [e-mail]

In article <[e-mail]> [e-mail] (Ari Husa OH8NUP) writes:
>TCP/IP packet radio can provide almost everything the "traditional"
>AX.25 service can.
>.. however, there is one service that we don't have yet, namely the DX
>Cluster - or similar - for TCP/IP.

Gak. There's a very good reason this hasn't been done. No, it's not
because I'm not a DXer.

The DX Cluster program is an outrageous abuse of the AX.25 protocol,
pure and simple.  Connected-mode AX.25 (and TCP) are protocols
specifically intended for point-to-point communications.  It is a
scandalous waste of spectrum to use them to implement a broadcast
function over a broadcast channel by sending N copies of the same
information to N different destination stations when they all could
have easily shared a single undirected transmission.

As soon as somebody designs and writes a DX Cluster program that uses
a reasonable protocol specifically designed for broadcasting, I would
be happy to add it to NOS. The NK6K/K8KA Pacsat Broadcast Protocol is
probably a good place to start. I would enhance their protocol by
adding some parity packets (probably using a Reed-Solomon code) so
that a few missing data packets could be reconstructed by the receiver
without requiring the brute-force repetition of every data packet by
the transmitter.

Phil

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

Date: 31 Dec 90 06:03:57 GMT
From: zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!news.funet.fi!ousrvr!ousrvr![e-mail]  (Ari Husa OH8NUP)
Subject: DX Cluster protocol?
To: [e-mail]

In article <[e-mail]> karn@envy..bellcore.com (Phil R. Karn) writes:

> >Cluster - or similar - for TCP/IP.

> The DX Cluster program is an outrageous abuse of the AX.25 protocol,
> scandalous waste of spectrum to use them to implement a broadcast
> function over a broadcast channel by sending N copies of the same
> information to N different destination stations when they all could
> have easily shared a single undirected transmission.

I had in mind something like a simple 'dx server' to my U*IX machine
(hopefully soon to be connected with the packet network), where the
user (client?) connects by 'telnet mymachine somenumber' and then uses
the connection to acquire desired dx information. Wasteful or not -
but there is a great need for this kind of service. Some of the local
guys have been talking about putting up a cluster - I just hate to
hear them say 'A-ha! your fancy tcp/ip can't do it!' ;-)

The idea of being able to talk with the regular clusters around would
add for its usefulness greatly. I might even use it myself (now who
said anything of packet people not being dx-hearted? ;-)...

The need for a roundtable chat program gets a similar solution as soon
as I can get the machine connected. Fortunately, there are several
around already.

> a reasonable protocol specifically designed for broadcasting, I would

Sounds like something not for the 'appliance computer geeks' like
myself. I can hardly picture myself trying to hack together a
reasonably working dx database - establishing or modifying a Real
Protocol is a little bit out of my hands at the moment. Could be
interesting though - maybe even credited in my studies, who knows..

Oh, almost forgot.. how'about the transverter we were talking some
time ago? Is it still lying around? Found out about the postage?

Happy new year,

    Luru
--
    ///
    o-o    Ham Radio Operators Do It In Higher Frequency
     o

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

End of Packet-Radio Digest
******************************
Date: Mon, 31 Dec 90 16:20:59 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #235
To: packet-radio


Packet-Radio Digest         Mon, 31 Dec 90       Volume 90 : Issue 235

Today's Topics:
             DX Cluster protocol?
       Wanted: Software for Packet-Radio running under Windows

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

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

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

Date: 31 Dec 90 16:30:40 GMT
From: ogicse!emory!wa4mei!ke4zv![e-mail]  (Gary Coffman)
Subject: DX Cluster protocol?
To: [e-mail]

In article <[e-mail]> [e-mail] (Phil R. Karn) writes:
>In article <[e-mail]> [e-mail] (Ari Husa OH8NUP) writes:
>>TCP/IP packet radio can provide almost everything the "traditional"
>>AX.25 service can.
>>.. however, there is one service that we don't have yet, namely the DX
>>Cluster - or similar - for TCP/IP.
>
>Gak. There's a very good reason this hasn't been done. No, it's not
>because I'm not a DXer.
>
>The DX Cluster program is an outrageous abuse of the AX.25 protocol,
>pure and simple.  Connected-mode AX.25 (and TCP) are protocols
>specifically intended for point-to-point communications.  It is a
>scandalous waste of spectrum to use them to implement a broadcast
>function over a broadcast channel by sending N copies of the same
>information to N different destination stations when they all could
>have easily shared a single undirected transmission.
>
>As soon as somebody designs and writes a DX Cluster program that uses
>a reasonable protocol specifically designed for broadcasting, I would
>be happy to add it to NOS. The NK6K/K8KA Pacsat Broadcast Protocol is
>probably a good place to start. I would enhance their protocol by
>adding some parity packets (probably using a Reed-Solomon code) so
>that a few missing data packets could be reconstructed by the receiver
>without requiring the brute-force repetition of every data packet by
>the transmitter.
>
>Phil

You're absolutely right...this is a "good thing" ...etc, etc, etc.
However, many, many users of the DX clusters are not on a "broadcast"
channel with the cluster. They are frequently one, two, or even three
Netrom or digipeater (shudder) hops away. The realities of level 1
connectivity in most places outside the most concentrated urban jungles
necessitates named routes for users. Several users may lie along a
particular route, but there still must be at least one ARQ node terminating
each route for the "broadcast" to be sucessful on our lossey networks.
Do we need better level 1? Sure. Are we likely to get a true CSMA/CD
enviornment, given terrain, our physical seperation, and finances?
No. So perhaps we should be thinking of protocols that maximize the
effectiveness of our real networks rather than trying to force fit
protocols onto a level 1 map that doesn't offer all the features we'd
like. I know that this is heresy, but ham radio networks are different
than ethernet and are unlikely to ever be like ethernet except in very
special cases. I don't know what that wonder protocol looks like, but
the sparse nature of our networks and their poor thruput indicate to
me that the protocol won't look anything like a wireline "broadcast"
protocol.

Gary KE4ZV

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

Date: 31 Dec 90 18:45:53 GMT
From: bu.edu!snorkelwacker.mit.edu!ira.uka.de!iras8![e-mail]  (Wolfgang Tremmel)
Subject: Wanted: Software for Packet-Radio running under Windows
To: [e-mail]

Hi!
Is there any Software for Packet-Radio running under Windows (I know every
DOS-Application can run under Windows, but this is not what I am looking for).

Please tell me where I can ftp it from.


Wolfgang DC3UV

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

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