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

Text File | 1993-12-31 | 282.0 KB | 6,671 lines

Sun,  1 Jul 90 04:30:06 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #72
To: packet-radio


Packet-Radio Digest         Sun,  1 Jul 90       Volume 90 : Issue  72

Today's Topics:
               Interested in packet...

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests 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".
----------------------------------------------------------------------

Date: Sat, 30 Jun 90 20:26:35 -0700
From: Doug Faunt N6TQS 415-688-8269 <[e-mail]>
Subject: Interested in packet...
To: [e-mail]

What radios does the K9NG 9600 seem to work OK with?
Is the list for the G3RUH 9600 different?
What characteristics of the radio are necessary?

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

End of Packet-Radio Digest
******************************
Date: Mon,  2 Jul 90 04:30:05 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #73
To: packet-radio


Packet-Radio Digest         Mon,  2 Jul 90       Volume 90 : Issue  73

Today's Topics:
               Interested in packet...

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests 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".
----------------------------------------------------------------------

Date: 1 Jul 90 13:58:07 GMT
From: zaphod.mps.ohio-state.edu!swrinde!emory!emcard!wa4mei!ke4zv![e-mail]  (Gary Coffman)
Subject: Interested in packet...
To: [e-mail]

In article <[e-mail]> [e-mail] (Brian Kantor) writes:
>
>The G3RUH is a similar design except that it is full duplex and has a
>compensation circuit on it that is designed to compensate for both the
>transmitter AND receiver, which implies that a homogeneous network is
>required.  In practice, that isn't quite true; it will work with several
>different kinds of radios in the system.  Many people use the G3RUH for
>medium-speed satellite work.
>
One additional note on the G3RUH design, it uses PSK rather than FSK
and uses less bandwidth while having a better signal to noise ratio.
I have interfaced a pair of these to GE MASTR UHF handhelds with good
results. I tried hooking them up to Icom and Kenwood HTs with poor
results. Apparantly the PLL loop filters in these rigs aren't happy
with the waveform produced by the modem. Best advice, use a crystal
controlled rig.

Gary KE4ZV

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

End of Packet-Radio Digest
******************************
Date: Tue,  3 Jul 90 04:30:02 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #74
To: packet-radio


Packet-Radio Digest         Tue,  3 Jul 90       Volume 90 : Issue  74

Today's Topics:
            Network Models (long) (3 msgs)
                Packet for CAP
               Packet Software
             SCSI Support For NET
         Turbo C++, anyone else tried to compile NOS
             Usenet News Feed on Packet?
          Wanted: Info on High Speed Packet

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests 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".
----------------------------------------------------------------------

Date: 2 Jul 90 08:23:04 GMT
From: mcsun!ukc!axion!galadriel![e-mail]  (Robin Gape)
Subject: Network Models (long)
To: [e-mail]



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

Date: 28 Jun 90 19:13:26 GMT
From: zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!grian!puffin!wd6ehr.ampr.org![e-mail]
Subject: Network models (long)
To: [e-mail]

>
> [e-mail] (Mike Curtis, ax.25 wd6ehr@k6iyk [phone]) writes:

> >In article <[e-mail]> [e-mail] (Bill Meahan) writes:
> >>In article <[e-mail]> [e-mail] (Gary Coffman) writes:
> >>>In article <[e-mail]> [e-mail] (Bill
> >>>Meahan) writes:

> >Whatever happened to our tradition  of building, fixing, and modifying?
> >I suppose it's gone the way of the dodo, and the work ethic........
> >Everyone wants something for nothing, right now.

> >73, Mike wd6ehr@k6iyk

> What does buying a Taiwanese XT clone and downloading Phil's gift wrapped
> software have to do with building, fixing, and modifying?  That is just as
> much appliance operating as an Icom, a microphone, and a triband beam.

You've entirely missed (ignored?) my point.  The bitty-boxboys are
carping that OTHERS are not supporting their machines with state of
the art software.  As Phil Karn said in a reply to your posting, the
source code is available to them.  If they want full-blown NOS on a C-64,
TI99-4, or T/S 1000, implement the amateur tradition of building, fixing,
and modifying (as mentioned above) and _do_ it, just as the Germans have
done with DIGICOM.  But PLEEZE stop crying about it.

This is vaguely reminiscent of the CBers that wouldn't sit down long
enough with a Farnsworth tape to learn CW, so they griped and moaned
until the FCC et al instituted a no-code license.  Now they'll bellyache
about the ferschluginner theory test being too hard, good buddy, until
they get rid of it, too.  Perhaps they'll also get rid of our frequencies
and leave us with 26.965-27.405, and a couple of slots above 450?  UPS
would love that-:)

I suppose what I'm trying to say is "talk is cheap".  Or "If you want
something done, do it yourself".

> The holy wars have moved to packet so soon?  The only place with any peace is
> CW, abuse in morse is such hard work.
>
yup - no Commode-odors there......
(Actually, I think the C-64 is a nice little machine, and there are
some rather impressive things written in 6809 machine code for it.....)

> --
>  Richard Loken VE6BSV                             :  see I took it out!
>  Athabasca University                             :  I can't afford Campy
>  Athabasca, Alberta Canada                        :  anyhow.
>  [e-mail]        {alberta|decwrl}!atha!tech :

73, Mike Curtis

ax.25/ip [e-mail]
uucp wd6ehr@puffin

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

Date: 2 Jul 90 21:58:44 GMT
From: sdd.hp.com!elroy.jpl.nasa.gov!grian!puffin!wd6ehr.ampr.org![e-mail]
Subject: Network Models (long)
To: [e-mail]

> >From article <[e-mail]>, by karn@envy..bellcore.com (Phil R. Karn):
> > In article <[e-mail]> [e-mail] (Richard Loken) writes:
> >>What does buying a Taiwanese XT clone and downloading Phil's gift wrapped
> >>software have to do with building, fixing, and modifying?  That is just as
 >>>much appliance operating as an Icom, a microphone, and a triband beam.
> >>
> >
> > There's one important difference: I provide full source code, so if
> > you're interested you can go into the code, take it apart, figure out
> > how it works, add new features, change those you don't like, etc.
> > Software hacking is as much a form of homebrewing as building hardware.
> >
> > Phil

> And in case anyone had missed the point you can hack the Icom, the
> microphone _and_ the triband beam if you've a mind so to do. These days
> I don't often have the time to hack hardware or software but that of
> itself wouldn't, and shouldn't, stop anyone coming on the air and using
> other people's efforts.>

The point I tried to make is that the bitty boxboys can hack their own
tcp/ip, just like Phil ka9q hacked his for HIS machine, and Rob pe1chl hacked
it for HIS machine, etc.

BOTTOM LINE: We don't care what computer you use on NET!  If you want to run
an opamp-analog computer - FINE!!!  YOU write the code for it!  If you're
a starving student, or??, it's not Phil's problem, is it?  Perhaps you could
do your masters thesis on hacking a split-screen, color NOS for a T/S 1000?
>
> You might add that to get Phil's software actually working requires
> rather a lot of hacking in itself, but that's another story!
Yup - If you try to run defaults here in L.A., you might as well turn
your rig off - it'll work about as well....
>


              73, Mike Curtis

  ____________________________________________________________________________
 | [e-mail]                | "I  didn't invent the talking machine- |
 | packet wd6ehr@k6iyk.#socal.ca.usa | God did.  I just  made the  first  one |
 |                                   | that can be turned off." (-;           |
 | 7921 Wilkinson Avenue             | -Thomas Edison, following several long |
 | North Hollywood CA 91605-2210     | speeches at a banquet in honor of  his |
 | [phone]                    | invention of the phonograph.           |
 |___________________________________|________________________________________|

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

Date: 2 Jul 90 17:15:28 GMT
From: noose.ecn.purdue.edu!newton.physics.purdue.edu!maxwell.physics.purdue.edu![e-mail]  (Bill C. Riemers)
Subject: Packet for CAP
To: [e-mail]

Hello, I'm looking for a sources for a packet modem.  I will be setting up
a CoCo III to interphase with packet at probably 1200 baud.  Currently, Indiana
CAP at considerable expense is setting up all our repeaters to operate with
packet.  However this money will be waisted, if no one is using packet.  I
would apprieciate any references on where an inexpensive packet modem can
be abtained for 2M communications.

Thankyou in advance.

Bill C. Riemers 1Lt/CAP

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

Date: 2 Jul 90 13:31:13 GMT
From: unhd!psc90![e-mail]  (Laurianne Olcott)
Subject: Packet Software
To: [e-mail]

Hi,

This fall I will be setting up a packet-radio-BBS at Plymouth State College
on a PC and am wondering what type of software is available for PC's and
the different networks that I can tie into etc... I am a newcomer to all
this so all the help and advice you can give me right now would be more
than appreciated.  I am primarily interested in the pros and cons of different
types of software packages, and where I can obtain them.
                Thanks,

                    -Laurianne-

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

Date: 2 Jul 90 13:43:01 GMT
From: wang!tegra![e-mail]  (Johnathan Vail)
Subject: SCSI Support For NET
To: [e-mail]

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

   I'm planning to build a SCSI card for my computer, and since everyone is
   talking SCSI, perhaps someone would enlight me on selecting the right
   SCSI chip to use.  I have Fujitsu MB87030, National Semi 5380 and
   8490 spec sheets but I wonder which to use.  I know that the 8490 and MB87030
   can handle to up 4Mbytes/sec transfer, but which chip is easier to program
   and which is easier to interface to differential SCSI bus.

I am involved with using the Am33C93 SCSI bus interface chip.  It is a
newer design and seems to be very complete and easy to use.
Internally it is an 8 bit micro.  It supports DMA and has regular bus
driver built in.  Works both target and host mode and will run up to 5
Mb/s.

If you are starting a fresh design check this one out before deciding.
The spec sheet I have is AMD, I don't know who else makes it.

"Like a clock, they sent, through, a washing machine:
 come around, make it soon, so alone." -- Syd Barrett
 _____
|     | Johnathan Vail | [e-mail]
|Tegra| [phone] | N1DXG@448.625-(WorldNet)
 -----  [e-mail] {...sun!sunne ..uunet}!tegra!vail

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

Date: 3 Jul 90 00:02:09 GMT
From: bacchus.pa.dec.com!leftlane.ucs.dec.com![e-mail]  (Mark Curtis)
Subject: Turbo C++, anyone else tried to compile NOS
To: [e-mail]

Has anyone else tried to compile NOS for the PC with Turbo C++?
Doesn't work.  Did with TC 2.0, but after looking at what C++
complains about I wonder how it did.

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

Date: 3 Jul 90 00:24:31 GMT
From: portal!cup.portal.com![e-mail]  (Robert Jules Shaughnessy)
Subject: Usenet News Feed on Packet?
To: [e-mail]

     I am not a Ham and have never used packet, but I would be very interested
in becoming one, if I could get a full Usenet News feed from Packet. Is this
possible and relatively easy to do? (4 meg a night costs $$$$)


Thanks for your time.

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

Date: 2 Jul 90 20:24:22 GMT
From: hayes.fai.alaska.edu!accuvax.nwu.edu!laue![e-mail]  (John Quintana)
Subject: Wanted: Info on High Speed Packet
To: [e-mail]

I have been in contact with various people in the computer networking
group here at Northwestern.  Several of them are extremely interested
in experimenting with packet radio to tie into the local ethernet
on campus using TCP/IP.  We envision that 1200 or 2400 baud options
are too limiting and would like to investigate setups that run at
56 Kbaud.  Since we would have to purchase all of the equipment
anyway, including transceivers, we would like to get the fastest
setup possible.  We envision a star network topology where the
campus station would act as a hub for experimental home stations.
All of the remote stations would be within about 10 miles of the
campus station.  The antenna for the campus station would be on the
top of a 5 story building.   University adminstrators have expressed
support for this endeavor and would be willing to fund a few pilot
stations to see if this works.  So, I have two questions:

1) Does anyone have experience with high speed set ups, and if you
   do, could you let us know what you are running?
2) We have to get the non-Hams licensed, probably with the Communicator
   no-code class to get started.  Is the Communcator class in effect
   yet?  I understand that the written test for this class consists
   of the Novice and Technician Class tests.  Is this correct?



Please mail responses to [e-mail]

73
- John Quintana    KB9BJK

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

Date: (null)
From: (null)
Patty,

the point that I was trying to make is that there is scope for hacking,
in the sense of understanding (or not) and changing things, in most
things that are part of Amateur Radio. What you describe is _competent_
hacking, as opposed to the other sort.

If you hadn't known what to do, it would have been a riddle.

Robin

P.S. It's an ST, but it's not operational yet, and that's another story!

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

End of Packet-Radio Digest
******************************
Date: Wed,  4 Jul 90 04:30:02 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #75
To: packet-radio


Packet-Radio Digest         Wed,  4 Jul 90       Volume 90 : Issue  75

Today's Topics:
         Cross band tcp/ip conectivity, suggestions?
       G3RUH Modem(s) (Was: "Interested in packet...")
               Interested in packet...
        KA9Q package for the Atari ST (2 msgs)
            Network Models (long)
        NOS -> domain.txt -> maps : A proposal
              NOS via Eagle PC = lockup?
             Usenet News Feed on Packet?
          Wanted: Info on High Speed Packet
            Yeasu ft 727 -> packet tiny-2

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests 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".
----------------------------------------------------------------------

Date: 3 Jul 90 19:28:35 GMT
From: rochester!rit!cci632![e-mail]  (Just another hired gun (n2hkd))
Subject: Cross band tcp/ip conectivity, suggestions?
To: [e-mail]

At present there is no 220 usr packet in this area. What I'd like to
do is use my contest 220 gear and cross link it to the 145.05 freq
we're using for tcpip. Is there a way to do it easily by
using two TNCs and two radios? Will NOS send packets out on
both attach'ed devices so that the same packets are availble
on both bands (let the 220 connect to the BBS on 145.05).
I thougth about add route default ax0 ax1?

Would it be easier just to connect the radios to the same TNC via
the audio (more apt for collisons though).

Has anyone done this (without running a BBS software would be
prefered).????

Allowing for the new priveleges is easy, but making it work
means a lot more.
--

email:   cb@cci632  or !rochester!kodak!n2hkd!curtis
Curtis Braun, N2HKD, Computronics, PO Box 1002 Fairport NY, 14450

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

Date: Tue, 3 Jul 90 10:55:18 EDT
From: [e-mail] (Barry McLarnon DGBT/DIP)
Subject: G3RUH Modem(s) (Was: "Interested in packet...")
To: [e-mail]

>>The G3RUH is a similar design except that it is full duplex and has a
>>compensation circuit on it that is designed to compensate for both the
>>transmitter AND receiver, which implies that a homogeneous network is
>>required.  In practice, that isn't quite true; it will work with several
>>different kinds of radios in the system.  Many people use the G3RUH for
>>medium-speed satellite work.
>>
>One additional note on the G3RUH design, it uses PSK rather than FSK
>and uses less bandwidth while having a better signal to noise ratio.
>I have interfaced a pair of these to GE MASTR UHF handhelds with good
>results. I tried hooking them up to Icom and Kenwood HTs with poor
>results. Apparantly the PLL loop filters in these rigs aren't happy
>with the waveform produced by the modem. Best advice, use a crystal
>controlled rig.

Say what?  The G3RUH 9600 bps modem is most definitely FSK, not PSK.
Perhaps you're thinking of the G3RUH 1200 bps PSK modem, which is an
entirely different breed of cat.  Given radios with decent filters,
I would not expect to see any significant performance difference
between the G3RUH 9600 bps and K9NG designs.  IMHO, the K9NG modem
offers more bang/buck... but both of them pale when compared with the
WA4DSY 56 kbs modem.

>Gary KE4ZV

Barry VE3JF

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

Date: Tue, 3 Jul 90 12:20:00 -0700
From: Doug Faunt N6TQS 415-688-8269 <[e-mail]>
Subject: Interested in packet...
To: [e-mail]

I got several back issues of the "Oscar Satellite Report", which is
the substitute for the AMSAT newsletter, and there's a report of
hooking up G3RUH 9600bps modems to many current rigs successfully, so
maybe crystal control is not necessary.  Since apparently the two
packet uSats use FM up on 2M and down on 70cm, at 9600bps, it appears
that a dual-band FM rig, G3RUH modem, TNC, computer, and dual-band
antenna omni-directional antenna (like two Jpoles) should be enough
for satellite packet communication.  Sounds like the low end for
satellite work is getting lower.

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

Date: 2 Jul 90 23:41:19 GMT
From: crash!simpact!hamavnet![e-mail]
Subject: KA9Q package for the Atari ST
To: [e-mail]

Hello there,

I managed to get a hold of the KA9Q package for the Atari ST. It took quite a
bit of looking and asking, until a kind sould in Europe uucp'd me the files.

If someone would like a copy of the files, I'd be happy to uucp them to you.

Javier Henderson     | [e-mail]           | These opinions
Engineering Services | Ham Packet: N6VBG @ KD7XG-1      | are all mine.
Hamilton Avnet       | WWIVNet: 1@2397                  |

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

Date: 3 Jul 90 18:16:30 GMT
From: psuvm![e-mail]
Subject: KA9Q package for the Atari ST
To: [e-mail]

In article <[e-mail]>, [e-mail] says:
>
>Hello there,
>
>I managed to get a hold of the KA9Q package for the Atari ST. It took quite a
>bit of looking and asking, until a kind sould in Europe uucp'd me the files.
>
>If someone would like a copy of the files, I'd be happy to uucp them to you.

The files for KA9Q are also on terminator.cc.umich.edu for annonomous ftp under
the /atari/telecomm directory.  Thought you would like to know.  :-)

Babs Silvas

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

Date: 3 Jul 90 20:11:31 GMT
From: [e-mail]  (Patty Winter)
Subject: Network Models (long)
To: [e-mail]

Robin wrote:
>You might add that to get Phil's software actually working requires
>rather a lot of hacking in itself, but that's another story!

Then I wrote:
> Could you elaborate on that? When I first used the KA9Q package, all
> I had to do was add my personal information (callsign, IP address, etc.)
> to the NET and BM startup files, toss a few lines into the ftpusers
> file, and and make sure I had the latest hosts.net list for this area.

And then Robin wrote:
>the point that I was trying to make is that there is scope for hacking,
>in the sense of understanding (or not) and changing things, in most
>things that are part of Amateur Radio. What you describe is _competent_
>hacking, as opposed to the other sort.


Hi, Robin.

I guess this is just a semantic difference. When I hear "hacking,"
I think of "writing code." To me, having to type a few things into
some setup files is the same thing as typing a few things into the
RAM of a TNC. It's just like setting up a modem program, where you
need to indicate the phone number you want dialed, what baud rate
you'll be using, perhaps your login ID, etc.

I just didn't want newcomers to get the impression that there was
any programming required to get Phil's software up and running. The
applications are fully executable, and only require some entries in
a few configuration text files.


Patty

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

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

Date: 3 Jul 90 19:20:02 GMT
From: rochester!rit!cci632![e-mail]  (Just another hired gun (n2hkd))
Subject: NOS -> domain.txt -> maps : A proposal
To: [e-mail]

I have a proposal for an idea. I'm sure that there are LOT's of execptions
for the way this might work, but I thought I'd give it shot.

IMHO: I get lost easily and without the domain.txt file so does tcpip.
Even with a prepared map it seems that I still get lost and don't
know where to go with my packets. In this area we're pretty far behind
many other areas, but we're trying to catch up. When I look at the
domain maps for the hard wire servicess they do seem to make a little
more sense, at least as far as subnets go for an area of tcpip address.

The idea:
Assign ip address based on state, area, city idea. Germany uses
a zip code number system that you can figure out where you letter
is goinf just by the zipcode (and you don't have to look it up in
a computer). [44] is pretty much where we start. Let's make the
next entry state/area or area/state. Then let the next are be the
city, then finally the user. This would give us an address:
[44.69.0.3] or n2hkd.ROC.WNY.AMPRORG. I know that some of these
things have been discussed before, but I thougth maybe it deserves
to be discussed again.
If the area/city were to use the Standard Airport codes then it
would be easy to mail stuff (by air or wire, etc). We then might
not need to worry too much about area/state.
Therefore the above address would look like n2hkd.ROC.ampr.org and
would allow for the address subnet to be 44.69.x.x.

Part two: How to find people and maps.
Lets then assign a domain info machine address. Ie. RFCARC BBS running
MSYS. let it be the keeper of the complete domain info.
Let one machine keep the maps for an area in /public/area.map.
And let this one machine have a specific subnet adress. IE x.x.0.1,
and have it keep the subnet map x.x.Z.x.
This way I could go to any area and look/connect to x.x.0.1 and
I would be able to find out where all x.x.Z.x area maps were.
I could then log onto x.x.Z.1 and get the area map for that subnet
and know who I can contact via the domain.txt file.

Lets take an example. I go visit Mom and Dad on LI NY for a week
and I take my portable. I can listen for some traffice and then find my
way to 44.68.0.1 or 44.68.Z.1. I then can find my college buddy
and get his IP addrss and sen him mail (even though I don't have his
ip address before hand) so that we can get together. Mail forwarding
would work easily too. the packets fro routing can be
screened by the router for [44.69], very easily to go to the next
router. This would work for land service interconnects too!

If I could net rom my way through the (ie) Neda backbone, I could then
also figure out my paths via this hunt and peck routine :-).

The good news would be that the area domain directors would only have
to mantain one area for addresses and could then download and build
real maps for our selfs. As it stands right now I find it difficult
at best to find others who have an interest and maybe even an IP
address in this area , but we are new to this...

The next problem for us is how do get off this island? anybody
got a bridge to other tcp/ip users from upstate NY?
If anyone who reads this is interested in connectivity to you
lan so we can wan :-) we'd love to hear from you. thanks

Thanks for listening.... any comments?

--

email:   cb@cci632  or !rochester!kodak!n2hkd!curtis
Curtis Braun, N2HKD, Computronics, PO Box 1002 Fairport NY, 14450

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

Date: 3 Jul 90 18:43:17 GMT
From: rochester!rit!cci632![e-mail]  (Just another hired gun (n2hkd))
Subject: NOS via Eagle PC = lockup?
To: [e-mail]

Hello everyone in Netland. I have small problem with my Eagle PC clone.
When I run nos (g1emm v900612) [or nos from DRSI or net] My pc locks
up and dies. I put the same software on my AT clone and It works fine.
It seems that there's a memory problem, sometimes I get a garbage
collection message? It seems to be ok until it receives (via trace also)
packets. I thougth it was the DRSI driver (it locks up real fast), but it
also seems to have aproblem runing slip.

The computer: intel 8086-8 processor, 512 on board, to 640 on sixpack.
2 serial ports, adaptec RLL controller, 1.2M and 360K floppy,
Wilkinson bios, monchrome adapter and screen, real time clock chip.
running DOS ver3.3 Currently disabled: ems card .5meg with drver uninstalled.

Any ideas would be appreaciated. I really don't want to run NOS
for packety radio on my AT
since it's my primary workstation (uucp,sco,vga,etc).
Thanks.
--

email:   cb@cci632  or !rochester!kodak!n2hkd!curtis
Curtis Braun, N2HKD, Computronics, PO Box 1002 Fairport NY, 14450

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

Date: 4 Jul 90 06:50:28 GMT
From: bionet!ucselx!crash![e-mail]  (Skip Sanders)
Subject: Usenet News Feed on Packet?
To: [e-mail]

Feeding USENET by ham radio is technically possible (though difficult), but
is TOTALLY ILLEGAL, due to the commercial nature of many USENET messages
and the fact that regulations require a ham to screen ALL messages BEFORE
they are transmitted to ensure no illegal traffic is sent, which would be
a bit hard to do, unless you're a REAL speed reader.
Bear in mind that international agreements that allow ham radio are created
by governments, many of whom run government monopolies on telecommunications,
and as such, prohibit ANY use of ham radio that "bypasses" phone or radio
common carrier service, or is in any way involving the normal business of
any person or business.

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

Date: 3 Jul 90 20:29:52 GMT
From: hpl-opus!hpnmdla![e-mail]  (Glenn Elmore)
Subject: Wanted: Info on High Speed Packet
To: [e-mail]

John

Your reply path didn't work for me so I'll try replying here.
  I thought I would let you know
that there is indeed some work going on toward higher speed networking.
Here in northern California a number of us are working hard to get a
prototype 250Kbaud network in place.  This is using clusters of "hub
served" local users ( a small number) all tied together with point-point
backbones made from either similar 250-500 kbaud "user" radios (we are
bankrolling this ourselves and have finite resources (:>) ) or microwave
hardware.  A description of some of our initial mega-bps microwave hardware
was in the December 1989 issue of Ham Radio magazine.  The next version of
backbone hardware will actually be done differently but this should give
you some idea of what it may look like.
   A prototype 250Kbaud radio is described in a recent Gateway/QEX
note (sorry, I forget the month  but it was this spring). The first
12-15 radios are on 904 and 916 MHz and run about 10 watts output
into a 2 MHz digital channel. I hope to have another "batch" of these
completed for the 1200 MHz band before too long.

    Along with the radio hardware, we are working on some shared memory
i/o hardware to switch/route several streams of higher rate data.  Along
with the hardware we are also developing link layer protocols for these
cells with the end goal to provide layer3-to-the-user services everywhere
in the network.

  If you haven't already, you may want to look at the last couple of
years of ARRL computer networking conference(CNC) proceedings.  Last year
several of us, Mike Chepponis, Phil Karn, Bdale Garbee, Kevin Rowett and
myself, did an article on the implications of high speed networking for
amateur radio.

Hope this is of interest.


Glenn Elmore -N6GN-

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

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

Date: 3 Jul 90 18:46:00 GMT
From: rochester!rit!cci632![e-mail]  (Just another hired gun (n2hkd))
Subject: Yeasu ft 727 -> packet tiny-2
To: [e-mail]

OK beat me with stick (spoon or whatever), I deserve it. I know
that this wiring diagram has been posted before, but I couldn't
find it anywhere. Could some kind soul email me a copy. thanks.
--

email:   cb@cci632  or !rochester!kodak!n2hkd!curtis
Curtis Braun, N2HKD, Computronics, PO Box 1002 Fairport NY, 14450

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

End of Packet-Radio Digest
******************************
Date: Thu,  5 Jul 90 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #76
To: packet-radio


Packet-Radio Digest         Thu,  5 Jul 90       Volume 90 : Issue  76

Today's Topics:
        NOS -> domain.txt -> maps : A proposal

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests 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".
----------------------------------------------------------------------

Date: 4 Jul 90 15:44:25 GMT
From: [e-mail]  (Brian Kantor)
Subject: NOS -> domain.txt -> maps : A proposal
To: [e-mail]

I had some difficulty understanding the proposal (perhaps the writer's
native language is other than English?), but I think he's suggesting
geographic subdomains of the amprnet namespace as a means to facilitate
routing.  Again.

Instead of replaying the same arguments over and over and over again,
I'll just say that such a scheme has many disadvantages and very few
advantages, and reflects a complete confusion on the part of the
proposer among the differences in routes, addresses, and hostnames.

For a review of this recurring proposal and discussion, please browse
through the packet-radio and tcp-digest archives located on host
ucsd.edu, available by anonymous ftp.  If you don't have ftp capability,
perhaps someone can fetch them for you.
    - Brian

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

End of Packet-Radio Digest
******************************
Date: Fri,  6 Jul 90 04:30:04 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #77
To: packet-radio


Packet-Radio Digest         Fri,  6 Jul 90       Volume 90 : Issue  77

Today's Topics:
        KA9Q package for the Atari ST (2 msgs)
               NET for atari ST
              Packet-Radio Digest V1 #76
               Packet Software
              TCP/IP on 6 meters
        Usenet News Feed on Packet? (15 msgs)

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests 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".
----------------------------------------------------------------------

Date: 5 Jul 90 17:18:00 GMT
From: portal!atari![e-mail]  (Mike Nowicki)
Subject: KA9Q package for the Atari ST
To: [e-mail]

In article <[e-mail]> [e-mail] writes:
>In article <[e-mail]>, [e-mail] says:
>>
>>Hello there,
>>
>>I managed to get a hold of the KA9Q package for the Atari ST. It took quite a
>>bit of looking and asking, until a kind sould in Europe uucp'd me the files.
>>
>>If someone would like a copy of the files, I'd be happy to uucp them to you.
>
>The files for KA9Q are also on terminator.cc.umich.edu for annonomous ftp under
>the /atari/telecomm directory.  Thought you would like to know.  :-)
>
>Babs Silvas

  The KA9Q is a ham radio callsign. Armed with that knowledge you could also
have gone to a public library that has a copy of the ARRL ham radio callsign
directory and found his (or her) address and written them directly.

------------------------------------------------------------------------------
|  Michael Nowicki   N6LUU      Atari Corp,Sunnyvale CA     /TT/UNIX/X team  |
|............................................................................|
|  char *disclaimer="  Views expressed are my own, not my employer's";       |
------------------------------------------------------------------------------

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

Date: 6 Jul 90 01:09:00 GMT
From: swrinde!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu![e-mail]
Subject: KA9Q package for the Atari ST
To: [e-mail]

I gathered up a list of the files whose path names had "ka9q" anywhere in
them, from each of the 456 anonymous FTP hosts I have indexed, and extracted
just the list of the hosts.  The full list of files, or the selected files,
are available; e-mail me for info.  Here is the list of just the host names
where I have found "ka9q" files:

allspice.lcs.mit.edu                    pacific.mps.ohio-state.edu
apple.com                               radio.astro.utoronto.ca
bellcore.com                            rusmv1.rus.uni-stuttgart.de
blake.acs.washington.edu                sauna.hut.fi
brazos.rice.edu                         sics.se
bu-it.bu.edu                            slopoke.mlb.semi.harris.com
bu.edu                                  sun.soe.clarkson.edu
citi.umich.edu                          surya.waterloo.edu
clover.ucdavis.edu                      tacky.cs.olemiss.edu
col.hp.com                              terminator.cc.umich.edu
flash.bellcore.com                      trwind.trw.com
ftp.uu.net                              tut.cis.ohio-state.edu
funet.fi                                uc.msc.umn.edu
gatekeeper.dec.com                      ucdavis.ucdavis.edu
hp4nl.nluug.nl                          uhccux.uhcc.hawaii.edu
inria.inria.fr                          unido.informatik.uni-dortmund.de
isy.liu.se                              uunet.uu.net
jyu.fi                                  uxc.cso.uiuc.edu
kolvi.hut.fi                            van-bc.wimsey.bc.ca
kth.se                                  vax.cs.pitt.edu
louie.udel.edu                          vega.hut.fi
miki.cs.titech.ac.jp                    watmath.waterloo.edu
munnari.oz.au                           wuarchive.wustl.edu
nisc.jvnc.net                           xlnvax.excelan.com

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

Date: 5 Jul 90 04:48:32 GMT
From: elroy.jpl.nasa.gov!grian!puffin!wd6ehr.ampr.org![e-mail]  (Mike Curtis, ax.25 wd6ehr@k6iyk [phone])
Subject: NET for atari ST
To: [e-mail]

The latest and greatest pe1chl net/ST and MS-DOS bits are available.
To obtain a copy, send a 720K formatted 3-1/2" disk, mailer, and postage to:

Mike Curtis  wd6ehr@k6iyk
7921 Wilkinson Avenue
North Hollywood CA 91605-2210

I have prepared several additional docs on pe1chl setup, which differs
greatly from standard ka9q net.

The pe1chl net includes end-user multiport netrom, conference bridge,
NetDigi (a cross-port connected-mode digipeater); rcmd (operate your
keyboard remotely); KISS dual-port operation on multiport TNC's like
the KAM, KPC-4, etc., supports the evil DRSI board (PC version - it
actually WORKS!), ax.25 mailbox, and more.

73, Mike wd6ehr
[e-mail]

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

Date: Thu, 5 Jul 90 17:06 N
From: Urs Baer <[e-mail]>
Subject: Packet-Radio Digest V1 #76
To: [e-mail]

please remove my old adress 87674800 from your list.

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

Date: 4 Jul 90 13:55:35 GMT
From: usc!cs.utexas.edu!helps!bongo![e-mail]  (Julian Macassey)
Subject: Packet Software
To: [e-mail]

In article <[e-mail]>, [e-mail] (Laurianne Olcott) writes:
>
> Hi,
>
> This fall I will be setting up a packet-radio-BBS at Plymouth State College
> on a PC and am wondering what type of software is available for PC's and
> the different networks that I can tie into etc... I am a newcomer to all
> this so all the help and advice you can give me right now would be more
> than appreciated.  I am primarily interested in the pros and cons
> of different types of software packages, and where I can obtain
> them.


This is being posted to the net because I have trouble sending mail to
max@.UUCP Please fix. Besides, this may be of interest to others
judging by some of the questions I often see.

You need to get in touch with the local packet community for the
following reasons:

1.      They will have BBS software

2.      They will help you install it

3.      You will need to get feeds from and to other BBS in your area.



You can find packet on:

145.01, 145.03, 145.05, 145.07, 145.09 Mhz. There may also be other
local freqs in use. Ask the locals, they have the answers for your
neck of the woods.

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

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

Date: 5 Jul 90 17:50:24 GMT
From: swrinde!cs.utexas.edu!oakhill!val![e-mail]  (Ben Thornton)
Subject: TCP/IP on 6 meters
To: [e-mail]

   Is there a 6 Meter frequency that is used primarily for TCP/IP
traffic?  I was thinking of crossbanding one of the NET/ROM nodes
in our vicinity and would like to know if anyone has any thoughts
or experiences to relate about this...

Ben
WD5HLS

--
This is MY opinion.  My employer can't have any of it....  So there.
Ben Thornton             packet:  WD5HLS @ KB5PM   Internet:  [e-mail]
Video Associates           uucp:  ...!cs.utexas.edu!val!ben
Austin, TX              fidonet:  1:382/40 - The Antenna Farm BBS

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

Date: 5 Jul 90 04:15:08 GMT
From: crash![e-mail]  (Skip Sanders)
Subject: Usenet News Feed on Packet?
To: [e-mail]

Unless you can get your "software filter" licensed by the FCC as a ham, it
cannot serve as a "control operator" for this purpose.  The FCC states when
this has come up before (usually in regard to phone patches) that ALL TRAFFIC
which will be available "on-air" MUST have been screened FIRST by a LIVE ham.

I doubt anyone is going to take the time to read a "full USENET feed" on a
daily basis...

Further, there is a rule prohibiting use of ham radio to bypass "common carrier"radio services, and if the FCC spots this use, they will "have a cow", in the
current phrase.  They do NOT want ham radio used by non-hams for routine
message traffic, that's what BUSINESS radio services and landline phone
is for.

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

Date: 5 Jul 90 04:09:28 GMT
From: crash![e-mail]  (Skip Sanders)
Subject: Usenet News Feed on Packet?
To: [e-mail]

There is a specific exemtion for INDIVIDUAL hams to list personal gear for
sale, discretely, but they cannot be in the BUSINESS of selling ham gear,
or make it a routine activity.
The FCC "blandly ignores" things like recommending ham gear sources, as long
as the recommender doesn't WORK for the source in question.
Encrypted data of any sort (with an exemption for spread-spectrum modulation
with specified parameters) is prohibited on ham radio (including ROT 13).
Basically, before thinking about doing anything like this link, buy and READ
CAREFULLY the FCC rules for ham radio, "Part 97", and remember that the FCC
will ALWAYS interpret the rules in the most restrictive way where business
or non-ham access to ham transmitters is concerned.  Hams can't even work
with the local PD on things like "Halloween Watch Patrols" according to the
FCC because it's contributing to the "routine business" of the Police Dept.

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

Date: 5 Jul 90 04:24:00 GMT
From: swrinde!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu![e-mail]
Subject: Usenet News Feed on Packet?
To: [e-mail]

>    I was told that possible foul language was a problem, but if I compressed
> or scrambled the data, would that fix this part?
>
>    I did not know comercial messages by someone else would be illeagal. I
> have a scanner and have heard the hams tell they have stuff for sale and
> recommend stores. Could you explain this a little to the Neophyte...

The ham for-sale stuff BY HAMS would be OK.  All the REST of the commercial
stuff would NOT be.

Scrambling it would not make it OK.  That would just make it worse.

As Jim Grubs points out, filtering is needed.  But I am not so sure that
an algorithmic filter would be very good.  I for one don't plan to gate
USENET onto ham radio.

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

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

Date: 4 Jul 90 20:43:07 GMT
From: news!cartan!ndmath!nstar!w8grt![e-mail]  (Jim Grubs)
Subject: Usenet News Feed on Packet?
To: [e-mail]

 > From: [e-mail] (Skip Sanders)
 > Date: 4 Jul 90 06:50:28 GMT
 > Organization: Crash TimeSharing, El Cajon, CA
 > Message-ID: <[e-mail]>
 > Newsgroups: rec.ham-radio.packet
 >
 > Feeding USENET by ham radio is technically possible (though difficult),
 > but
 > is TOTALLY ILLEGAL, due to the commercial nature of many USENET messages

Let's not exaggerate. It is not TOTALLY ILLEGAL. It is illegal only for those
individual messages with commercial content. It shouldn't be too difficult to
write a software filter to toss the questionable ones into a holding area for
review by a carbon based unit.

--
  |\/\/\/|
  |      | Jim Grubs, W8GRT - aka FidoNet node 1:234/1
  | (o)(o) UUCP: {ncar!asuvax!stjhmc!,iuvax!ndmath!nstar}!w8grt!jim.grubs
  |     _) INTERNET: [e-mail]
  | ,___|  ____________________________________________
  |   /     "I wanna go to the ham radio National Park
 /____\          of the Mind and ride the NOS!"

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

Date: 4 Jul 90 20:43:07 GMT
From: news!cartan!ndmath!nstar!w8grt![e-mail]  (Jim Grubs)
Subject: Usenet News Feed on Packet?
To: [e-mail]



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

Date: 4 Jul 90 17:35:03 GMT
From: portal!cup.portal.com![e-mail]  (Robert Jules Shaughnessy)
Subject: Usenet News Feed on Packet?
To: [e-mail]

     I was told that possible foul language was a problem, but if I compressed
or scrambled the data, would that fix this part?

     I did not know comercial messages by someone else would be illeagal. I
have a scanner and have heard the hams tell they have stuff for sale and
recommend stores. Could you explain this a little to the Neophyte...


Thanks for your time.

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

Date: 5 Jul 90 15:59:35 GMT
From: zaphod.mps.ohio-state.edu!usc!cs.utexas.edu!oakhill!val![e-mail]  (Ben Thornton)
Subject: Usenet News Feed on Packet?
To: [e-mail]

[e-mail] (Skip Sanders) writes:

>Further, there is a rule prohibiting use of ham radio to bypass "common carrier"radio services, and if the FCC spots this use, they will "have a cow", in the
>current phrase.  They do NOT want ham radio used by non-hams for routine
>message traffic, that's what BUSINESS radio services and landline phone
>is for.

Hmmm...  I seem to recall a particular incident in the not-too-distant past
where certain NYC Taxicab operators were flagrantly using 10M SSB for their
*commercial* operation.  The FCC field office there seemed to be less than
responsive on this...


--
This is MY opinion.  My employer can't have any of it....  So there.
Ben Thornton             packet:  WD5HLS @ KB5PM   Internet:  [e-mail]
Video Associates           uucp:  ...!cs.utexas.edu!val!ben
Austin, TX              fidonet:  1:382/40 - The Antenna Farm BBS

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

Date: 5 Jul 90 14:31:29 GMT
From: swrinde!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!sunybcs!uhura.cc.rochester.edu!rochester!rit!cci632![e-mail]  ( co-op)
Subject: Usenet News Feed on Packet?
To: [e-mail]

In article <[e-mail]> [e-mail] (Jim Grubs) writes:

> > From: [e-mail] (Skip Sanders)

> > Feeding USENET by ham radio is technically possible (though difficult),
> > but
> > is TOTALLY ILLEGAL, due to the commercial nature of many USENET messages
>
>Let's not exaggerate. It is not TOTALLY ILLEGAL.

No, I agree with Skip that it is illegal, period, without an operator
viewing each message and approving or rejecting it for radio transmission.

There is more involved here than just "commercial" messages and the
seven words.  The ARRL's FCC rule book does a pretty good job of
explaining the law with regard to "relinquishing control" - if you start
forwarding to Usenet, you are doing just that, aren't you?

If you could assure the guy on the other end is a ham, then that ham is
in remote control of your station and it's O.K. but third party traffic
of this sort should be carefully watched by the ham handling it.

My $.02.

--
Christopher E. Piggott, WZ2B                                (ex-N2JGW)
Computer Consoles, Inc. (an STC company)                 Rochester, NY
cs.rochester.edu!cci632!ccird7!cep  or  uunet!ccicpg!cci632!ccird7!cep

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

Date: 5 Jul 90 18:41:25 GMT
From: usc!zaphod.mps.ohio-state.edu!mips!wyse![e-mail]  (Steve Wilson x2580 dept303)
Subject: Usenet News Feed on Packet?
To: [e-mail]

In article <[e-mail]> [e-mail] (Skip Sanders) writes:
>Hams can't even work
>with the local PD on things like "Halloween Watch Patrols" according to the
>FCC because it's contributing to the "routine business" of the Police Dept.

Not so....I think if you look at it closely you'll find that this is ok
if you don't do it 365 days a year.   To grossly paraphrase part 97 on
the subject it says something to the effect that it is OK to help a group
if the primary beneficiary is the public.  The fact that the "sponsor"
(in this case the local PD) might benefit as an incedental to the
communication is not a problem.  The point where you step over the line
is when you do this in a full time manner.  This then would be helping
the PD do their thing in a "business like" fashion due more to the
duration of the operation than from what you where doing.  Please
see the new FCC Rule book put out by ARRL.  They specifically use
a "Goblin patrol" in the discussions of the subject.

73's de Steve KA6S

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

Date: 6 Jul 90 01:01:00 GMT
From: pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu![e-mail]
Subject: Usenet News Feed on Packet?
To: [e-mail]

> Unless you can get your "software filter" licensed by the FCC as a ham, it
> cannot serve as a "control operator" for this purpose.  The FCC states when
> this has come up before (usually in regard to phone patches) that ALL TRAFFIC
> which will be available "on-air" MUST have been screened FIRST by a LIVE ham.

You might be taking something out of context.  There are such things
automatic control, and this is what the software filter is.  The FCC
rules do not literally say "live ham" but rather are defined in legal
terms that do allow automatic things under certain circumstances.
Read what those circumstances are.  Don't just assume that because
something is not legal under some circumstances that it is also not
legal under other circumstances.

> I doubt anyone is going to take the time to read a "full USENET feed" on a
> daily basis...

Most certainly not.

> Further, there is a rule prohibiting use of ham radio to bypass "common
> carrier"radio services, and if the FCC spots this use, they will "have a
> cow", in the current phrase.  They do NOT want ham radio used by non-hams
                                ^^^^^^^^^^^
> for routine message traffic, that's what BUSINESS radio services and
> landline phone is for.

But since we are talking about use by hams, then this particular argument
would not necessarily apply.  These USENET messages would really constitute
third party traffic and the rules that apply to it would apply here.  Just
because the ends are non-hams does not in itself make it illegal; it just
invokes some additional restrictions, which most of USENET cannot adhere to
anyway.  The restrictions are less if the destination is a ham, and this is
more likely what is being considered.

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

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

Date: 5 Jul 90 23:46:46 GMT
From: n8emr![e-mail]  (Gary Sanders)
Subject: Usenet News Feed on Packet?
To: [e-mail]

In article <[e-mail]> [e-mail] (Skip Sanders) writes:
>......
>Encrypted data of any sort (with an exemption for spread-spectrum modulation
>with specified parameters) is prohibited on ham radio (including ROT 13).
>Basically, before thinking about doing anything like this link, buy and READ

Try again Skip...
    Encryption of a message to be sent over amateur bands is
legal as long as your not using the encryption to hide the real
meaning of a message, Encryption/compression is ok if your
just trying to reduce bandwith/time to transmit a file.
This way you can send a .arc or .zip file over the air
with out it being called encryption. This however still
would not permit the orginal author to compress a message
to to clean up the "dirty words"


--
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: 5 Jul 90 18:42:34 GMT
From: zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!sdd.hp.com!elroy.jpl.nasa.gov!turnkey!orchard.la.locus.com!prodnet.la.locus.com!lando.la.locus.com![e-mail]  (Dana H. Myers)
Subject: Usenet News Feed on Packet?
To: [e-mail]

In article <[e-mail]> [e-mail] (Robert Jules Shaughnessy) writes:
>
>     I was told that possible foul language was a problem, but if I compressed
>or scrambled the data, would that fix this part?

  No! You cannot intentionally obscure the meaning of text when using
amateur radio; codes and ciphers are expressly forbidden. On the other
hand, a filter (program) to delete commonly used foul language would be
rather straightforward, probably as part of the inter-domain router.

>     I did not know comercial messages by someone else would be illeagal. I
>have a scanner and have heard the hams tell they have stuff for sale and
>recommend stores. Could you explain this a little to the Neophyte...

  As I understand it, hams are permitted to engage in conversations
pertaining to ham radio. Most packet BBSes are loaded with "IC-761 for sale"
or "TR-2500 for sale or trade" messages. It is legal to sell, buy or even
discuss terms on ham equipment. I suspect this includes any kind of equipment
for amateur use, like "CoCo 3 for sale" (CoCo is a Tandy Color Computer).

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

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

Date: 5 Jul 90 18:37:39 GMT
From: zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!sdd.hp.com!elroy.jpl.nasa.gov!turnkey!orchard.la.locus.com!prodnet.la.locus.com!lando.la.locus.com![e-mail]  (Dana H. Myers)
Subject: Usenet News Feed on Packet?
To: [e-mail]

In article <[e-mail]> [e-mail] (Skip Sanders) writes:
>Feeding USENET by ham radio is technically possible (though difficult), but

  I'm not certain how difficult. I've been told the BM/KA9Q generated
messages aren't exactly RFC822 compliant so something like that, but that
probably isn't terribly difficult to fix on the fly.

>is TOTALLY ILLEGAL, due to the commercial nature of many USENET messages

    TOTALLY ILLEGAL? Hmmm... Almost every message I read on rec.ham-radio
and rec.ham-radio.packet are non-commercial in nature. Even the kind of
messages seen on rec.ham-radio.swap are legal, have you looked at the
bulletin boards in your area lately?

>and the fact that regulations require a ham to screen ALL messages BEFORE
>they are transmitted to ensure no illegal traffic is sent, which would be
>a bit hard to do, unless you're a REAL speed reader.

   How does the automatic forwarding from BBS to BBS work? Does the control
operator have to review all traffic to make sure it is legal? I think not.
Same problem, already solved. The control operator is responsible and
accountable for correct operation of his station. He may choose to read
all traffic before forwarding it, or he may choose to take his chances.

>Bear in mind that international agreements that allow ham radio are created
>by governments, many of whom run government monopolies on telecommunications,
>and as such, prohibit ANY use of ham radio that "bypasses" phone or radio
>common carrier service, or is in any way involving the normal business of
>any person or business.

  Once again, I don't see how this applies to the generally trivial nature
of the rec.ham-radio postings. You couldn't use a inter-domain gateway for
a commercial purpose, but most of us don't use Usenet for commercial
purposes.

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

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

Date: 6 Jul 90 00:59:57 GMT
From: zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!turnkey!orchard.la.locus.com!prodnet.la.locus.com!lando.la.locus.com![e-mail]  (Dana H. Myers)
Subject: Usenet News Feed on Packet?
To: [e-mail]

In article <[e-mail]> [e-mail] (Skip Sanders) writes:
>Unless you can get your "software filter" licensed by the FCC as a ham, it
>cannot serve as a "control operator" for this purpose.  The FCC states when
>this has come up before (usually in regard to phone patches) that ALL TRAFFIC
>which will be available "on-air" MUST have been screened FIRST by a LIVE ham.

   Are YOU for real? The control operator is responsible for the operation
of a station, the software he uses is no more responsible for the operation
of his station than the wall socket the equipment is plugged into.

>I doubt anyone is going to take the time to read a "full USENET feed" on a
>daily basis...

   I agree with this; but I don't think control operators of packet
stations CAN or DO screen all traffic flowing through their station;
what happens if someone is digipeating through my station - do I need
to have MONITOR mode on and turn the TNC off if I see traffic of questionable
nature? Hmmm..... nobody I know does that, so either there are a lot of
criminals out there or you have some interpretation of the rules that is
impractical and not being enforced.

>Further, there is a rule prohibiting use of ham radio to bypass "common carrier"radio services, and if the FCC spots this use, they will "have a cow", in the
>current phrase.  They do NOT want ham radio used by non-hams for routine
>message traffic, that's what BUSINESS radio services and landline phone
>is for.

   Once again, Skip, get with reality. The FCC restrictions have to do
with the content of the traffic. The traffic must be of a trivial enough
nature not to warrant use of a competing commercial service, and the intent
must not be to avoid paying commercial services. This has little to do,
for instance, with making rec.ham-radio.packet available via packet.

  Skip, you very strongly state things without supporting them with
proper quotes. My defense does not quote Part 97; but instead I take
the position "this behavior is common". The assumption is if this
common behavior really was illegal, we'd be hearing more about it.
I do plan to go home and look at my copy of Part 97; I'd appreciate
it if you did also before appointing yourself an expert.
*****************************************************************
* Dana H. Myers KK6JQ           | Views expressed here are      *
* [phone] (ex WA6ZGB)    | mine and do not necessarily   *
* [e-mail]                | reflect those of my employer  *
*****************************************************************

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

Date: 6 Jul 90 00:49:46 GMT
From: zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!turnkey!orchard.la.locus.com!prodnet.la.locus.com!lando.la.locus.com![e-mail]  (Dana H. Myers)
Subject: Usenet News Feed on Packet?
To: [e-mail]

In article <[e-mail]> [e-mail] (Skip Sanders) writes:
>CAREFULLY the FCC rules for ham radio, "Part 97", and remember that the FCC
>will ALWAYS interpret the rules in the most restrictive way where business
>or non-ham access to ham transmitters is concerned.  Hams can't even work
>with the local PD on things like "Halloween Watch Patrols" according to the
>FCC because it's contributing to the "routine business" of the Police Dept.

   Is this for real? I find it very difficult to believe, given that the
Police Departments are not commercial businesses (despite what people say
about them being local revenue generators by writing tickets).

  Part of the charter of amateur radio is public service. I don't see how
the FCC would reasonably dis-allow a public service like "Halloween Watch
Patrols". I'd like to see a specific reference to the edict ruling assistance
to PDs to be illegal.


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

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

End of Packet-Radio Digest
******************************
Date: Sat,  7 Jul 90 04:30:02 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #78
To: packet-radio


Packet-Radio Digest         Sat,  7 Jul 90       Volume 90 : Issue  78

Today's Topics:
         Cross band tcp/ip conectivity, suggestions?
            IMHO ??????? (3 msgs)
            KA9Q/NOS for SCO XENIX wanted
        KA9Q package for the Atari ST (2 msgs)
   Packet callsign servers (Was: Re: KA9Q package for the Atari ST)
         Usenet News Feed on Packet? (2 msgs)

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests 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".
----------------------------------------------------------------------

Date: 6 Jul 90 06:58:20 GMT
From: nisca.ircc.ohio-state.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!grian!puffin!wd6ehr.ampr.org![e-mail]  (Mike Curtis, ax.25 wd6ehr@k6iyk [phone])
Subject: Cross band tcp/ip conectivity, suggestions?
To: [e-mail]

in message <[e-mail]> [e-mail] writes:

> At present there is no 220 usr packet in this area. What I'd like to
> do is use my contest 220 gear and cross link it to the 145.05 freq
> we're using for tcpip. Is there a way to do it easily by
> using two TNCs and two radios? Will NOS send packets out on
> both attach'ed devices so that the same packets are availble
> on both bands (let the 220 connect to the BBS on 145.05).
> I thougth about add route default ax0 ax1?

The pe1chl net for Atari ST and ms-dos supports the Kantronics
KAM and KPC-4 as dual port TNC's.  It also has "NetDigi", end user
netrom, conference bridge, etc., that will work with many ports,
be they kiss, slip, or whatever.  There is also a driver for an
external scc interface.  I have schematics for the Atari ST.
the pe1chl ms-dos version also supports the evil DRSI board, and
actually works for weeks on end, unlike DRSI's net.
>
> Would it be easier just to connect the radios to the same TNC via
> the audio (more apt for collisons though).

Offhand, I think you'll run into problems, although I've not tried it.

I _do_ run 2 TNC's on a single radio, using analog loopback for collision
prevention, and to communicate between the 2 TNC's.  However, that's
quite a different story :-)

If you'd like a copy of the latest and greatest Atari ST or ms-dos pe1chl
net, with extra docs (you'll need them - it differs greatly from ka9q),
send a 720k 3-1/2" diskette with postpaid addressed mailer to:

Mike Curtis  wd6ehr
7921 Wilkinson Avenue
North Hollywood CA 91605-2210

and please note on the disk which version you need.

              73, Mike Curtis
  ____________________________________________________________________________
 | [e-mail]                | "I  didn't invent the talking machine- |
 | packet wd6ehr@k6iyk.#socal.ca.usa | God did.  I just  made the  first  one |
 |                                   | that can be turned off." (-;           |
 | 7921 Wilkinson Avenue             | -Thomas Edison, following several long |
 | North Hollywood CA 91605-2210     | speeches at a banquet in honor of  his |
 | [phone]                    | invention of the phonograph.           |
 |___________________________________|________________________________________|

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

Date: Thu 5 Jul 90 15:07:46-EST
From: [e-mail]
Subject: IMHO ???????
To: [e-mail]

What does IMHO mean?
-------

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

Date: 6 Jul 90 21:39:26 GMT
From: uc!shamash![e-mail]  ( VTC)
Subject: IMHO ???????
To: [e-mail]

In article <[e-mail]> [e-mail] writes:
>What does IMHO mean?
>-------

IMHO  - In my humble opinion
TTFN  - ta ta for now.

Gee, can't think of any other ones right now - can anyone else ?

#include <sig_file_from_hell>
===============================================================================
AMPR: nr0d.ampr.org          44.94.3.12         CIS   : 70436,1410
      at386.nr0d.ampr.org    44.94.3.23         PORTAL: jrc
      slip.nr0d.ampr.org     44.94.3.25         QLINK : jrc1
      brainiac.nr0d.ampr.org 44.94.3.30         GENIE : jrc

INET: [e-mail]   UUCP: umn-cs!bungia!vware!brainiac!jrc
      [e-mail]         umn-cs!kksys!edgar!brainiac!jrc
                    shamash!vtcqa

      N R 0 D  P A C K E T  R A D I O  --  Bloomington, Minnesota USA
===============================================================================

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

Date: 6 Jul 90 22:18:00 GMT
From: swrinde!zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu![e-mail]
Subject: IMHO ???????
To: [e-mail]

FYI - For Your Information
USI - You Stupid Idiot|Imbecile

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

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

Date: 6 Jul 90 17:25:51 GMT
From: swrinde!zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!mailrus!accuvax.nwu.edu!anaxagoras!ils.nwu.edu![e-mail]  (Matt Larson)
Subject: KA9Q/NOS for SCO XENIX wanted
To: [e-mail]

I imagine this question has been asked before -- my apologies to the
rec.ham-radio.packet readers.

I am looking for an SCO XENIX port of Phil Karn's KA9Q, or better yet,
the more recent update, NOS.  I would also settle for -any- UNIX port of
either package.  If anyone has heard anything, please let me know.
Thanks a lot.

Matt Larson

--
Matt Larson                            "I believe in the fundamental
[e-mail]                        interconnectedness of all things"
NU Distributed Systems Services               - Dirk Gently

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

Date: 6 Jul 90 16:12:09 GMT
From: shlump.nac.dec.com!carafe.enet.dec.com![e-mail]  (Fred R. Goldstein)
Subject: KA9Q package for the Atari ST
To: [e-mail]

In article <[e-mail]>, [e-mail] (Mike Nowicki) writes...
>  The KA9Q is a ham radio callsign. Armed with that knowledge you could also
>have gone to a public library that has a copy of the ARRL ham radio callsign
>directory and found his (or her) address and written them directly.

Not a good idea.  KA9Q is Phil Karn's call sign.  He write the
"original" MS-DOS versions of the code.  Other people then write the
variants, such as the Atari version.  Walter Doerr DK2GG (or DG2KK?) did
one of the ST ports; a later one comes from somebody in Holland.  A
better notesfile to ask in might be rec.ham-radio.packet.
---
Fred R. Goldstein   [e-mail]
 k1io            or [e-mail]
            voice:  [phone]

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

Date: 6 Jul 90 13:39:38 GMT
From: hpl-opus!hpnmdla![e-mail]  (Glenn Elmore)
Subject: KA9Q package for the Atari ST
To: [e-mail]

> >The files for KA9Q are also on terminator.cc.umich.edu for annonomous ftp under
> >the /atari/telecomm directory.  Thought you would like to know.  :-)
> >
> >Babs Silvas

 Michael Nowicki   N6LUU      writes:

>
>   The KA9Q is a ham radio callsign. Armed with that knowledge you could also
> have gone to a public library that has a copy of the ARRL ham radio callsign
> directory and found his (or her) address and written them directly.
>
  However, most of the porting of Phil's code to the ST has been done by
amateurs in Europe, DG2KK and recently PE1CHL. Distribution of current
ST code in the US has been a problem, I've mailed out more diskettes than
I would have preferred because of this.

  Not only could you have gone to the library, but in northern California
anyway you could have used tcp/ip to finger the amateur radio database
which n6oyu runs and gotten the information via radio. Of course
if you only have an Atari that might require the very code you were trying
to get it ....


Glenn Elmore -N6GN-

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

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

Date: 7 Jul 90 01:21:10 GMT
From: [e-mail]  (Patty Winter)
Subject: Packet callsign servers (Was: Re: KA9Q package for the Atari ST)
To: [e-mail]

In article <[e-mail]> [e-mail] (Glenn Elmore) writes:
>
>  Not only could you have gone to the library, but in northern California
>anyway you could have used tcp/ip to finger the amateur radio database
>which n6oyu runs and gotten the information via radio. Of course
>if you only have an Atari that might require the very code you were trying
>to get it ....

The N6OYU callsign server can be accessed via AX.25 as well as TCP/IP.
Whatever software the original poster is now using (he gave a PBBS address)
would be fine for that. However, he lives in Culver City, so he still
would have been out of luck. I thought people in northern California
who weren't aware of this might be interested, though. (145.75 MHz.)

(However, as a couple of people have pointed out, getting Phil's
address wouldn't have helped anyway since he didn't write the Atari
version of his program.)


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

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

Date: 6 Jul 90 18:08:02 GMT
From: usc!samsung!uakari.primate.wisc.edu!crdgw1![e-mail]  (Donald P Perley)
Subject: Usenet News Feed on Packet?
To: [e-mail]

In article <[e-mail]>, dana@lando (Dana H. Myers) writes:
>            I don't think control operators of packet
>stations CAN or DO screen all traffic flowing through their station;
>what happens if someone is digipeating through my station - do I need
>to have MONITOR mode on and turn the TNC off if I see traffic of questionable
>nature? Hmmm..... nobody I know does that, so either there are a lot of
>criminals out there or you have some interpretation of the rules that is
>impractical and not being enforced.

I don't know what the "official" story is, but you could argue that
you as the digipeater operator relies on the originating station to keep it
clean, since that station is under the same restrictions that you are.

Usenet doesn't have the same content restrictions, so the gateway station
can't rely on the feed from usenet to be compliant.

-don perley - ke2tp
[e-mail]

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

Date: 6 Jul 90 17:30:54 GMT
From: rochester!rit!cci632![e-mail]  ( co-op)
Subject: Usenet News Feed on Packet?
To: [e-mail]

In article <[e-mail]> [e-mail] (Dana H. Myers) writes:
>
>   I agree with this; but I don't think control operators of packet
>stations CAN or DO screen all traffic flowing through their station;
>what happens if someone is digipeating through my station - do I need
>to have MONITOR mode on and turn the TNC off if I see traffic of questionable
>nature?

That's silly, and I'm sure you're aware of this.  The traffic that is
"digipeated" through you was originated by another ham -- another HAM,
who is presumably licensed.  Digipeating, or repeater operation, is not
the same as third-party operation.

If you're automatically shipping out Usenet, you are putting non-hams
in control of what goes out of your station.  You therefore have NOT
taken adequate precautions to prevent unauthorized use of your station.

Sure, automatic repeater operation is permitted...but third-party traffic
is a totally different issue, and the idea behind it is that THE HAM is
putting stuff on the air on behalf of another person; it is NOT that
the other person may use your equipment and it's O.K.

I would consider the sort of operation under consideration here as
very negligent, and would hope that this is a hypothetical discussion
(and that hams value their licenses more than to do this sort of thing).

(I'm just a little surprised that nobody's disputed how realistic a
"dirty-word-filter" really is; I don't think it's very practical at
all).


Chris, WZ2B

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

End of Packet-Radio Digest
******************************
Date: Sun,  8 Jul 90 04:30:02 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #79
To: packet-radio


Packet-Radio Digest         Sun,  8 Jul 90       Volume 90 : Issue  79

Today's Topics:
                 IMHO ???????
            KA9Q package for the Atari ST
           KA9Q software on floppy (2 msgs)
         usenet News Feed on Packet? (2 msgs)

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests 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".
----------------------------------------------------------------------

Date: 8 Jul 90 02:55:36 GMT
From: philmtl!philabs!briar![e-mail]  (Robert Casey)
Subject: IMHO ???????
To: [e-mail]

PITA:  pain in the ass
RTFM:  read the f*cking manual
BTW:  by the way

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

Date: 6 Jul 90 18:22:24 GMT
From: sdd.hp.com!elroy.jpl.nasa.gov!grian!puffin!wd6ehr.ampr.org![e-mail]  (Mike Curtis, ax.25 wd6ehr@k6iyk [phone])
Subject: KA9Q package for the Atari ST
To: [e-mail]

In article <[e-mail]> [e-mail] writes:
> In article <[e-mail]> [e-mail] writes:
> >In article <[e-mail]>, [e-mail] says:
> >>
> >>Hello there,
> >>
> >>I managed to get a hold of the KA9Q package for the Atari ST. It took quite a
> >>bit of looking and asking, until a kind sould in Europe uucp'd me the files.
> >>
> >>If someone would like a copy of the files, I'd be happy to uucp them to you.
> >
> >The files for KA9Q are also on terminator.cc.umich.edu for annonomous ftp under
> >the /atari/telecomm directory.  Thought you would like to know.  :-)
> >
> >Babs Silvas

>   The KA9Q is a ham radio callsign. Armed with that knowledge you could also
> have gone to a public library that has a copy of the ARRL ham radio callsign
> directory and found his (or her) address and written them directly.
>
> ------------------------------------------------------------------------------
>  |  Michael Nowicki   N6LUU      Atari Corp,Sunnyvale CA     /TT/UNIX/X team  |

The ka9q net is ms-dos, and will not run on an ST.  There are several
ports for the ST that don't work for more than a few  minutes  before
bombing.

I'm running pe1chl's port of the ka9q net on my ST.  Not only does it
run for a week or so before Atari's infamous folder limit catches  up
to it, but it has many enhancements lacking in the ka9q net, such  as
multiport gateway (NetDigi), conference bridge, rcmd (rlogin),  type,
flow control that works, etc.

The message below has been posted several times here.

              73, Mike Curtis

  ____________________________________________________________________________
 | [e-mail]                | "I  didn't invent the talking machine- |
 | packet wd6ehr@k6iyk.#socal.ca.usa | God did.  I just  made the  first  one |
 |                                   | that can be turned off." (-;           |
 | 7921 Wilkinson Avenue             | -Thomas Edison, following several long |
 | North Hollywood CA 91605-2210     | speeches at a banquet in honor of  his |
 | [phone]                    | invention of the phonograph.           |
 |___________________________________|________________________________________|


         TCP/IP: PE1CHL NET FOR ATARI ST and IBM PC

I have been "volunteered" as the official keeper of the pe1chl bits  for
the U.S.

I have the latest pe1chl TCP/IP for both the Atari ST and  the  port  to
IBM PC and clones, and some  additional  documentation  on  them.   Both
versions support the KAM/KPC-4  as  dual  port  KISS  TNC's,  conference
bridge, NetDIGI, MHeard, end user Netrom, rcmd  (remote  command  mode),
TNC2 emulator (run net with rli/mbl PBBS with SCC interface, or PC under
DoubleDos), and excellent implementations of the usual tcp/ip protocols.
The MS-DOS version also supports the evil DRSI board.

For the ST version, send me a 720k double sided or 2 single  sided  360k
3-1/2" diskettes, formatted, with postpaid,  addressed  mailer.   Please
specify Atari ST on the disk label.

For the PC version,  send one  FORMATTED  720K  3-1/2"  diskette,   with
postpaid, addressed mailer.  I do not support  5-1/4".   Please  specify
MS-DOS version on the disk label.

Mail to:
Mike Curtis wd6ehr
7921 Wilkinson Avenue
North Hollywood CA 91605-2210
[phone]

73, Mike
wd6ehr@k6iyk.#socal.ca.usa.na
[e-mail]

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

Date: 6 Jul 90 10:06:34 GMT
From: peregrine!sceard!ncr-sd!ncrcae!secola![e-mail]  (Randy Mechling)
Subject: KA9Q software on floppy
To: [e-mail]

Can anyone tell me how to get a copy of the KA9Q software on floppy for
a DOS PC.  I do not have ftp capability at this site.  Please E-Mail me
any responses.  Thank you very much.

Randy Mechling WA4HOX
[e-mail]


--
*******************************************************************************
*  Randy Mechling    NCR Comten Columbia | 1+1=2  1-1=0   etc.                *
*  [e-mail]      | 2+2=4  2-2=0                       *
*******************************************************************************

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

Date: 7 Jul 90 15:27:31 GMT
From: [e-mail]  (Patty Winter)
Subject: KA9Q software on floppy
To: [e-mail]

In article <[e-mail]> [e-mail] (Randy Mechling) writes:
>Can anyone tell me how to get a copy of the KA9Q software on floppy for
>a DOS PC.  I do not have ftp capability at this site.  Please E-Mail me
>any responses.  Thank you very much.

Randy (and others who don't have FTP access):

The software is available from TAPR (Tucson Amateur Packet Radio).
Because they sell several different KA9Q disks (depending on
whether you want the source code, the full documentation, etc.),
it's probably best if you call and find out the price of the
exact set you want. Their number is [phone]. Or you could
write to them and ask for their software list. (P.O. Box 12925,
Tucson, AZ 85732.)


Patty

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

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

Date: 6 Jul 90 18:54:42 GMT
From: sdd.hp.com!elroy.jpl.nasa.gov!grian!puffin!wd6ehr.ampr.org![e-mail]  (Mike Curtis, ax.25 wd6ehr@k6iyk [phone])
Subject: usenet News Feed on Packet?
To: [e-mail]

In article <[e-mail]> [e-mail] writes:
> > Unless you can get your "software filter" licensed by the FCC as a ham, it
> > cannot serve as a "control operator" for this purpose.  The FCC states when
> > this has come up before (usually in regard to phone patches) that ALL TRAFFIC
> > which will be available "on-air" MUST have been screened FIRST by a LIVE ham.

> You might be taking something out of context.  There are such things
> automatic control, and this is what the software filter is.  The FCC
> rules do not literally say "live ham" but rather are defined in legal
> terms that do allow automatic things under certain circumstances.
> Read what those circumstances are.  Don't just assume that because
> something is not legal under some circumstances that it is also not
> legal under other circumstances.
>
> > I doubt anyone is going to take the time to read a "full USENET feed" on a
> > daily basis...

> Most certainly not.

> > Further, there is a rule prohibiting use of ham radio to bypass "common
> > carrier"radio services, and if the FCC spots this use, they will "have a
> > cow", in the current phrase.  They do NOT want ham radio used by non-hams
>                                                                 ^^^^^^^^^^^
> > for routine message traffic, that's what BUSINESS radio services and
> > landline phone is for.

Not exactly so - first, ham radio provides autopatch and phone patch, both
of which bypass telco; and NTS for passing messages, which bypasses
Western Union.  These have been going on for years with the approval of
the FCC.  The only thing that has been questioned is the "reverse
autopatch", which allows someone to phone in and call a ham on the air.
Here the issue is allowing uncontrolled access to amateur radio, not
bypassing other services.

> But since we are talking about use by hams, then this particular argument
> would not necessarily apply.  These USENET messages would really constitute
> third party traffic and the rules that apply to it would apply here.  Just
> because the ends are non-hams does not in itself make it illegal; it just
> invokes some additional restrictions, which most of USENET cannot adhere to
> anyway.  The restrictions are less if the destination is a ham, and this is
> more likely what is being considered.

Just thought you'd like to know - pete@puffin (k6jrr) is providing a
screened news feed to me, which I forward to several other tcp/ip
stations here on the packet duplex repeater.  He personally checks all
mail for "dem dir-tee words", or anything else that could be a bone of
contention for the FCC to pick.....

It seems to me that, if usenet could police itself in the same manner
that amateur radio does, there would be no problem with an unsupervised
news feed.


              73, Mike Curtis

  ____________________________________________________________________________
 | [e-mail]                | "I  didn't invent the talking machine- |
 | packet wd6ehr@k6iyk.#socal.ca.usa | God did.  I just  made the  first  one |
 |                                   | that can be turned off." (-;           |
 | 7921 Wilkinson Avenue             | -Thomas Edison, following several long |
 | North Hollywood CA 91605-2210     | speeches at a banquet in honor of  his |
 | [phone]                    | invention of the phonograph.           |
 |___________________________________|________________________________________|

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

Date: 8 Jul 90 06:38:44 GMT
From: elroy.jpl.nasa.gov!grian!puffin![e-mail]  (0000-Pete Carah(0000))
Subject: usenet News Feed on Packet?
To: [e-mail]

In article <[e-mail]> wd6ehr.ampr.org![e-mail] writes:
>Just thought you'd like to know - pete@puffin (k6jrr) is providing a
>screened news feed to me, which I forward to several other tcp/ip
>stations here on the packet duplex repeater.  He personally checks all
>mail for "dem dir-tee words", or anything else that could be a bone of
>contention for the FCC to pick.....

Actually, I only handle 2 low-volume newsgroups this way (rec.ham-radio.packet
and ca.earthquakes) to 3 stations, with a 3rd very low-volume newsgroup
to one of the stations.  Even rec.ham-radio is too high-volume for my
available screening time.  (I'm using a mail-based gateway that forces
me to read each article to each station, so I see all articles 3 times.)
An nntp implementation with a dedicated spool would make things much
easier, but that hasn't showed up in "net" yet.

The reject rate for the above newsgroups is rather low.

BTW, mail to Mike's return address goes through the same gateway.

>It seems to me that, if usenet could police itself in the same manner
>that amateur radio does, there would be no problem with an unsupervised
>news feed.

Really, you come up against the 3rd party rules here, which make not only
screening necessary but also extra logging and some other problems.
Policing is not the only issue.

>                      73, Mike Curtis

-- Pete    ([e-mail])
      ...!{elroy.jpl.nasa.gov!grian | hacgate}!puffin!pete

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

End of Packet-Radio Digest
******************************
Date: Mon,  9 Jul 90 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #80
To: packet-radio


Packet-Radio Digest         Mon,  9 Jul 90       Volume 90 : Issue  80

Today's Topics:
             HAM RADIO IN DANGER
             Usenet News Feed on Packet?

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests 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".
----------------------------------------------------------------------

Date: 8 Jul 90 20:33:00 GMT
From: maverick.ksu.ksu.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu![e-mail]
Subject: HAM RADIO IN DANGER
To: [e-mail]

> Lets get optimistic:  Most of the stuff on the hf bands you hear is going to
> be replaced with satellite communications.  I know for a fact that this is
> true for maritime mobile.  Wouldnt an extra 10 or 15 mhz in the hf bands be
> a nice acquisition ?

Let's get REALISTIC!

As most everything else slowly moves off shortwave, there will be lots of
this spectrum for grabs.  But the Shortwave Broadcasting service is going
to end up with most of it.  Hams themselves are going to get some, but
nothing near 10 or 15 Mhz.

As a shortwave listener, I actually look forward to more SWBC spectrum.
As a ham I'd also like to see us get more, even though my interest in
shortwave is primarily as a listener.  Nearly ALL of my hamming is on
VHF and above.

However, amateur radio is going to be judged.  Those who are making the
decisions to allocate spectrum are surely not interested in allocating
any spectrum to the "shout, cuss, and QRM" service.  While VHF and up
has these problems as well, we hear them in HF, and everyone else in the
world does, too.

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

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

Date: 8 Jul 90 20:15:00 GMT
From: maverick.ksu.ksu.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu![e-mail]
Subject: Usenet News Feed on Packet?
To: [e-mail]

> It seems to me that, if usenet could police itself in the same manner
> that amateur radio does, there would be no problem with an unsupervised
> news feed.

USENET already polices itself within reason.

USENET has a **DIFFERENT** set of "policies" to go by than Amateur Radio has.

Unless the FCC decides to let "anything go" in Amateur Radio (which I would
strong oppose), that which is OK in Amateur Radio will always be some subset
of that which is OK in USENET.

USENET is an umbrella net, and it is not inconceivable that it could even
include Amateur Radio under it.  But anytime a network really consists of
other networks with different policies of what is and is not allowed, there
usually needs to be a consideration of these policies.  In MOST cases, there
has not be much of a concern.  One example of where there is such a concern
is the DoD policy of not permitting "for sale" items over its network.  This
has lead to creation of a separate USENET newsgroup (rec.ham-radio.swap) so
that these "for sale" items were not distributed over Arpa via the INFO-HAMS
digest.  Though this setup was not absolutely perfect, it basically did what
was needed to be done.

Similarly, Amateur Radio has a "policy" and that is basically what is in
the FCC rules.  However this "policy" is not readily understood by most
ordinary people, and is tough enough for hams themselves.  Hams need to
interpret the rules themselves because it is their own license that is at
stake for violations.  This means that UNLIKE the previously mentioned setup
where for sale items were isolated and USENET was self policing, it is not
likely that USENET can be able to "enforce" Amateur Radio policies in any
way.  Remember, people do not take an exam on FCC part 97 rules for USENET
access.

While any ham who passes on prohibited traffic is technically in violation,
the ham who introduces prohibited traffic into Amateur Radio is the most
likely one to have to deal with the violations.  Since this depends on
tracking down which ham it is, each ham down the line still has certain
responsibilities.

I see no other way for a USENET feed gateway into Amateur Radio to take
place without some sort of filtering to ensure that prohibited traffic
does not make it into Amateur Radio.  I also happen to believe that no
software can reliably filter this traffic.  However, if the newsgroups
are limited to the Amateur Radio related ones (such as including some
like sci.electronics) then a simple software based filtering system MIGHT
be able to reduce prohibited traffic to a low enough level that PERHAPS
the problems of such traffic will be negligible, as interpreted by the
FCC (and the judicial system where applicable).

Filtering the seven dirty words, while certainly a necessity, is NOT
ENOUGH.  For sale items must clearly be ham radio related.  Any other
business related matter must be filtered out.  Remember, "business"
includes more kinds of business than just "commercial business".  An
exchange of information between charitable, non-profit, and/or public
services organizations CONSTITUTES BUSINESS (just not COMMERCIALLY).
Don't equate COMMERCE with BUSINESS.

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

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

End of Packet-Radio Digest
******************************
Date: Tue, 10 Jul 90 04:30:02 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #81
To: packet-radio


Packet-Radio Digest         Tue, 10 Jul 90       Volume 90 : Issue  81

Today's Topics:
          Automatic screening of traffic for packet
              Dumb PK-88 on Mac question
              Packet-Radio Digest V1 #79
              Packet-Radio Digest V1 #80
           Packet Connections in the Baltic States
              TCP/IP on 6 meters
             Usenet News Feed on Packet?
                 WWIV

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests 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".
----------------------------------------------------------------------

Date: 9 Jul 90 19:59:43 GMT
From: swrinde!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!turnkey!orchard.la.locus.com!prodnet.la.locus.com!lando.la.locus.com![e-mail]  (Dana H. Myers)
Subject: Automatic screening of traffic for packet
To: [e-mail]

  I've thought about it a little; the encryption of the data would have
to be done with a relatively unique seed to be useful. If just one seed
was in use, this wouldn't work well. Obviously.

  I'd suggest that amateurs operating "usenet" to packet gateways would
enroll users, much as a user gets an account on a computer. Traffic
intended for retransmission in the packet domain would be encrypted, and
the seed would be on a per-user basis and must have been previously
agreed upon. It would be up to the amateur how to do this; maybe by a
telephone call.

   The amateur would probably still wish to "filter" the traffic for
profanity or attempt to filter out other illegal content; "users" who
violate the rules may have their accounts revoked. This is a non-issue
for hams (like myself) who'd like to be able to originate and receive
packet traffic via usenet.

   I'd also like to apolofize to Skip Sanders for jumping on him. He was
mostly correct, but a little strict in his interpreting of the rules. I
certainly was not well-informed of the way the FCC handles digipeating
of traffic, but I did make the correct assumption; the FCC makes a
special case here.

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

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

Date: 9 Jul 90 14:13:23 GMT
From: snorkelwacker!spdcc!merk!alliant!linus!luke.mitre.org![e-mail]  (Douglas S. Rand)
Subject: Dumb PK-88 on Mac question
To: [e-mail]

OK.  I bought a PK-88, wired the cable and hooked it up to my
MAC and my 2m rig.  Everything's fine.  I can hook up to people
using AX.25, access the local clubs PBBS  and everything.

I now try putting it in KISS mode and using KA9Q.  Now I've used
the KA9Q package before with a PK-232 (right?) and everything
was fine with,  I believe, the same RS-232 cable.  But everything
isn't fine with the PK-88.  I've double checked the baud (9600) to
the TNC and loopback works.

Now this PK-88 has a simple KISS command that resets the
appropriate parameters to correct values for as long
as KISS is on.  So my problems aren't with the parameters
for KISS mode.  The KA9Q commands for AX.25 don't work either
so it isn't just a TCP/IP configuration problem.

Help.

Douglas S. Rand
Internet:   <[e-mail]>
Snail:      MITRE, Burlington Road, Bedford, MA
Disclaimer: MITRE might agree with me - then again...

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

Date: Tue, 10 Jul 90 10:16 N
From: Urs Baer <[e-mail]>
Subject: Packet-Radio Digest V1 #79
To: [e-mail]

please remove my old adress [e-mail] from your list.
The LISTSERV doesn-t work.

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

Date: Mon, 9 Jul 90 19:32 N
From: Urs Baer <[e-mail]>
Subject: Packet-Radio Digest V1 #80
To: [e-mail]

please remove my old adress 87674800s at csghsg5a. bitnet


from your list!!!!!!!!!!!!!!!!!!!!!!!0

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

Date: 18 Jun 90 22:54:21 GMT
From: eru!luth!sunic!tut!funic!santra!puukko.hut.fi![e-mail]  (Karl R. Tigerstedt)
Subject: Packet Connections in the Baltic States
To: [e-mail]

In article <[e-mail]> [e-mail] (Mike) writes:
>We are searching for packet radio operators in the Baltic states.
>If anyone knows of any packet radios out there, please let me know.
>If anyone knows of anyone closer to the Baltic states, who might know,
>please let me know!

    A couple of Estonian stations are active on packet. They connect to
our local PacketCluster and BBS's here in Helsinki quite frequently.
The distance between Tallinn and Helsinki is only about 70 km - across
the Gulf of Finland, so reaching here is not a big problem for the Tallinn
fellows. The station I've connected with are ES2WX and ES2RJ.

73 de OH2MBM


----------------------
Karl R. Tigerstedt                            email : [e-mail]
Helsinki University of Technology            packet : [e-mail]
Faculty of Electrical Engineering

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

Date: 9 Jul 90 18:22:59 GMT
From: hpfcso![e-mail]  (Bill Vodall)
Subject: TCP/IP on 6 meters
To: [e-mail]

/ hpfcso:rec.ham-radio.packet / [e-mail] (Ben Thornton) / 11:50 am  Jul  5, 1990 /

   Is there a 6 Meter frequency that is used primarily for TCP/IP
traffic?  I was thinking of crossbanding one of the NET/ROM nodes
in our vicinity and would like to know if anyone has any thoughts
or experiences to relate about this...

Ben
WD5HLS

----------


Is there a primary frequency (like 145.01) for general 6 Meter packet
use.  I've acquired an used crystal controlled FM rig that might be
fun to put on packet.  It'd be a chance to work the openings without
having to keep checking the band - just check the heard list and mailbox
every couple days.

Bill
WA7NWP

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

Date: 9 Jul 90 18:55:10 GMT
From: usc!samsung!sdd.hp.com!elroy.jpl.nasa.gov!turnkey!orchard.la.locus.com!prodnet.la.locus.com!lando.la.locus.com![e-mail]  (Dana H. Myers)
Subject: Usenet News Feed on Packet?
To: [e-mail]

In article <[e-mail]> [e-mail] (Christopher E. Piggott, WZ2B) writes:
>In article <[e-mail]> [e-mail] (Dana H. Myers) writes:
>>
>>   I agree with this; but I don't think control operators of packet
>>stations CAN or DO screen all traffic flowing through their station;
>>what happens if someone is digipeating through my station - do I need
>>to have MONITOR mode on and turn the TNC off if I see traffic of questionable
>>nature?
>
>That's silly, and I'm sure you're aware of this.  The traffic that is
>"digipeated" through you was originated by another ham -- another HAM,
>who is presumably licensed.  Digipeating, or repeater operation, is not
>the same as third-party operation.

    Oh, gosh, Dad, that is silly, and I'm stupid enough to say it anyway. :-)
Quite frankly, I'm surprised that the FCC would not hold an operator
responsible for profane (or otherwise illegal) traffic, regardless of where
it originated from. I'm glad that I'm not responsible, but I am very surprised
and (seriously) DON'T THINK IT WAS SILLY FOR ME TO ASK THE QUESTION. Don't
be a snot.

>If you're automatically shipping out Usenet, you are putting non-hams
>in control of what goes out of your station.  You therefore have NOT
>taken adequate precautions to prevent unauthorized use of your station.

    The more I've thought about it, I don't think I'd ship rec.ham-radio
or rec.ham-radio.packet out. In fact, the volume of traffic generated would
be too much. This leads me to further thought below.

>(I'm just a little surprised that nobody's disputed how realistic a
>"dirty-word-filter" really is; I don't think it's very practical at
>all).

    I don' think a dirty word filter is difficult at all; a profane language
filter may be quite a bit more challenging. A dirty word filter need only
"bounce" messages into a holding bin, for operator review. The problem is
bouncing profane material which does not use dirty words, or material which
has an unacceptable commercial content.

   Certainly, routing traffic FROM the packet domain to the "usenet"
domain is not a problem. But, routing traffic from the "usenet" to the
amateur packet domain is prone to the already discussed profanity
regulations, but there is also the chance (very slight given the performance
of 1200 b packet links) that a route may exist which takes traffic from the
"usenet" domain into the packet domain and back into the "usenet" domain.
This would start to look suspiciously like competition with the phone
companies.

   So, routing to the ham community becomes less and less attractive; but
I still would like to send mail to hams from the usenet through an automatic
gateway... how?

  Make the gateway a request server. People originating traffic for the
packet domain inside the "usenet" domain would send a request, including
the text of the message, to a server. The server would then decide whether
or not to forward the traffic. Once idea that springs to mind is the
use of encrypted "usenet" text; the packet gateway server would decrypt
the text and look for a certain form "letter", this in turn may contain
special keywords in order to get repeated out into the packet domain.
Another thought is that the packet to "usenet" direction may automatically
encapsulate the packet traffic into encrypted usenet messages which use
the "usenet" as a backbone.

  Please keep in mind I'm suggesting that the traffic is only encrypted
while in the usenet domain in order to obscure the mechanism used to
prevent unauthorized access from the packet domain, I'm not suggesting
that encrypted packets be sent over ham radio (I'm not that silly :-).

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

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

Date: 7 Jul 90 03:39:49 GMT
From: n8emr!cmhgate!f160.n226.z1.FIDONET.ORG![e-mail]  (Joey Burgett)
Subject: WWIV
To: [e-mail]

Ok gents, there is supposed to be a BBS program for the IBM called WWIV, it
was written by a fellow HAM and was supposed to be intended for packet use as
well as phone modem use.  I have a copy of WWIV but no where in the docs or
setup does it even seem to refer to Packet, let alone ham!

Anyone know anything?  Help!!!!!!

73's de N8MPV Joey


--
Joey Burgett via cmhGate - Net 226 fido<=>uucp gateway Col, OH
UUCP: ...!osu-cis!n8emr!cmhgate!160!Joey.Burgett
INET: [e-mail]

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

End of Packet-Radio Digest
******************************
Date: Wed, 11 Jul 90 04:30:04 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #82
To: packet-radio


Packet-Radio Digest         Wed, 11 Jul 90       Volume 90 : Issue  82

Today's Topics:
      Automatic screening of traffic for packet (4 msgs)
                   For Sale
   Packet callsign servers (Was: Re: KA9Q package for the Atari ST)
         TR-22 use on packet - two questions
         What's wrong with Internet on radio (2 msgs)

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests 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".
----------------------------------------------------------------------

Date: Tue, 10 Jul 90 09:50:08 MST
From: [e-mail] (Marc Sarrel)
Subject: Automatic screening of traffic for packet
To: [e-mail]

With all this stuff about getting news-feeds on the air, no one has
mentioned anything about getting just a mail hookup.  How tough would
it be to handle SMTP mail traffic?  What FCC rules would govern such a
gateway's use?  Would the standard third party traffic rules apply?
Is it similar to the situation where a ham uses a phone patch to call
a non-ham?  (Although this analogy is not complete, since, in this
case, the non-ham can originate as well as answer.)  I also seem to
remember hearing that there are some technical problems with such
things since the ham TCP/IP network is disjoint (that is, each part is
not connected to every other part), is this a big problem?

With more questions than answers...

--marc

-=-
Marc A. Sarrel
N7OLI
[e-mail]    |   "Oh, _lightweight_ Alpaca..."
..!sun!sunburn!miranda!sarrel           |               -Blanche DuBois

NSA fodder:

Marxist, quiche, El Salvador, assassination, Warsaw Pact.

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

Date: 10 Jul 90 19:10:47 GMT
From: swrinde!cs.utexas.edu!helios![e-mail]  (William Gunshannon)
Subject: Automatic screening of traffic for packet
To: [e-mail]

In article <[e-mail]> [e-mail] (Marc Sarrel) writes:
>With all this stuff about getting news-feeds on the air, no one has
>mentioned anything about getting just a mail hookup.  How tough would
>it be to handle SMTP mail traffic?  What FCC rules would govern such a
>gateway's use?  Would the standard third party traffic rules apply?
>Is it similar to the situation where a ham uses a phone patch to call
>a non-ham?

Well, for one thing, I'm sure he couldn't use it to order a pizza!!


:-) :-)   see, I'm only kidding...

bill KB3YV

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

Date: 10 Jul 90 13:24:24 GMT
From: usc!zaphod.mps.ohio-state.edu!sunybcs!uhura.cc.rochester.edu!rochester!rit!cci632![e-mail]  ( co-op)
Subject: Automatic screening of traffic for packet
To: [e-mail]

In article <[e-mail]> [e-mail] (Dana H. Myers) writes:

>  I'd suggest that amateurs operating "usenet" to packet gateways would
>enroll users, much as a user gets an account on a computer. Traffic
>intended for retransmission in the packet domain would be encrypted, and
>the seed would be on a per-user basis and must have been previously
>agreed upon. It would be up to the amateur how to do this; maybe by a
>telephone call.
...
>This is a non-issue
>for hams (like myself) who'd like to be able to originate and receive
>packet traffic via usenet.

If I read this right, it seems like you'd be making a list of hams that
you're "authorizing" to be in control of your station.  Is this what you
are suggesting?  Doesn't seem like you'd have the authority to do this.
(Ignore this point if I misunderstand you).

Having a list of hams whose traffic is O.K. to pass out to packet could be
fun, though.  But I still don't know if I'd trust it, knowing how easy it
is to fake usenet message paths and sources.

Am I paranoid?  Hmm, good question.  I also keep my HT on "Tx STOP", in
case some idiot picks it up and starts pushing buttons (chances are that
said idiot would not figure it out fast enough to do any damage).

Chris

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

Date: 10 Jul 90 13:25:44 GMT
From: rochester!rit!cci632![e-mail]  ( co-op)
Subject: Automatic screening of traffic for packet
To: [e-mail]

In article <[e-mail]> [e-mail] (Christopher E. Piggott, WZ2B) writes:
>If I read this right, it seems like you'd be making a list of hams that
>you're "authorizing" to be in control of your station.  Is this what you
>are suggesting?  Doesn't seem like you'd have the authority to do this.

Oops.  I goofed.  I meant to say, "making a list of NON-hams that you're..."

:-) (sheepish grin)

Chris

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

Date: 10 Jul 90 06:45:29 GMT
From: n8emr!cmhgate!f160.n226.z1.FIDONET.ORG![e-mail]  (Joey Burgett)
Subject: For Sale
To: [e-mail]

* Original: AREA.... 4SALE226
* Original: FROM.... Joey Burgett
* Original: TO...... All
* Forwarded by...... Maximus-CBCS v1.00 at 1:226/160.0

For Sale:

12 Mhz IBM Compatible 286 -

o  Full size case
o  1-5.25" Floppy 1.2 Meg
o  1-3.5" Floppy 720k
o  2 Meg of Ram
o  VGA Graphics Adapter with VGA Gray Scale Monitor
o  Sound Blaster sound card, which features:
      - MIDI Port
      - Stereo Sound (Also Adlib Compatible)
      - External Amplified Speakers (Stereo)
      - Game Port
      - Voice Digitizer
o  2 Serial Ports
o  1 2400 Baud internal modem
o  Serial Mouse
o  1 Printer Port
o  Arcnet Networking Card
o  40 Meg Hard Drive

Price: $1000 - FIRM!

Reason for selling:  Need to get new HF Rig for Amateur Radio -

Contact me via my BBS at: 1/614-421-3015 1200 or 2400 Baud
FidoNet: (1:226/160)

or

Contact me packet on W8CQK in Columbus, Ohio

Thanks - N8MPV - Joey


--
Joey Burgett via cmhGate - Net 226 fido<=>uucp gateway Col, OH
UUCP: ...!osu-cis!n8emr!cmhgate!160!Joey.Burgett
INET: [e-mail]

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

Date: 9 Jul 90 13:32:55 GMT
From: usc!elroy.jpl.nasa.gov!peregrine!ccicpg!cci632![e-mail]  ( co-op)
Subject: Packet callsign servers (Was: Re: KA9Q package for the Atari ST)
To: [e-mail]

In article <[e-mail]> [e-mail] (Patty Winter) writes:
>
>The N6OYU callsign server can be accessed via AX.25 as well as TCP/IP.

Is the software that does this publically accessible, and does it run
under Unix or DOS?

I am in the process of loading the callsign database to my home machine from
work, and have begun planning on the software but no actual coding.  Perhaps
I do not have to re-invent the wheel?

Chris

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

Date: 10 Jul 90 18:27:22 GMT
From: usc!elroy.jpl.nasa.gov!turnkey!orchard.la.locus.com!prodnet.la.locus.com!lando.la.locus.com![e-mail]  (Dana H. Myers)
Subject: TR-22 use on packet - two questions
To: [e-mail]

  I'm interested in hearing from anyone who {is using, has used} a TR-22
on packet. Specifically, I've heard a few reports of abysmal TXDELAY
values required for this radio.

  Also, I'd be interested anyone who has successfully modified the radio
to reduce the TXDELAY. I've got a really straightforward idea to do this,
and I'm likely to try it and post the results fairly soon, but I'd be really
interested in hearing of a mod that works for sure.

 (Anyone interested in my idea - the basic notion is to lift the 'BT'
  end of R145 and connect it to 'B'. This leaves the xmit oscillator,
  phase modulator, first doubler and tripler running all the time. The
  'BT' line will still switch the second doubler and buffer amp. The
  possible problem is harmonic radiation from the first doubler at 144
  Mhz getting into the receiver; even if this is happening it may be of
  a low enough amplitude to ignore)

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

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

Date: 11 Jul 90 01:21:28 GMT
From: hayes.fai.alaska.edu!acad3.fai.alaska.edu![e-mail]  (MUNTS PHILLIP A)
Subject: What's wrong with Internet on radio
To: [e-mail]

    Before I get started on this tirade, let me emphasize
that I laud the efforts of those who are trying to advance
amateur packet radio.  I just wonder about the direction we
are going.

    It seems to me that the goal of the amateur radio
TCP/IP community is to implement a fully distributed network
based on well connected peer stations.  Ideally, there
should be no central (read large, expensive, and vulnerable)
switching stations like the phone company uses.  This is of
course based on the existing Internet.  Unfortunately the
Internet is NOT a good model for packet radio.

    Let me postulate that most NODES on Internet are
essentially large terminal servers.  On the other hand, most
USERS on Internet are connected to plain old terminal ports
on the server, like the modem and serial port I am using
right on the university VAX cluster.  Traffic from the
various users is bundled by the terminal server and routed
to the Internet.  Internet ONLY FUNCTIONS BECAUSE MOST USERS
ARE NOT ACTUALLY CONNECTED TO IT.  A great deal of parallel
processing is provided by the terminal controllers of the
various nodes.  This is the only thing that keeps Internet
from being swamped.  (Sometimes, at least.)

    This many-to-one concentration function is simply not
technically or politically feasible for packet radio.  We
attempted to do it on VHF with half-duplex contention
channels but this obviously has been a total failure.  Half-
duplex contention is extremely inefficient, and even it it
wasn't, the channel bandwidth still has to be divided up
among the many users.

    Given the full duplex radios now on the market, I think
it would be pretty straightforward to build 9600 baud full
duplex radio modems using V.29 signalling.  This eliminates
the inefficency of the contention channel, but every user
needs a dedicated frequency pair.  This is impossible on the
VHF/UHF bands because they are already saturated in
metropolitan areas, where the most channels would be needed.
It's also difficult or impossible on the microwave bands
because the terminal server needs an omnidirectional antenna
pattern.  Not every user would have a clear path to the
server anyway.

    Even if we could solve all the technical problems
described above, who is going to pay for the terminal
servers?  On Internet, they are mostly funded by federal and
state governements.  Such vast quantities of money are
simply not available to the amateur radio community.  Even
if it were, we are right back to central switching stations.

    So we scrap the entire Internet concept of large scale
terminal concentrators, leaving us with a distributed
network of peer stations: just what the amateur radio TCP/IP
community is working on.  The existing Internet is
implemented on point-to-point channels between nodes.  This
is easy to do with wires (given enough money), but not so
easy to do with radios.  The number of channels required for
a metropolitian area demands microwave equipment again but
finding a frequency and a clear path for everyone seems
virtually impossible.  And then how do you get between
cities...

    At this point, I would like to unveil some grand master
plan to solve all the problems of amateur packet radio.
Unfortunately, I haven't got one.  It's easy to criticize
the TCP/IP community but a lot more difficult to come up
with anything better.  I haven't got a general solution and
I am not sure there even is one.

    The easy way out would be to reduce our expectations.
On the existing Internet, the user expects to be able to
connect interactively, in real time, to any node on the
network.  This is actually possible since all the nodes are
connected together with permanent high bandwidth channels.
Most of the wonder and usefulness of TCP/IP comes from this
ability to make real time connections to remote systems.

    On amateur packet radio, channels are neither permanent
nor high bandwidth.  Perhaps it is then only reasonable to
expect a reliable email system, with real time connections
only possible within limited areas.  TCP/IP is then perhaps
no longer appropriate and better solutions may be possible.

    Let me reemphasize that I am not attacking the TCP/IP
implementators.  Telnet and FTP are nifty and wonderful but
I have to wonder if a really efficient and reliable email
system would be a lot more useful in the real world of
amateur packet radio.

Philip Munts N7AHL
NRA Extremist, etc.
University of Alaska, Fairbanks

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

Date: 11 Jul 90 04:21:55 GMT
From: [e-mail]  (Brian Kantor)
Subject: What's wrong with Internet on radio
To: [e-mail]

>The internet and the tcp/ip packet radio network that emulates it is
>a huge collection of terminal servers, etc.

If I were to accept your view of what the real world of packet radio,
and what the internet is, I'd have to admit that your arguments make
sense.

But I don't want to limit myself to that view.  I want more.

I want closely-coupled distributed computing, databases, communications.
I want to play chess against your computer while you challenge mine.  I
want digital voice, images, text, printed pages.  I want to see if I can
be in two or more places at one time with virtual realities.  I want to
span space and time - visit places I can never go.  I want to see the
Earth from orbit, travel undersea, hear the winds in a ballon as I
control it from my easy chair.  I want to know if the Cokes in the
machine down the hall or across the planet are cold yet.  What's the
weather like in New Jersey, or off the end of the Scripps Pier?

These are only a few of the things that can be done with an experimental
digital network.  Some of them are history, some are happening now; some
are a few years off.  Some might never happen - but we'll never know
until we try.

Please, oh please! don't try to make everyone equal by cutting them all
down to a uniform size.  It is the dreamers, the experimenters, the
imaginative few who are willing to try to do the impractical, the
impossible, the glorious - these are the kinds of people we need most in
ham radio - nay, in society!

And think, even if only one or two of us succeeds only in 1% of what we're
dreaming of doing, even unimaginative uses of the network will be all
the better for it.

Please don't take my toys away, Daddy.  I don't want to go to bed yet.
    - Brian

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

End of Packet-Radio Digest
******************************
Date: Thu, 12 Jul 90 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #83
To: packet-radio


Packet-Radio Digest         Thu, 12 Jul 90       Volume 90 : Issue  83

Today's Topics:
      Automatic screening of traffic for packet (2 msgs)
                   BB V2.10
             HAM RADIO IN DANGER
                 IMHO ???????
               MFJ-1270 Virus? (2 msgs)
   Packet callsign servers (Was: Re: KA9Q package for the Atari ST)
         TR-22 use on packet - two questions (2 msgs)
             Usenet News Feed on Packet?
         What's wrong with Internet on radio (6 msgs)
                 WWIV

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests 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".
----------------------------------------------------------------------

Date: 11 Jul 90 09:30:30 GMT
From: elroy.jpl.nasa.gov!grian!puffin!wd6ehr.ampr.org![e-mail]  (Mike Curtis, ax.25 wd6ehr@k6iyk [phone])
Subject: Automatic screening of traffic for packet
To: [e-mail]

In article <[e-mail]> [e-mail] (Marc Sarrel) writes:
> With all this stuff about getting news-feeds on the air, no one has
> mentioned anything about getting just a mail hookup.  How tough would
> it be to handle SMTP mail traffic?  What FCC rules would govern such a
> gateway's use?  Would the standard third party traffic rules apply?
> Is it similar to the situation where a ham uses a phone patch to call
> a non-ham?  (Although this analogy is not complete, since, in this
> case, the non-ham can originate as well as answer.)

Speaking of phone patches, I've never seen a patch that DIDN'T bypass
the phone company.  Bypassing Ma Bell seems to be largely a non-issue
with the FCC; therefore a usenet feed to ham packet would not be a problem
based on this.

What WOULD be a problem is business-related communications, and profane
and/or indecent language.  I guess some people would be limited to a 4-word
vocabulary without said language.

>         I also seem to
> remember hearing that there are some technical problems with such
> things since the ham TCP/IP network is disjoint (that is, each part is
> not connected to every other part), is this a big problem?

Well, the tcp/ip network is not as contiguous as we'd like, but mail
can be forward via the ax.25 network worldwide.  It may take a week
or 2 sometimes (usually a day or so in the USA, and a couple days to
Europe), but it eventually gets where it's going.

Some portions of the mail forwarding network are quite slow - 110 baud.
Much mail is shipped over dedicated forwarding frequencies like 14.111,
at 300 baud, etc.

We're working on some higher speed links, i.e. 9600 baud, 56 KB, and
faster.  We'll also have a 9600 baud group on 2 meters in the L.A.
area soon.  TAPR's much-rumoured packetRADIO is going into beta testing
and will have a k9ng-format 9600 baud modem, 2 meter radio, and an
optional TNC2, all in one box.  Once that's done testing, can MFJ be
far behind in licensing and building these?

In the foreseeable future, we'll quite likely have multi-megabit
links for mail/ftp/netrom (??), etc.,  on amateur radio.
>
> With more questions than answers...

Not bad questions, though.....
> Marc A. Sarrel
> N7OLI

              73, Mike Curtis

  _________________________________________________________________________
 | [e-mail]             | "I  didn't invent the talking machine- |
 | packet [e-mail]   | God did.  I just  made the  first  one |
 |                                | that can be turned off." (-;           |
 | 7921 Wilkinson Avenue          | -Thomas Edison, following several long |
 | North Hollywood CA 91605-2210  | speeches at a banquet in honor of  his |
 | [phone]                 | invention of the phonograph.           |
  -------------------------------------------------------------------------

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

Date: 11 Jul 90 19:22:25 GMT
From: mejac!orchard.la.locus.com!prodnet.la.locus.com![e-mail]  (Dana Myers)
Subject: Automatic screening of traffic for packet
To: [e-mail]

In article <[e-mail]> [e-mail] (Christopher E. Piggott, WZ2B) writes:
>In article <[e-mail]> [e-mail] (Dana H. Myers) writes:
>
>>  I'd suggest that amateurs operating "usenet" to packet gateways would
>>enroll users, much as a user gets an account on a computer. Traffic
>>intended for retransmission in the packet domain would be encrypted, and
>>the seed would be on a per-user basis and must have been previously
>>agreed upon. It would be up to the amateur how to do this; maybe by a
>>telephone call.
>...
>>This is a non-issue
>>for hams (like myself) who'd like to be able to originate and receive
>>packet traffic via usenet.
>
>If I read this right, it seems like you'd be making a list of hams that
>you're "authorizing" to be in control of your station.  Is this what you
>are suggesting?  Doesn't seem like you'd have the authority to do this.
>(Ignore this point if I misunderstand you).

    I'm not clear just exactly how to word this, but I think this is a case
    where I am a control operator putting together an automatic station
    with safeguards to prevent unauthorized use. I think (and I could be
    wrong here) I have the authority to do this.

>Having a list of hams whose traffic is O.K. to pass out to packet could be
>fun, though.  But I still don't know if I'd trust it, knowing how easy it
>is to fake usenet message paths and sources.

   The reason for keeping data encrypted while in the usenet domain is
   to prevent such abuses. Even if someone were to forge mail from an
   enrolled user, they would have to encrypt the text of the message with
   the correct seed (password). It isn't just a list of OK hams; it is a
   list of "user names" and "passwords".

   I should clarify; I'm not suggesting that the data be sent into the
   packet domain still encrypted; the gateway would decrypt the text using
   the password, and check for a valid message (with some kind of internal
   checksum or message format, or some combination of these). Only valid
   messages, in pure text, get sent out.

--
*
* Dana H. Myers KK6JQ           (Alternate signature file)
* [e-mail]
*

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

Date: Wed, 11 Jul 90 18:16:22 PDT
From: "Roy Engehausen" <[e-mail]>
Subject: BB V2.10
To: [e-mail]

Version 2.10 of the AA4RE BB program is now available.

The primary advantage of BB over the MBL/RLI/BQE/CBBS.... systems is the
ability to handle multiple connects per port.  The program uses it own
multitasker and no DesqView, DoubleDos, etc is required.  On the down
side, BB has been optimized for speed and requires at least 512K (and
usually 640K) to be used productively.

BB uses a "host-mode" interface so the only TNCs supported are the TNC-1
and TNC-2 (or clones) with the WA8DED (or clone) EPROMS installed, the
AEA PK-87, PK-88, PK-232, and the DRSI PC*PA TNC card.  It also runs
with any KISS TNC using the G8BPQ PC Node switch.

You can get these programs by sending a $5 US (or equivalent) to:

 Dave Larton, N6JQJ
 766 El Cerrito Way, #D
 Gilroy, CA  95020-4149
 [phone]

For source code, include $2 more (needs multiple diskettes).  Between
Dave and I, we can handle all formats of 5 1/4 and 3 1/2.

The software can also be obtained by downloading from the following BBS:

   WA6RDH BBS at 916-678-1535 (300/1200/2400/4800/9600 N81)
   The W3IWI TOMCAT TCPIP server

Those with FTP Internet service or BITNET should send a note to AA4RE @
AA4RE.#NOCAL.CA.USA.NA with your TCPIP address (eg. 123.213.22.33) or
BITNET address for delivery over those networks.

SYSOPs running 2.9 should obtain 2.10 as soon as possible because of
potential BID problems with the alternate header length.

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

Date: 11 Jul 90 05:40:42 GMT
From: usc!samsung!sdd.hp.com!elroy.jpl.nasa.gov!grian!puffin!wd6ehr.ampr.org![e-mail]  (Mike Curtis, ax.25 wd6ehr@k6iyk [phone])
Subject: HAM RADIO IN DANGER
To: [e-mail]

In message <[e-mail]> [e-mail] writes>
> ..........
> BTW:  I agree that we need more people getting involved in this hobby, but
> there is a flip side to the coin.  Ever try to have a little fun on 20 mtr
> packet before ?  It is a very frustrating experience.

Yes, it is - due to the following, listed in order:
1. Too many packeteers jammed into a couple of frequencies
2. Not enough frequencies to accommodate the many packet users
3. 20 meter packet is normally too crowded to allow efficient 300 baud
   packet (is that an oxymoron or what? ;-)

............. (edited for levity.........;-)

25. Too many hams on 20 meter packet at the same time
26. Dorky beacons (HIEEE! CONECK TOO MY STUPED STAITION AN SCREEM A MESSEGE
    MOOR INSIPIDLY IDIOTIC THEN THIS WON! DE FRANK, PROFFFESSUR OF ENGLESH)
27. Fading (QSB)
28. Poor parameter settings

(Please note the relativity of the first 25.......)
If you've ever been on 20 in the very early morning, when it's not crowded,
you well know what I'm talking about.  300 baud HF packet is quite nice
for keyboard to keyboard sessions and lightweight FTP when QRM is minimal.
We have gateways to 15 and 20 meters here on the L.A. duplex packet
repeater, and I route to HF station via these.

If you've had the pleasure of running 10 meter 1200 baud when the band is
open, you realize the potential HF has for packet.

What I'd like to see is:
1. Greatly expanded 300 baud packet frequencies on all low bands.
     We could double our current frequencies by using 1 KHz separation
     and 500 Hz filters in our SSB rigs.  This would greatly help HF
     300 baud congestion.
2. 1200, 2400, 4800, and 9600 baud operation in the phone bands.
     1200 baud AFSK packet uses a top frequency of 2200 Hz, and would
     do just fine on HF SSB.  4800 FSK (_not_ AFSK), using the traditional
     NRZI packet format, has a top frequency of 2400 Hz.  Both of these
     fall easily within the 2700 Hz theoretical passband of SSB voice.
   The k9ng 9600 baud modem could be used with only a little greater
     passband, i.e. 4800 Hz.  Also realize this - even though the k9ng
     modem is operating 8 times faster than a Bell 202 TNC-2 modem, true
     FSK gives the k9ng a significant 15.5 db BER over the AFSK Bell 202!

> .........     I believe that a
> major problem is dis-organisation and sheer ignorance of the people
> involved.  You have alot, maybe hundredes of people all off by up to what,
> maybe 400 hz of each other - and total chaos is the result.

I disagree!!! Check the operation on 14.103, 14.105, 14.107, et al, and
you'll find a remarkable adherance to our unofficial channels.  BTW, if
you do as most TNC manufacturers recommend and use a 500 Hz CW filter,
these 2 KHz slots could easily be cut to 1 KHz spacing with no adverse
effects - in fact, you'd be better off than someone using a 2.3 KHz phone
filter with 2 KHz spacing!  (Try it sometime....)
> ...............           It would not
> be a good idea to involve a whole load of more new people into a mess
> like that.  After using HF packet for a while, I wouldn't be surprised if
> the FCC banned packet radio from HF.  It isn't very efficient is it ?
If you're the one sitting there for a couple of hours trying to get a
half screenful of text through - no.  If you compare the amount of info
that flows on a skinny slot like that with 50 baud AMTOR (yawn) or 45 baud
Racketty teletype (double yawn), that's another story....

> Having said that,  I am not impressed with operations on the VHF
> bands either.  It leaves much to be desired.

Yes it does!  A major improvement could be made if non-MFJ TNC owners
would install $20 DCD state machines in their "alligator" TNC's.  Then they
could run their radios unsquelched, and keyup delay would be minimized.
Also, the modems seem to demod better, if you can believe that.  Perhaps
less garbage from squelch delay and tail???  My IC22A has a squelch that
takes days to open, unless it's set right at the threshold.

> I also realize that there are other problems beyond the control of us
> operators, like not to great of a protocol, one hell of a lot of development
> all at once, etc - but I think the above is important.

Yes -  the biggest problem is using a stinking rotten modem design.  Why
do we insist on limping about with audio tones through a voice radio?
(Yeah, I know it's easier to plug into your voice rig, but getting onto
packet, even ax.25, is not an easy thing, even for us engineers..)
This is lousy at best.  True frequency shift keying has been proven to
work orders of magnitude better!  It's also very easy to implement on
a cheap crystal-controlled radio - just pop a varactor across the transmit
rock!  If the transceiver has a discriminator (most do), pick up demod'd
FSK  directly from the discriminator.  It's easier than Folgers Crystals!
(Pun intentional)
>
>
> I have donned the asbestos armor and am awaiting to hear replys from all you
> lovely people.............

No asbestos necessary - in fact, please rid yourself of said toxic garment.
I think you've raised some quite valid points.  We agree more than not.
>
> Jeff - NR0D

              73, Mike Curtis

  _________________________________________________________________________
 | [e-mail]             | "I  didn't invent the talking machine- |
 | packet [e-mail]   | God did.  I just  made the  first  one |
 |                                | that can be turned off." (-;           |
 | 7921 Wilkinson Avenue          | -Thomas Edison, following several long |
 | North Hollywood CA 91605-2210  | speeches at a banquet in honor of  his |
 | [phone]                 | invention of the phonograph.           |
  -------------------------------------------------------------------------

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

Date: 11 Jul 90 17:02:55 GMT
From: usc!samsung!xylogics!merk!alliant![e-mail]  (Bill Freeman)
Subject: IMHO ???????
To: [e-mail]

In article <[e-mail]>, [e-mail] writes:
> What does IMHO mean?
> -------


It's actually a misspelling.  It should be IMHMO, which stands for, IMHMO:
"In My Humble Missguided Opinion".
--
--
...!{decvax!linus,mit-eddie}!alliant!f          Bill Freeman
alliant![e-mail]         PP-SMEL         KE1G

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

Date: 11 Jul 90 14:40:15 GMT
From: ubc-cs!alberta!adec23![e-mail]  (Mark Salyzyn)
Subject: MFJ-1270 Virus?
To: [e-mail]

Locally, we have had several MFJ-1270's that have had their parameters changed
for no apparent reason. There was a bullitin posted to a distant (300Km) board
that has information about an MFJ Virus. Unfortuneatly when I decided to check
it out, the bullitin was removed from the file system (even tho' the message
subject was still there).

Does anybody have any information about this `possible' back door (by on air
connection) into the TNC to change parameters of the TNC? I am not sure if it
should be posted or e-mailed, I leave that up to the originator to decide.
I'l also accept the judgement that it is an Urban legend and tell the local
boys that they should replace their batteries :-) :-).

Ciao,
73 de VE6MGS/Mark -sk-  alberta!adec23!mark

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

Date: 11 Jul 90 18:17:45 GMT
From: [e-mail]  (Brian Kantor)
Subject: MFJ-1270 Virus?
To: [e-mail]

Golly, I sure hope it's true!  - Because that's the only way I'll ever
be able to get people around here to set MAXFRAME to 1.
    - Brian

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

Date: 11 Jul 90 18:23:24 GMT
From: [e-mail]  (Patty Winter)
Subject: Packet callsign servers (Was: Re: KA9Q package for the Atari ST)
To: [e-mail]

In article <[e-mail]> [e-mail] (Christopher E. Piggott, WZ2B) writes:
>In article <[e-mail]> [e-mail] (Patty Winter) writes:
>>The N6OYU callsign server can be accessed via AX.25 as well as TCP/IP.
>
>Is the software that does this publically accessible, and does it run
>under Unix or DOS?

DOS???!! Perish the thought!! :-)

Doug runs Macintosh systems. The request comes into the Mac that's
on the TCP/IP ham channel, then is routed (via AppleTalk) to another
Mac that has the callsign database. The requested information, obviously,
goes back out the other direction.

Doug has posted details here previously. Perhaps he will do so again.
I think the code is just a modification to the standard Macintosh KA9Q
package, so I expect he'd be happy to make it available to others.


Patty

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

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

Date: 11 Jul 90 17:38:32 GMT
From: usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!stda.jhuapl.edu![e-mail]  (Marshall Jose)
Subject: TR-22 use on packet - two questions
To: [e-mail]

In article <[e-mail]>
[e-mail] (Dana H. Myers) writes:
>
>  I'm interested in hearing from anyone who {is using, has used} a TR-22
>on packet. Specifically, I've heard a few reports of abysmal TXDELAY
>values required for this radio.

I use a TR-22 with a KPC-2/KISS and NOS combination, and have had no problems
with TXDELAY at 25 (250 ms).  Is this abysmal?  Works for me.

The delay may not be in the RF portion, but rather in the mic amplifier.
Those amps usually take some time (~200 ms) to reach their proper bias
point once switched on.  It certainly can't hurt to simply run the mic amp
all the time, so you might give that a try, too.

What I did have problems with was receiver recovery time.  As I recall,
the TR-22's rcvr is muted by practically grounding the squelch transistor
base, causing it to take a long time to recover.  I can't remember what
I changed, but the idea was to reduce the base circuit's time constant.
Works fine now.

Hope this helps,
Marshall Jose  WA3VPZ
[e-mail]  ||  ...mimsy!aplcen!aplvax!mjj

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

Date: 12 Jul 90 00:53:12 GMT
From: bellcore-2!envy![e-mail]  (Phil R. Karn)
Subject: TR-22 use on packet - two questions
To: [e-mail]

In article <[e-mail]>, [e-mail] (Marshall
Jose) writes:
|> What I did have problems with was receiver recovery time.  As I recall,
|> the TR-22's rcvr is muted by practically grounding the squelch transistor
|> base, causing it to take a long time to recover.

Now that you mention it, I seem to recall making a similar mod to the TR-22
I used back when I first got on packet. (Believe it or not, for at least
a year I was only one of three (3) stations on 145.01 in the NNJ/NYC area!)

Anyway, I sold the radio a long time ago, but I seem to remember that I
modified the receiver so that it continued to operate while the transmitter
was on. The TNC heard its own packets, of course, but this didn't bother
anything.

Phil

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

Date: 12 Jul 90 06:11:08 GMT
From: usc!samsung!emory!kd4nc!km4ba![e-mail]  (Alan Barrow)
Subject: Usenet News Feed on Packet?
To: [e-mail]

Maybe I am missing something obvious here, but I don't see what the big deal
is.

I *do* see a strong tendancy for hams to turn into armchair lawyers, and forget
the intent of the regs.

The issue of profanity & "encryption" is an old one. Have any of ya'll seen
the old rtty "pictures" of nude women that used to be the rage on HF?

Were they profane? Most were... Did the violate the regs? nope.

These "profane" images were encoded, not "encrypted" as clever lines
of characters. they did not transmit "dirty" words, so they were ok. I never
heard a case where anyone was told otherwise.

A major magazine publisher brought up the point that hams should now be
sending music over the air.  Oh no, we say!

He goes on to explain that digitally stored music, such as that on a compact
disk, would be legal to send as a file. It is *not* encrypted, it is encoded
in a published format. The intention is that ham radio not be used to
*broadcast* music. Nor is a "cipher" used to obsure meaning or intent.
It is data, nothing more. The intention is met.

An hdlc frame is encoded. I view uuencode, and file compression the same way.
Treat it as a modulation technique. Think about video. It is images "encoded"
to allow transmission in a certain bandwidth.

Let's carry it further... would it be illegal to ftp over packet an executable
that printed out "dirty" words. Or pictures? does this mean I cannot ftp
Leisure suit Larry to my friend. (Copyright discussions aside.)

I don't see how we can prohibit this, yet allow the things that are said on
75, 20, and 2 meters all the time.

I believe the intention of the reg, was that a listener on that frequency
should not hear profanity. Commercial broadcast stations sure play word
games at will, having lots of lewd/"dirty" discussion, with nary a
prohibited word. If we are going to deal with "intent" rather then the
word itself, then SOB, darnit, shoot, etc will all have to go.

I would view batched, compressed usenet feeds in the same light. I would
probabley not include the obvious for-sale groups, but I have a filter
that cleans all the profanity I can think of nicely.

Is it "transmitting profanity"? No.
Is it facilitating "pecuniary" interests. I have not seen any.
Most groups *are* as strict on commercial traffic. filter the *.for-sales
and you get the lion's share.

Oh well, maybe I am confused. I do think hams like to invent stumbling
blocks for ourselves. The "music on hold" autopatch issue comes to mind.
We consider this as prohibited, yet a guy who jammed welfare traffic for
hurricane Hugo is not touched. He stayed within the "letter" of the regs, yet
violated the intent. We were in charleston from Atlanta helping with the
traffic handling. This guy uses his own callsign, was confirmed, yet nothing
happens.

Anyway, those are my (rambling) thoughts. As I ftp a compressed binary over
56k to another ham. (NOS, no dirty words that I know of, except AX.25 :-> I
think I will go wash my mouth out. )

73, quit arguing, and build something! (HW or SW, anything!)

Alan Barrow km4ba

..!gatech!kd4nc!km4ba!alan

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

Date: 11 Jul 90 14:41:28 GMT
From: messy![e-mail]  (Michael O'Dell)
Subject: What's wrong with Internet on radio
To: [e-mail]

As for wanting good, reliable, working email....

hate to break the news, but the Internet world
invented it, and still provides the best,
most ubiquitous service.  sure there are serious
problems (I know - I participated in the effort which
produced RFC-822), but boy, in the world of working,
useful services, it is soooo fine.

so if you really want email that works, having been developed
over 25 years of in-the-field engineering and abuse,
guess what you run???

ax25 ain't it, buster!

    -Mike

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

Date: 11 Jul 90 16:52:29 GMT
From: hayes.fai.alaska.edu!acad3.fai.alaska.edu![e-mail]  (MUNTS PHILLIP A)
Subject: What's wrong with Internet on radio
To: [e-mail]

(I've got to stop poking into hornet nests)

In article <[e-mail]>, [e-mail] (Michael O'Dell) writes...
>As for wanting good, reliable, working email....
>
>hate to break the news, but the Internet world
>invented it, and still provides the best,
>most ubiquitous service.  sure there are serious
>problems (I know - I participated in the effort which
>produced RFC-822), but boy, in the world of working,
>useful services, it is soooo fine.
>
>so if you really want email that works, having been developed
>over 25 years of in-the-field engineering and abuse,
>guess what you run???
>
>ax25 ain't it, buster!
>
>       -Mike

     Yes, but suppose that the various governments stopped paying for the high
speed dedicated lines that Internet runs on?  If everyone on Internet had to
get by with dial-up telephone lines would it still work?  Now let's take away
all the expensive multiuser computers on Internet and give everyone a PC and a
(radio) modem, increasing the number of nodes by a factor of 100.  Would it
still work?  Is TCP/IP still appropriate?  Isn't this what the TCP/IP community
in amateur packet radio wants?  At least think about it.

Philip Munts N7AHL
NRA Extremist, etc.
University of Alaska, Fairbanks

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

Date: 11 Jul 90 19:46:37 GMT
From: messy![e-mail]  (Michael O'Dell)
Subject: What's wrong with Internet on radio
To: [e-mail]

Yes, it still works.  The UUCP world works fine as well, thank you
very much.  Most people have advance beyond 1200 baud to 2400 or
9600 or 19.2Kbaud.  Such modems for phone lines cost $100-$1000, or
less than the average HF radio. (Anyone connected a Trailblazer
over an RF duplex dual-band radio to see how it does???)

As for The Government paying for the lines, things in the Internet
world are changing along those lines and many people are more than
willing to pay for real network service.  Even in the UUCP world,
more than 1200 people or organizations are willing to pay
money for a direct connection to UUNET even when they could get
some of the stuff via a local phone call.

Other than historical (hysterical?) accident, there is no reason
to be using 1200 baud on radio, particularly VHF and UHF.
The first 1200 baud modems were cobbled-up from available parts
(actually surplus Bell 202 modems connected to radio audio connectors).
If they had been 9600 baud units, we'd all be at 9600 baud
and people would be complaining that there's no need for
a megabit, instead of complaining that there's no need for 9600.
So, while the appliance TNCs out there are indeed 1200 baud,
the folks I know who started it all would have never done it that way
if they had forseen it would be so hard to move people forward.
(We've had this conversation many times....)

TCP/IP and telnet, giving your basic AX.25/TNC capability isn't
complex.  In fact, it has been done in a mask-programmable
6502-type ``toaster-controller'' chip designed to plug into a standard
UART socket so an ADM-3A terminal could speak TCP/IP.  Regretably,
this part didn't get to market because the fellow who did it went
off to be chief scientist of a networking company.
So a TCP/TNC *could* be done if people are interested enough
to work on it.

But then that's how packet got started - some enterprising
people were interested enough to DO something, not just
talk about it how what someone else did isn't adequate.

    -Mike
     N4NLN

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

Date: 12 Jul 90 00:47:18 GMT
From: bellcore-2!envy![e-mail]  (Phil R. Karn)
Subject: What's wrong with Internet on radio
To: [e-mail]

It is difficult to respond to many of Phil Munts's comments because
many of them either attack straw men or belie a basic misunderstanding
of the Internet architecture, but I will try.

> Unfortunately the Internet is NOT a good model for packet radio.

A little-known fact: the entire original motivation for the
development of what became TCP/IP was the desire of the DoD to
transparently interconnect the ARPANET with the various DARPA miliary
packet radio nets. This was several years before the invention of
Ethernet (which was itself originally described as "packet radio on a
cable"), so it was only natural that TCP/IP would find wide acceptance
on local area networks. And it is only natural that TCP/IP would
eventually come full circle and be run on amateur packet radio as
well.

I also point out that the other protocol "stacks" that run on
interconnected LANs, e.g., DECNET, XNS, Chaos, Appletalk and OSI, all
share the same basic architecture as TCP/IP. The differences are
mainly in the details. (Of course, it might be more accurate to say
that OSI is unique in that it runs mostly on paper, not LANs, but I
digress...)

> Let me postulate that most NODES on Internet are essentially large
> terminal servers.

This is an incorrect postulation. Almost all nodes on the Internet are
general purpose computers ranging from PCs up to Crays.  The majority
run some variant of UNIX.  Terminal servers are a small fraction of
the hosts on the net.  They provide what is basically a backward
compatibility function that allows existing dumb terminals to do what
they have always done: to log into a remote computer.

But this is not what the Internet was primarily designed to do. The
Internet is a COMPUTER network, not a TERMINAL network. This is a
fundamental issue that is often not grasped by those who try to
compare it with X.25 nets, terminal switches and the like. Many of the
applications supported by the Internet make sense only in the context
of computer-to-computer communication. How does a dumb terminal use a
"file transfer" protocol?

Those who know me know that I long resisted incorporating "terminal
server" functions into my code because I believed that that approach
was architecturally "unclean" and hides much of what the Internet has
to offer. However, recently SM0RGV has added such features to the
mailbox subsystem he contributed to my package. A "plain" AX.25 or
NET/ROM user can connect to NOS and initiate a TCP/IP Telnet
connection over the Internet, and vice versa. I now agree that this
feature is useful in giving regular AX.25 users a small taste of what
a real TCP/IP node can do, hopefully encouraging them to become
full-fledged TCP/IP users.

> Internet ONLY FUNCTIONS BECAUSE MOST USERS
> ARE NOT ACTUALLY CONNECTED TO IT.  A great deal of parallel
> processing is provided by the terminal controllers of the
> various nodes.  This is the only thing that keeps Internet
> from being swamped.  (Sometimes, at least.)

I'm not sure of your point. Are you saying that the use of a terminal
server instead of a computer somehow removes load from the network?
This doesn't make sense.  Terminals servers are merely specialized
Internet hosts that provide a single application, namely remote login.
Personal computers directly attached to the Internet (e.g., a Sun
running SunOS or a PC running NOS) can provide exactly the same
service to their local users.  From the Internet side, these two types
of systems (the terminal server and the PC running Telnet) are
completely indistinguishable.

The difference, however, is that the computer user has the option of
using many other applications besides remote login. Many allow him to
do his tasks much more conveniently AND WITH LESS NETWORK LOADING than
if he were forced to do them across the network on a remote
timesharing system.  For example, a user with a personal computer or
workstation can conduct an email session by transferring his mailbox
file across the network to his local computer where he can read it and
compose replies offline. Then he sends his replies back out in what
are essentially a series of automated file transfer operations.  This
makes *far* more efficient use of the network than the "dumb terminal"
approach.  Not only are all of the user's editing commands kept off
the network entirely, but the data that *is* sent goes out in a few
large packets instead of many small packets.

And most important of all, the user need not sit there and twiddle his
thumbs waiting for each packet to be sent; his PC can receive his mail
before he even sits down to read it, and his replies can go out
automatically after he gets up. I receive all of my PBBS mail via a
TCP/IP relay from NN2Z; it's there with the rest of my Internet mail,
and I compose and send responses in exactly the same way.  I don't
understand how hams can tolerate interactive PBBS operation at 1200
baud. If that were my only choice, I wouldn't bother.

|>         This many-to-one concentration function is simply not
|> technically or politically feasible for packet radio.  We
|> attempted to do it on VHF with half-duplex contention
|> channels but this obviously has been a total failure.  Half-
|> duplex contention is extremely inefficient, and even it it
|> wasn't, the channel bandwidth still has to be divided up
|> among the many users.

Now I think we're getting to the crux of your argument, which is that
the channel access/sharing algorithms we're currently using for
amateur packet radio don't work very well, and that the many-to-many
mode of operation characterized by the Internet protocols aggravate
the problem in comparison to the many-to-one style characterized by
PBBSes. Right?

Well, you're certainly correct on one point: our channel access
algorithms desperately need work. But this issue is completely
independent of what protocols you run at the higher layers! The whole
idea behind a layered protocol architecture is modularity and
interchangeability of the various components. If channel access is the
problem, then fix it! Don't hobble the development of the upper layer
services instead. There are many approaches toward making our shared
channels more efficient: Ethernet-style CSMA/CD through crossband
repeaters that allow stations to detect collisions while transmitting;
Appletalk-style CSMA/CA, which restricts collisions to the small
"request to send" packets that start an exchange, and perhaps even
ARCNET-style token passing or polling. And yes, point-to-point
microwave links such as those being developed by N6GN, N6RCE and N3EUA
also have tremendous potential in certain situations.  Why don't you
lend a hand to this effort so we can find out the relative advantages
and disadvantages of each approach?

It's quite likely that there will be no one clear winner, so we'll end
up with a hybrid network in which different approaches are taken to
different problems. And this is where TCP/IP really shines:
interconnecting dissimilar networks in a way that's transparent to the
applications.

> So we scrap the entire Internet concept of large scale
> terminal concentrators, leaving us with a distributed
> network of peer stations: just what the amateur radio TCP/IP
> community is working on.

Once again, this is a straw man. There is no "internet concept of
large scale terminal concentrators". I had no intention of providing
them in the first place, so there's nothing to scrap. At best, they're
a temporary stopgap provided for backward compatibility with dumb
terminals, or for "marketing purposes" in encouraging more users to
discover why they should get on TCP/IP themselves.

> It's easy to criticize the TCP/IP community but a lot more difficult
> to come up with anything better.

Truer words were never spoken, as the OSI community is only now
discovering.

>         On amateur packet radio, channels are neither permanent
> nor high bandwidth.  Perhaps it is then only reasonable to
> expect a reliable email system, with real time connections
> only possible within limited areas.  TCP/IP is then perhaps
> no longer appropriate and better solutions may be possible.

This doesn't follow. It is entirely true that our channels are
imperfect.  But you forget that this is precisely the kind of
environment for which TCP/IP was originally designed!  Many of the
basic design decisions in TCP/IP, e.g., the choice of the datagram
model and the emphasis on distribution, were driven by the DoD's
desire to keep bits flowing even when nodes on tanks, jeeps and
airplanes move around, get jammed and/or blown up. Our requirements
aren't as dramatic, but the same features make TCP/IP well suited
for the research, commercial and yes, amateur packet radio worlds.

And TCP/IP is certainly more appropriate than the connection-oriented
approaches such as X.25. Of course, even robust, flexible protocols
like TCP/IP can't turn a sow's ear channel into a silk purse. But they
do come close.

> I have to wonder if a really efficient and reliable email
> system would be a lot more useful in the real world of
> amateur packet radio.

Why does TCP/IP preclude your "email system"? Mail is one of the major
uses of the Internet, and not all of it flows directly between
original sender and final destination. The Internet mail system
supports mail relay points called "mail exchangers". These closely
resemble, in principle, the store-and-forward network of amateur
PBBSes, except that the Internet mail protocols are much better
thought out, far more flexible, and more reliable and efficient.

In summary, the Internet is much closer to amateur packet radio than
you might imagine, and it is the best model we have. There certainly
are problems with the lower layers in our packet radio networks, but
solutions exist that do not require that we discard the flexibility
and power of the Internet protocols.

Phil

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

Date: 12 Jul 90 01:25:32 GMT
From: bellcore-2!envy![e-mail]  (Phil R. Karn)
Subject: What's wrong with Internet on radio
To: [e-mail]

In article <[e-mail]>,
[e-mail] (MUNTS PHILLIP A) writes:
> Yes, but suppose that the various governments stopped paying for the high
> speed dedicated lines that Internet runs on?

This is already happening. The various NSFNet regionals are only
partially subsidized by the NSF. JvNCNet, the one Bellcore is
connected to, charges its commercial members their full share of
network costs; only the educational institutions are subsidized. It is
true that the backbone net is still fully funded by the NSF, but this
is likely to change over the next few years. (The backbone net also
accounts for a smaller fraction of the Internet's total cost than you
might think.)

> If everyone on Internet had to get by with dial-up telephone lines
> would it still work?

Certainly not as well. That's why the Internet was built in the first
place, because dialup telephone lines were built for voice, not for
high speed computer-to-computer communication. If everyone had been
happy with UUCP, the Internet would never have happened.

You should also know that the success of the Internet has not gone
unnoticed by the telephone companies. The Switched Multi-Megabit Data
Service (SMDS) is a service concept that would provide "Lan
Interconnection" (the telco term for internetworking) on a commercial
basis. If you're interested, several articles on SMDS by Bellcore and
BOC authors have appeared in the literature.

> Now let's take away all the expensive multiuser computers on Internet
> and give everyone a PC and a (radio) modem, increasing the number of
> nodes by a factor of 100.  Would it still work?  Is TCP/IP still
> appropriate?  Isn't this what the TCP/IP community in amateur packet
> radio wants?  At least think about it.

What's an expensive multiuser computer? There are already several UNIX
systems on my local amateur TCP/IP network, and as prices continue to
drop I expect many more. And you don't need to run UNIX to use TCP/IP;
my code runs under MS-DOS and provides both server and client
facilities.

And given the right mix of radio modems and channel access techniques,
yes, I think we could easily support a 100-fold increase in amateur
packet radio nodes. We won't do it with 1200 baud on 2 meters, though.

Phil

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

Date: 11 Jul 90 23:46:14 GMT
From: hayes.fai.alaska.edu!acad3.fai.alaska.edu![e-mail]  (MUNTS PHILLIP A)
Subject: What's wrong with Internet on radio
To: [e-mail]

[Me]

>> Let me postulate that most NODES on Internet are essentially large
>> terminal servers.

[Karn]

>This is an incorrect postulation. Almost all nodes on the Internet are
>general purpose computers ranging from PCs up to Crays.  The majority
>run some variant of UNIX.  Terminal servers are a small fraction of

[Me again]

     Some clarification is in order.  I was attempting to say that most
users on Internet do not have a dedicated node, with the address, comm
channels, and processing that includes.  Most Internet users log on to big
multiuser systems that are funded by various governments, like the VAX
cluster I am logged onto right now.  I called such a beast a "terminal server"
or "terminal concentrator", because I use very little of its processing
power, while on Internet.  Apologies for bad choice of terminology; as Phil
Karn indirectly points out, these phrases have more specific meanings in the
data communications industry.

     My whole point about the terminal server idea is that Internet may be
more dependant on the few large multiuser systems than we might like to
believe.  What happens when we increase the number of nodes by 100 or 1000?
Even 10000 if we managed to every ham on the planet on TCP/IP packet.  I am
not sure ANY protocol can support a network of 100,000 sparsely connected
peer nodes (nodes that get turned off a random intervals, no less), at least
in real time.  And that's only a tiny percentage of the current ham
population.  (International of course, especially Japan.)  My observations
have been that Internet as is doesn't function at peak times with only a
few hundred (maybe a few thousand by now) nodes.

     Internet may have orignally been intended for radio but what is
currently installed is absolutely dependant (I believe) on the leased lines
and microwave relays that are again paid for by various governments.  To
duplicate this, every ham on packet would have to install at least 2 or 3
dedicated microwave (or VHF/UHF) data links to his near neighbors.  (Here in
Alaska I don't have any near neighbors!)  It seems to me the chance of
finding a clear path and/or frequency for everyone is pretty remote.  And
what about between cities?  And who pays for all this stuff?

     To summarize my argument, I claim (am afraid) that the Internet
architecture depends upon

1.   Large multiuser computers, which are paid for by various government
     agencies.  (A few are also privately owned.)

2.   Dedicated and permanent communication links, which are also funded
     by governments.  (Some are private or donated.)

     for its real-time performance, which is what everybody likes and
expects.  The real-time stuff in TCP/IP is what everybody raves about, but
I am not sure it can deliver on the promise in the amateur packet radio
environment.

     I have never suggested AX.25 is any kind of solution.  My opinion is
that the very idea of shared frequency packet was flawed and that
sharing by contention was even worse.  (I am talking long term solutions
here; 2m AX.25 was and is amazing but it's a dead end).  Putting TCP/IP
on top of it isn't (I believe) going to help very much.

     What I am suggesting is that everyone better prepare to buy a lot of
microwave gear to make TCP/IP work properly, in real time.  This is not
necessarily a bad thing, but it isn't trivial either.

     What we will actually get (I believe) is a system that will only supports
real time TCP/IP operations for small areas and some sort of email to patch
these areas together.  I doubt that we will ever achieve enough connectivity
to allow real time operations over wide geographical and especially rural
areas.  Again, this is not necessarily a bad thing, unless you live in
Alaska.

     To use an analogy, there are still many people here in Alaska
who don't have a telephone (admittedly fewer all the time) but can still
go to the nearest village to get and send mail.  The question is do we build
a fantastic new telephone system connected to only a few big cities or do we
build a fantastic new postal system that everyone can use?  The ideal case
is to build a fantastic new telephone system that goes everywhere but the
world is hardly ideal.

NOTE: Before everyone tries to incinerate me, go back and find all the places
I said "real time."  It is my only real reservation about TCP/IP.  Show me how
we can achieve real time operation over wide areas with it.  I'm not writing
this just to give the TCP/IP people a bad time; I really am concerned (and with
a rural viewpoint).

Philip Munts N7AHL
NRA Extremist, etc.
University of Alaska, Fairbanks

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

Date: 10 Jul 90 18:28:52 GMT
From: crash!simpact!hamavnet![e-mail]
Subject: WWIV
To: [e-mail]

In article <[e-mail]>, [e-mail] (Joey Burgett) writes:
> Ok gents, there is supposed to be a BBS program for the IBM called WWIV, it
> was written by a fellow HAM and was supposed to be intended for packet use as
> well as phone modem use.  I have a copy of WWIV but no where in the docs or
> setup does it even seem to refer to Packet, let alone ham!

Hi there,

I ran a WWIV land line BBS for three years, and I don't think it is meant for
packet use. You could probably get it going, but it wouldn't support store and
forward, none of that is built in.

The guy that wrote it is Wayne Bell, and I believe his callsign is N6PLO. He
runs a BBS himself, at 213-208-6689, probably your best bet would be to call
him direct.

Good luck,

Javier Henderson     | [e-mail]           | These opinions
Engineering Services | Ham Packet: N6VBG @ KD7XG-1      | are all mine.
Avnet Computer       |                                  |

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

End of Packet-Radio Digest
******************************
Date: Fri, 13 Jul 90 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #84
To: packet-radio


Packet-Radio Digest         Fri, 13 Jul 90       Volume 90 : Issue  84

Today's Topics:
            9600bps QAM (v.29) on 440 FM?
              Dove alive on 2m?
              Dumb PK-88 on Mac question
        Help with USENET->Packet feed in early August?
            Network Models (long)
         What's wrong with Internet on radio (2 msgs)
                 WWIV

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests 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".
----------------------------------------------------------------------

Date: 12 Jul 90 21:32:03 GMT
From: uc!nachos.SSESCO.com![e-mail]  (Chris Elmquist)
Subject: 9600bps QAM (v.29) on 440 FM?
To: [e-mail]

I've been toying with the idea (well, I've actually started building)
a v.29 modem using a Rockwell MONOFAX chip for packet use on 440 FM.
I'm wondering if I have ignored any legal issues in running QAM modulation
on a 440 NBFM voice channel??  This thing will connect to a regular TNC
and the MIC and SPKR jacks (or equiv.) of an FM rig...  the theory being
that one can now move 9600bps data over *quality* paths using unmodified
radios. It may not work the best with one for every end-user, but may make
lower-cost, higher-speed backbones easier.

I believe others (in Europe??) have been doing this for awhile...and
I thought I'd give it a try.

Any comments on the legality of 16 point QAM on 440 FM ?

73, Chris  N0JCF

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

Date: 12 Jul 90 13:48:02 GMT
From: shlump.nac.dec.com!e2big.mko.dec.com!anarky.enet.dec.com![e-mail]  (John Brewer)
Subject: Dove alive on 2m?
To: [e-mail]

    Well, has the 2m output on DOVE been activated? I have
been listening the past couple of nights, but have not heard anything.

    /john

+----------------------------------------------------------------+
|John Brewer    WB5OAU           |      [e-mail]  |
|Digital Equipment Corporation   |      [e-mail]    |
|Albuquerque NM                  |      WB5OAU@KN5D              |
+----------------------------------------------------------------+

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

Date: 12 Jul 90 17:24:38 GMT
From: hpl-opus!hpnmdla![e-mail]  (Glenn Elmore)
Subject: Dumb PK-88 on Mac question
To: [e-mail]

If the problem is that the host can talk to the pk88 but the pk88
never talks back in KISS mode you may have been stung by the same
thing that got me on my pk88s.

The bloody RTS line on the pk88 is a FLOATING input!!!

Tie pins 4 and 6 together on the pk88 end and try again.

Hardware flow control is forced on when KISS ON is issued, consequently
this problem may only show up when trying to run KISS modes.


Glenn Elmore -N6GN-

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

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

Date: 12 Jul 90 20:17:36 GMT
From: umigw!rsmas![e-mail]
Subject: Help with USENET->Packet feed in early August?
To: [e-mail]

Well, as long as we're on the topic of Internet<->Packet forwarding again, I
have a request.  I need a volunteer, preferably in the southeast US, to forward
some articles from Usenet to Packet during a short time in August.  Here's the
story.

Starting on 5 August, and continuing through 13-17 August is a bicycle race
called the Race Across AMerica (RAAM).  The RAAM this year takes the riders
from Beaumont, CA through AZ (incl. Flagstaff), UT, CO, NM, TX, LA, MS, AL and
finally finishes up in Savannah, GA.  I will be in SE GA just prior to the
finish & plan to watch some of the finishers arrive in Savannah.

What I need is for someone to forward NEWS items from rec.bike to a packet BBS
in SE GA (yet to be named, as I haven't found a good one to sign into yet).
This way, I can keep up with the news while I travel (packet portable is
great).  In addition, anyone who happens to live along the route & would like
to report on how the race progresses will be welcome.

Anyway, that's the scoop, any volunteers?

73 de Mark
--

C. Mark Eakin
Internet: [e-mail]
Amateur Radio: N4SYK      Packet Radio: [e-mail]
USnail: Univ. of Miami, RSMAS-BLR, 4600 Rickenbacker Cswy. Miami, FL 33149-1098

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

Date: 12 Jul 90 20:26:39 GMT
From: usc!sdd.hp.com!zaphod.mps.ohio-state.edu!sunybcs![e-mail]  (Devon E Bowen)
Subject: Network Models (long)
To: [e-mail]

At the risk of stirring things up again (sorry, I'm just catching up on
news from the last few weeks and I missed this)...

In article <[e-mail]>, [e-mail] ( VTC) writes:
> I fail to see what the big stink over C64's running TCP is. I think it could
> be done.

It can be done. KB2GZD and I have a working foundation for TCP (meaning
that the foundation is working... not TCP yet). It is receiving and replying
to ARP packets but that is is high as we've gotten. Not because it is too
difficult but because of time constrictions. All of my free time lately
has been going to a BSD port (no, not to the c64) and to programming the
GLB PK1-L TNC for KISS. We could probably have it routing and pinging in
a matter of weeks when we get moving again. Hopefully that will be soon.

> Frankly, if someone comes up with
> a telnet or ftp client, Ill pull mine out of the closet.  Be sure to make
> it compatible with Digicomm.

Sorry. We don't have that kind of time (what the hell am I saying? I don't
have any kind of time). We didn't even want to deal with their rs-232
routines, so we've built a small 6551 UART off of the expansion bus. You
will have to add this and a KISS TNC to run our stuff. The advantage to
having the 6551 is that we think we can push it to 9600 baud. Of course,
if someone else would like to add Digicom...

Devon

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

Date: 12 Jul 90 20:39:04 GMT
From: bellcore-2!envy![e-mail]  (Phil R. Karn)
Subject: What's wrong with Internet on radio
To: [e-mail]

In article <[e-mail]>,
[e-mail] (MUNTS PHILLIP A) writes:
>      Some clarification is in order.  I was attempting to say that most
> users on Internet do not have a dedicated node, with the address, comm
> channels, and processing that includes.  Most Internet users log on to big
> multiuser systems that are funded by various governments, like the VAX
> cluster I am logged onto right now.  I called such a beast a "terminal
server"
> or "terminal concentrator", because I use very little of its processing
> power, while on Internet.

I do not agree. It's certainly not true where I work; almost everyone
has a Sun, Decstation or PC that is connected directly to the local
Ethernet. I'm sure I could point to many other commercial and academic
organizations who have similar setups. It is true that many of our
users use the multiuser systems when they should offload their
operations to their much more cost-effective workstations; as you say,
such operations make very little use of the big multiuser system's
processing power.  But this is user inertia, not a fault of the
Internet architecture.  And in our case, none of our "big multiuser
systems" are funded by the government.

It was my exposure to the environment I have at work that motivated me
to bring something similar to amateur radio, albeit scaled down to run
on PC hardware that is affordable by individuals.

>      My whole point about the terminal server idea is that Internet may be
> more dependant on the few large multiuser systems than we might like to
> believe.

This is simply not true. More than anything else, the Internet has
made possible (and accelerated) the decentralization of computing
power and data storage.

> I am not sure ANY protocol can support a network of 100,000 sparsely
> connected peer nodes (nodes that get turned off a random intervals, no
> less), at least in real time.

The Internet is already estimated to include several hundred thousand
nodes, and it is growing rapidly. If you are referring specifically to
amateur packet radio, where our links are greatly limited in speed and
scope, you may be right. But this can hardly be blamed on the Internet
protocols.

>      Internet may have orignally been intended for radio but what is
> currently installed is absolutely dependant (I believe) on the leased lines
> and microwave relays that are again paid for by various governments.

The Internet spans an extremely wide range of media, ranging from
privately-owned local area Ethernets, token rings and the like up to
shared, long haul point-to-point links.  This is precisely what makes
it so successful: because each transmission medium has its own
advantages and disadvantages, no one LAN or WAN technology is always
superior.  Yet this collection of disparate LANs and WANs must appear
as one seamless, transparent network in order to be truly useful to
its users. This is precisely what TCP/IP was designed to do.

> I have never suggested AX.25 is any kind of solution.  My opinion is
> that the very idea of shared frequency packet was flawed and that
> sharing by contention was even worse.

You and N6GN ought to get along just fine. However, instead of
complaining, he's doing something about it -- he's developing those
nifty low-cost digital microwave radios.

> I said "real time."  It is my only real reservation about TCP/IP.  Show me
> how we can achieve real time operation over wide areas with it.

You're attacking another straw man here.  OBVIOUSLY no protocol,
TCP/IP included, can give you real time service if there are no real
time links over which to run it! My point is that TCP/IP is the best tool
for making the best of the non-real-time links that we do have. And it
provides a stable platform for new real-time services if the links ever
do become available.

I strongly suggest that you read up on the Internet architecture and
get some more experience in using it. An excellent place to start is
the book "Internetworking with TCP/IP: Principles, Protocols and
Architecture" by Douglas Comer. It is published by Prentice Hall and
has ISBN 0-13-470154-2.

Phil

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

Date: 12 Jul 90 18:10:15 GMT
From: hpl-opus!hpnmdla![e-mail]  (Glenn Elmore)
Subject: What's wrong with Internet on radio
To: [e-mail]

Philip Munts N7AHL writes:

>      Internet may have orignally been intended for radio but what is
> currently installed is absolutely dependant (I believe) on the leased lines
> and microwave relays that are again paid for by various governments.  To
> duplicate this, every ham on packet would have to install at least 2 or 3
> dedicated microwave (or VHF/UHF) data links to his near neighbors.  (Here in

No, just one link to a neighbor or a cluster server. Only the server
need have a backbone connection. This is exactly what
we are building right now to prototype a .25 Mbaud network here in
norther California. See the recent QEX/Gateway description of prototype
radio performance.   Parts cost is no more than that of a typical 2M
nbfm radio.
  The high performance solutions (>1-2 Mbps) *will* almost certainly
require dedicated pt-pt hardware, at least 1/user at both user and
server ends. See comment below about co$t.

> Alaska I don't have any near neighbors!)  It seems to me the chance of
> finding a clear path and/or frequency for everyone is pretty remote.  And
> what about between cities?  And who pays for all this stuff?

There is no question that higher performance requires higher quality
links. As the phone company's example shows this may translate to
a number of (hopefully shorter) intermediate hops as part of a backbone
to interconnect separated rural areas. Rural America didn't get
connected to a power grid immediately either...
  Who pays for your local repeater? Around here it is the local club(s).
To be interesting this must includ not only support for local users
but also connections to a backbone. The tremendous advantage of backbone
hardware over a  nbfm (omni) station is that you have antenna gain
working for you. There is clear incentive to interconnect local areas
with a backbone and two clubs, each supporting half an interconnecting
backbone, both stand to gain from the connection.


> 2.   Dedicated and permanent communication links, which are also funded
>      by governments.  (Some are private or donated.)

I don't think this has to be the case any more than local nbfm repeaters
are funded by governments...

>      for its real-time performance, which is what everybody likes and
> expects.  The real-time stuff in TCP/IP is what everybody raves about, but
> I am not sure it can deliver on the promise in the amateur packet radio
> environment.

I don't think it can deliver it immediately to *all* amateurs either. We
do have to start in areas which have sufficient critical mass of
interested (and willing-to-contribute) amateurs. However, I think the
bigger problems are organizational and not technical or even economic,
per se.

>      I have never suggested AX.25 is any kind of solution.  My opinion is
> that the very idea of shared frequency packet was flawed and that
> sharing by contention was even worse.  (I am talking long term solutions
> here; 2m AX.25 was and is amazing but it's a dead end).  Putting TCP/IP
> on top of it isn't (I believe) going to help very much.

I agree. I'm putting together a CNC paper related to physical/link layer
design for optimum use of amateur resources right now. If I get it done,
you can see if it makes sense to you after Sept. 22. However, as Phil (ka9q)
mentioned, TCP isn't the problem, crummy physical/link layer is!
Point-point hardware and supporting protocols are absolutely necessary.


>      What I am suggesting is that everyone better prepare to buy a lot of
> microwave gear to make TCP/IP work properly, in real time.  This is not
> necessarily a bad thing, but it isn't trivial either.

It's not a lot! We had better be prepared to build a network interconnected
with point-point and LOS links but THE HARDWARE IS NOT EXPENSIVE or even
particularly difficult.
  There are different potential levels of performance based on the quality
of a link in terms of energy transfer. If you want high speed you have
to be prepared to get KTB + 20 dB (or something) power in your
signalling bandwith. If you have long, non-LOS links you will not get this
kind of performance. Maybe remote Alaska is not going to be running
fast scan digital TV for a while. However, a few inexpensive LOS links
may very well serve to connect even remote users at fairly interesting
data rates.
  The radio side of the 10 GHz data link we showed in  Dec. '89 HR Mag actually
will run at about 8 Mbps. That for about $100/end in parts, antenna included.
Yes 10 hops does divide the effective rate down below 1 MBps, but that is
still fast enough for some new and  interesting applications, real time.
  The intermediate speed solution we are working on has potential for
working over limited non-LOS paths. As the phone company hardware shows though,
high performance (low downtime, high info bandwidth) demands well controlled
(shorter) LOS links.

>      What we will actually get (I believe) is a system that will only supports
> real time TCP/IP operations for small areas and some sort of email to patch
> these areas together.  I doubt that we will ever achieve enough connectivity
> to allow real time operations over wide geographical and especially rural
> areas.  Again, this is not necessarily a bad thing, unless you live in
> Alaska.

I'm not so pessimistic about the technology. Whether amateurs can cooperate
enough to make it happen is another question. I don't think we will have
world wide X-windows to every amateur any time soon but a few geostationary
satellite transponders might do wonders toward supporting real time,
moderate data rate applications across large geographic spans.

> NOTE: Before everyone tries to incinerate me, go back and find all the places
>I said "real time."  It is my only real reservation about TCP/IP.  Show me how
> we can achieve real time operation over wide areas with it.  I'm not writing
>this just to give the TCP/IP people a bad time; I really am concerned (and with
> a rural viewpoint).

If a few of us find time to get things written in the midst of trying to
get northern California connected at 250 Kbps, we hope to have some
related text in the next CNC.

  I'm really concerned too, I even have a rural viewpoint (to a degree anyway,
Santa Rosa is *not* (yet) part of Si Valley).

Glenn Elmore -N6GN-

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

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

Date: 12 Jul 90 15:44:14 GMT
From: bacchus.pa.dec.com!jumbo![e-mail]  (Ed Satterthwaite)
Subject: WWIV
To: [e-mail]

In article <[e-mail]>, [e-mail] writes:
> ...
> The guy that wrote it is Wayne Bell, and I believe his callsign is N6PLO. He
> ...

If it is, the FCC messed up.  I've gotten my own name back from the
callbook, callsign servers, etc.

Ed, n6plo

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

End of Packet-Radio Digest
******************************
Date: Sat, 14 Jul 90 04:30:02 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #85
To: packet-radio


Packet-Radio Digest         Sat, 14 Jul 90       Volume 90 : Issue  85

Today's Topics:
               160 Meter QAM Earth Wave
            9600bps QAM (v.29) on 440 FM?
   Packet callsign servers (Was: Re: KA9Q package for the Atari ST)
             TNC-2 bootstrap rom: works?
             Usenet News Feed on Packet?

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests 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".
----------------------------------------------------------------------

Date: Fri, 13 Jul 90 12:20:20 +0600
From: [e-mail]
Subject: 160 Meter QAM Earth Wave
To: [e-mail]

Chris Elmquist's question about the legality of 16-point QAM on 440 MHz reminded
me of a related question.  I read an article about someone who was experimenting
with SSB 160 meter earth wave operation (that's right, underground antennas).
As I recall, the author mentioned that signals propogated over substantial
distances and that the signal to noise ratio was incredibly good.

Ever since, I've been wondering about the possibility of packet operation with
QAM on 160 earth wave.  With a good enough signal to noise ratio, it should be
possible to get at least 4800 BPS without exceding the 300 baud FCC "speed
limit."

Would an STA be required to even experiment with this?  I'd appreciate any
comments on the technical or legal problems I'm likely to run into.

Thanks,

    Bob Van Valzah  [e-mail]  sun!laidbak!bob  [phone] x260

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

Date: 13 Jul 90 18:16:41 GMT
From: bellcore-2!envy![e-mail]  (Phil R. Karn)
Subject: 9600bps QAM (v.29) on 440 FM?
To: [e-mail]

In article <[e-mail]>, [e-mail] (Chris
Elmquist) writes:
|> I'm wondering if I have ignored any legal issues in running QAM modulation
|> on a 440 NBFM voice channel??

I see absolutely no problem. The rules are quite clear in granting you
the privilege of using any modulation scheme you want in domestic
communications as long as it fits within the bandwidth limits for the
frequency band in use. The bandwidth limit for 440 MHz is 100 KHz, and
since you said you will be using standard voice radios I don't see
that you'll have any trouble meeting this requirement.

Phil

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

Date: 12 Jul 90 12:56:01 GMT
From: zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!peregrine!ccicpg!cci632![e-mail]  ( co-op)
Subject: Packet callsign servers (Was: Re: KA9Q package for the Atari ST)
To: [e-mail]

In article <[e-mail]> [e-mail] (Patty Winter) writes:
>In article <[e-mail]> [e-mail] (Christopher E. Piggott, WZ2B) writes:
>>In article <[e-mail]> [e-mail] (Patty Winter) writes:
>>Is the software that does this publically accessible, and does it run
>>under Unix or DOS?
>
>DOS???!! Perish the thought!! :-)

Well...the reason I asked ...

It seems like a neat idea (which hadn't occured to me) to incorporate
a callsign server into either fingerd (if you're running 'nix) or KA9Q
(if you're under something else)...IP users could look you up in the
callsign database simply by fingering you, and AX.25'ers could use the
NOS gateway stuff to do the same.  You wouldn't need any outside client
software to do so.

I'm interested in doing it.  Only problem is, I've never written any
code to live under KA9Q, and I'm frankly quite intimidated at the
thought.  Maybe it won't be so scary once I actually get started. :)

Chris

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

Date: 13 Jul 90 13:05:12 GMT
From: rochester!rit!cci632![e-mail]  ( co-op)
Subject: TNC-2 bootstrap rom: works?
To: [e-mail]

I recently burned the EPROM that comes in the TNC_TNC2 archive.  It
is SUPPOSED to allow me to upload intel hex ercords to the TNC-2,
but it does not work.  Nor does it echo back all bytes sent to it
on startup.

I'm using an MFJ-1274 - anybody have any thoughts on what the problem
may be?  It simply freezes, with both lamps on.

Chris

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

Date: 14 Jul 90 07:26:00 GMT
From: swrinde!zaphod.mps.ohio-state.edu!maverick.ksu.ksu.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu![e-mail]
Subject: Usenet News Feed on Packet?
To: [e-mail]

> I *do* see a strong tendancy for hams to turn into armchair lawyers, and forget
> the intent of the regs.

Many times, agreements are reached between parties having entirely
opposite intends.  Intend is not always clear.

> The issue of profanity & "encryption" is an old one. Have any of ya'll seen
> the old rtty "pictures" of nude women that used to be the rage on HF?
>
> Were they profane? Most were... Did the violate the regs? nope.

Back then, maybe not.  Today they could violate the US CODE.  I've read,
but forgot where, that section is.

> These "profane" images were encoded, not "encrypted" as clever lines
> of characters. they did not transmit "dirty" words, so they were ok. I never
> heard a case where anyone was told otherwise.

Before the "sexual revolution" a little bit of this was healthy and people
just accepted it.  Today there is so much we have people fighting against
it, and they go crazy with everything.

> A major magazine publisher brought up the point that hams should now be
> sending music over the air.  Oh no, we say!
>
> He goes on to explain that digitally stored music, such as that on a compact
> disk, would be legal to send as a file. It is *not* encrypted, it is encoded
> in a published format. The intention is that ham radio not be used to
> *broadcast* music. Nor is a "cipher" used to obsure meaning or intent.
> It is data, nothing more. The intention is met.

You and I actually agree on the intent, but not on how law works.  Since the
intention is not codified, you will have to bring it up as an argument in
your hearing.  Maybe the judge will accept it.  Maybe he will buy the OTHER
side's version of "intent".  Hopefully no one will complain, and the FCC is
too busy to chase it.

> An hdlc frame is encoded. I view uuencode, and file compression the same way.
> Treat it as a modulation technique. Think about video. It is images "encoded"
> to allow transmission in a certain bandwidth.

There is nothing wrong with encoding schemes.

> Let's carry it further... would it be illegal to ftp over packet an executable
> that printed out "dirty" words. Or pictures? does this mean I cannot ftp
> Leisure suit Larry to my friend. (Copyright discussions aside.)

That depends.  I see the "dirty" words as a problem.

> I don't see how we can prohibit this, yet allow the things that are said on
> 75, 20, and 2 meters all the time.

That is the difference between what is law and what is enforced.  Clearly,
enforcement has a major problem.

> I believe the intention of the reg, was that a listener on that frequency
> should not hear profanity. Commercial broadcast stations sure play word
> games at will, having lots of lewd/"dirty" discussion, with nary a
> prohibited word. If we are going to deal with "intent" rather then the
> word itself, then SOB, darnit, shoot, etc will all have to go.

Maybe I need to find that section of the US CODE and quote it on the net.
It might SCARE you on what CAN be enforced.  We are talking about MORE
than just 7 words.

> I would view batched, compressed usenet feeds in the same light. I would
> probabley not include the obvious for-sale groups, but I have a filter
> that cleans all the profanity I can think of nicely.

Shall I test your filter sometime?

> Oh well, maybe I am confused. I do think hams like to invent stumbling
> blocks for ourselves. The "music on hold" autopatch issue comes to mind.
> We consider this as prohibited, yet a guy who jammed welfare traffic for
> hurricane Hugo is not touched. He stayed within the "letter" of the regs, yet
> violated the intent. We were in charleston from Atlanta helping with the
> traffic handling. This guy uses his own callsign, was confirmed, yet nothing
> happens.

There are other ways to deal with him (not necessarily legal).

> Anyway, those are my (rambling) thoughts. As I ftp a compressed binary over
> 56k to another ham. (NOS, no dirty words that I know of, except AX.25 :-> I
> think I will go wash my mouth out. )

We can ask Congress to prohibit "AX.25" over all broadcast media.  That should
get the point across.  :-)

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

End of Packet-Radio Digest
******************************
Date: Sun, 15 Jul 90 04:30:04 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #86
To: packet-radio


Packet-Radio Digest         Sun, 15 Jul 90       Volume 90 : Issue  86

Today's Topics:
       Callsign sever in KA9Q (was Re: Packet callsign servers)
              Ham Radio Magazine
             TNC-2 download eprom
         What's wrong with Internet on radio

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests 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".
----------------------------------------------------------------------

Date: 15 Jul 90 00:27:12 GMT
From: [e-mail]  (Patty Winter)
Subject: Callsign sever in KA9Q (was Re: Packet callsign servers)
To: [e-mail]

In article <[e-mail]> [e-mail] (Christopher E. Piggott, WZ2B) writes:
>It seems like a neat idea (which hadn't occured to me) to incorporate
>a callsign server into either fingerd (if you're running 'nix) or KA9Q
>(if you're under something else)...IP users could look you up in the
>callsign database simply by fingering you, and AX.25'ers could use the
>NOS gateway stuff to do the same.  You wouldn't need any outside client
>software to do so.

Chris--

Forgive me if I'm repeating what I said a few postings ago; I can't
remember exactly where this discussion started. :-)

Anway, if I didn't make it clear before, let me do it now. Doug Thom's
callsign server IS available via both TCP/IP and AX.25. TCP users simply
type "%finger callsign@n6oyu". AX.25 users do a normal connect to N6OYU,
then use the inquire command: "i callsign". No special software is
required by either set of users.

You could contact him ([e-mail]) to find out more about the C
code that parses the incoming request and sends it out the AppleTalk
link to the machine holding the database. (Instead of doing a lookup
on the host machine itself, as a normal finger command would do.)
Although Doug has his system trained to speak AppleTalk and go to
another machine to grab the information, I expect you could adapt it
for whatever situation you have.


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

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

Date: 14 Jul 90 14:52:09 GMT
From: news!cartan!ndmath!nstar!w8grt![e-mail]  (Jim Grubs)
Subject: Ham Radio Magazine
To: [e-mail]

I just got a call from Terry Northup, the editor of the now-defunct HAM
RADIO magazine. She says:

(1) 3 of the articles in the July issue of CQ were in fact originally
accepted by HAM RADIO;

(2) the HAM RADIO presence in CQ is going to increase considerably;
there will be more technical items, and they will even go through the
HAM RADIO editorial office in New Hampshire, which will remain open.

Hmmm, could we persuade 'em to start their magazine back up, before it
dies out completely?  It seems to be lingering...

--
  |\/\/\/|
  |      | Jim Grubs, W8GRT - aka FidoNet node 1:234/1
  | (o)(o) UUCP: {ncar!asuvax!stjhmc!,iuvax!ndmath!nstar}!w8grt!jim.grubs
  |     _) INTERNET: [e-mail]
  | ,___|  ____________________________________________
  |   /     "I wanna go to the ham radio National Park
 /____\          of the Mind and ride the NOS!"

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

Date: Sat, 14 Jul 90 13:12:53 -0700
From: Mike Chepponis <[e-mail]>
Subject: TNC-2 download eprom
To: [e-mail]

When I wrote this code eons ago, I did it to give me a way to test kiss code
without burning an eprom every time.  Therefore, this code is quite quick
and dirty.  It does work, though!  As I recall, if you type Control-E the
codes prints out a version banner at you.  This was handy because it made
sure that you had the correct baud rate.  It also assumes 8 bits no parity.
Also, as I recall, it does not check the checksum byte on Intel .hex file
downloads, because I couldn't figure out what to do when such an error
happened!

I believe the source code is in the same archive.  You can look at that to see
what it does in detail.

Best -Mike K3MC

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

Date: 14 Jul 90 21:52:12 GMT
From: cs.utexas.edu!texbell!helps!bongo![e-mail]  (Julian Macassey)
Subject: What's wrong with Internet on radio
To: [e-mail]

In article <[e-mail]>, [e-mail] (Phil R. Karn) writes:
>
>
> I do not agree. It's certainly not true where I work; almost everyone
> has a Sun, Decstation or PC that is connected directly to the local
> Ethernet. I'm sure I could point to many other commercial and academic
> organizations who have similar setups.

    How about this for a commercial application: I sometimes work in a
lawyers office which consists of a several dozen Suns. The sight of
all those Sun 2s with legal documents on their screens is a sight to
behold. It is also much more fun than all dull PCs running
Wordimperfect which is what most ambulance chasers use.


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

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

End of Packet-Radio Digest
******************************
Date: Mon, 16 Jul 90 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #87
To: packet-radio


Packet-Radio Digest         Mon, 16 Jul 90       Volume 90 : Issue  87

Today's Topics:
            9600bps QAM (v.29) on 440 FM?
                 Signing Off

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests 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".
----------------------------------------------------------------------

Date: 16 Jul 90 06:18:50 GMT
From: portal!cup.portal.com![e-mail]
Subject: 9600bps QAM (v.29) on 440 FM?
To: [e-mail]

i am very interested in anyone that has used the yamaha7109 fax ic or
rockwell chip set for transmission via radio. any software or schematics
the rockwell will train on data where as the yamaha fax ic must have
equalizer values pre-set i belive.any help will be much appreciated.
norm gillaspie
iss eng
415-967-0833

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

Date: Sun Jan  4 06:30:08 1970
From: [e-mail]
Subject: Signing Off
To: [e-mail]

Dear Friends,

Please sign me off the I-PACRAD board.  I'm changing employment and this
address will no longer be valid.

Thanx

David M Stein


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

End of Packet-Radio Digest
******************************
Date: Tue, 17 Jul 90 04:30:04 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #88
To: packet-radio


Packet-Radio Digest         Tue, 17 Jul 90       Volume 90 : Issue  88

Today's Topics:
             Running a PC on 12V
         What's wrong with Internet on radio
                 WWIV

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests 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".
----------------------------------------------------------------------

Date: 17 Jul 90 01:11:15 GMT
From: pacbell.com!tandem!moe![e-mail]  (Kevin J. Rowett)
Subject: Running a PC on 12V
To: [e-mail]

In article <[e-mail]>, [e-mail] (David J Bell) writes:
|> Doug, you should have very little trouble, as far as I can see...
|>
|> The drive motors operate off 12V (the car is a little hot for that, but
|> it really *shouldn't* be a problem), and the electronics requires both

Be wary of hooking to the +12V DC rail in a automotives electrical
system.  The gotcha is load dump.  With a very heavy discharged battery,
the alternator will be putting out plenty of current.  If you hit a bump
and the battery cable jumps around, you'll see the output dumped back
into the +12VDC rail.  Of course, the regulator will dampen the voltage
swing, but it's feedback has a slow time constant compared to that of
the silicon in a PC.

N6RCE

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

Date: 16 Jul 90 21:10:10 GMT
From: philmtl!atha![e-mail]  (Lyndon Nerenberg)
Subject: What's wrong with Internet on radio
To: [e-mail]

[e-mail] writes:
>     My whole point about the terminal server idea is that Internet may be
>more dependant on the few large multiuser systems than we might like to
>believe.  What happens when we increase the number of nodes by 100 or 1000?
>Even 10000 if we managed to every ham on the planet on TCP/IP packet.  I am
>not sure ANY protocol can support a network of 100,000 sparsely connected
>peer nodes (nodes that get turned off a random intervals, no less), at least
>in real time.

Isn't the current estimate for the number of connected nodes on the Internet
around 100K already? The NSFnet backbone bandwidth is increasing fast enough
to handle another 100K nodes if need be.

>     Internet may have orignally been intended for radio but what is
>currently installed is absolutely dependant (I believe) on the leased lines
>and microwave relays that are again paid for by various governments.

Yes, the Internet, as a specific functional model defined by the current
group of connected national and regional networks, is heavily dependent
on leased lines and PTP links. That does not mean that the internet MODEL
is.

>     To summarize my argument, I claim (am afraid) that the Internet
>architecture depends upon
>1.   Large multiuser computers, which are paid for by various government
>     agencies.  (A few are also privately owned.)
>2.   Dedicated and permanent communication links, which are also funded
>     by governments.  (Some are private or donated.)

OK, I'm nitpicking over terminology here ... the Internet (capital I) is
a production networks that exists to support reaearch (in theory at least :-)
The environment used by these researchers leans towards big mainframes
for the most part, although that is changing. How the network is used
doesn't have much bearing (in this case, anyway) on how the network is
capable of being used in a different environment. AMPRnet, by its very
nature, will not look a lot like the Internet, since the model of large
mainframes accessed by many users is not applicable to the end user
applications that will be running over it. Instead, you will find a
much more distributed environment. How we use the network at the
applications layer doesn't change the fact that TCP/IP is still an
excellent choice for the transport layer of the network (AMPRnet).

--
     Lyndon Nerenberg  VE6BBM / Computing Services / Athabasca University
     {alberta,cbmvax,mips}!atha!lyndon || [e-mail]
               Practice Safe Government
                 Use Kingdoms

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

Date: 16 Jul 90 14:07:58 GMT
From: zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!helios![e-mail]  (William Gunshannon)
Subject: WWIV
To: [e-mail]

Try N6PLU!!  That's the correct callsign according to MARVIN.CS.BUFFALO.EDU.

bill  KB3YV

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

End of Packet-Radio Digest
******************************
Date: Wed, 18 Jul 90 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #89
To: packet-radio


Packet-Radio Digest         Wed, 18 Jul 90       Volume 90 : Issue  89

Today's Topics:
         2 meters (144Mhz band) and wet trees
           Kantronix DataEngine & 9600 baud
             Pac-Radio Dealer/Manuf addr
             Running a PC on 12V

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests 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".
----------------------------------------------------------------------

Date: 17 Jul 90 16:31:45 GMT
From: swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!stda.jhuapl.edu![e-mail]  (Marshall Jose)
Subject: 2 meters (144Mhz band) and wet trees
To: [e-mail]

In article <[e-mail]>
   [e-mail] (Robert Casey) writes:

>Is the
>attenuation of wet tree leaves significant at 145Mhz?  Lot more than
>the same trees dry?  And without leaves (ie, winter)?  I thought this
>sort of thing was only significant up in the microwave freqs.
>

YES! Rainwater coating the leaves and the bark of trees is slightly
conductive.  Further, the length of branches and leaves is comparable
to a wavelength at VHF.  VHF E-M waves passing "through" a wet tree
will be very slightly attenuated, and they will surely be knocked down
quite a bit if several wet trees are along your radio link path.

The effect becomes quite pronounced at higher frequencies, such that
at frequencies of 1 GHz and higher, leaves (wet or dry) are opaque.

Another note:  Acid rain has higher conductivity than "clean" rain, and
contributes even more to the attenuation.

Marshall Jose  WA3VPZ
[e-mail]  ||  ...mimsy!aplcen!aplvax!mjj

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

Date: 17 Jul 90 13:39:43 GMT
From: usc!snorkelwacker!bu.edu!mirror!necntc!necis![e-mail]  ( NM1D)
Subject: Kantronix DataEngine & 9600 baud
To: [e-mail]

I just thought someone would be interested....


   I recently (this past Saturday) saw my first Kantronix Data Engine....
It looks very nice... good construction.... and Kantronix is promising full
documentation as they hope it will become a popular "open architechure"
standard.

   The most interesting thing about the demo was that they had their 9600
baud modem installed, and were demonstrating its use (I believe they said
it was based on the G3RUH design).   Will this be the first company to have
mass produced 9600 baud TNC SYSTEMS available to the average ham packeteer??

   They were using the Kantronix DVR-2-2 radios (what else?), and they
promised "plug&play" (oh no.... 9600 baud apliance operators)!!!



   Well, I was impressed, the system looks flexible, and complete.  If they
could just get the system price down to $50.00!!! :-)


    Rich

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

Date: 17 Jul 90 13:00 GMT
From: "Disini SW, Emmanuel Disini,PRT" <[e-mail]>
Subject: Pac-Radio Dealer/Manuf addr
To: [e-mail]

greetings. just wondering if there are any packet radio manufacturers out there
on the Net somewhere? I'm interested in setting up a multi-line E-Mail system
so that users can receive news and correspond via TNCs.  <The phone line system
in Manila is *REALLY* bad.>  Is there a compact VHF radio - TNC package that
one can just attach to a LapTop?

Sincerely,
Joel Disini
Manila, Philippines
[e-mail]

PS

Please send all mail to me directly, as I haven't subscribed to your group!




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

Date: 17 Jul 90 16:02:31 GMT
From: microsoft![e-mail]  (James THIELE)
Subject: Running a PC on 12V
To: [e-mail]

In article <[e-mail]> [e-mail] writes:
>
>In article <[e-mail]>, [e-mail] (David J Bell) writes:
||> Doug, you should have very little trouble, as far as I can see...

Sounds like someone who hasn't tried it.

||>
||> The drive motors operate off 12V (the car is a little hot for that, but
||> it really *shouldn't* be a problem),

But it is.  A very fine EE consultant I know had a lot of trouble
with this, and he only needed +5V.  The transients are terrible,
due in part to various inductive loads (for instance, wiper motors).
As an experiment, put a scope on your +12 when you use your horn.

Or consider...

|
|Be wary of hooking to the +12V DC rail in a automotives electrical
|system.  The gotcha is load dump.  With a very heavy discharged battery,
|the alternator will be putting out plenty of current.  If you hit a bump
|and the battery cable jumps around, you'll see the output dumped back
|into the +12VDC rail.  Of course, the regulator will dampen the voltage
|swing, but it's feedback has a slow time constant compared to that of
|the silicon in a PC.
|
|N6RCE

As implied by the previous parts of this message you probably will have
big problems.  There is tons of noise in a car's electical system,
and the +12V in your computer is used to a regulated source.  You'll
need to isolate your computer from the car's electrical system.

If anyone knows a simple and reliable method of doing this, other
than using a seperate battery [:-(] I'd love to hear it.

James Thiele -- microsoft!jamesth

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

End of Packet-Radio Digest
******************************
Date: Thu, 19 Jul 90 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #90
To: packet-radio


Packet-Radio Digest         Thu, 19 Jul 90       Volume 90 : Issue  90

Today's Topics:
         How to access the Amateur Radio BBS
             Running a PC on 12V (3 msgs)
               Source for NOS?
               W0RLI Mailbox in US ???

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests 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".
----------------------------------------------------------------------

Date: 18 Jul 90 20:18:29 GMT
From: usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!wb3ffv![e-mail]  ( WB3FFV)
Subject: How to access the Amateur Radio BBS
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.0.1 {wb3ffv.ampr.org}  [for FTP access on 145.550 mhz ONLY]
 Misc. Info: Machine is an 80386 computer running UNIX V.3.2 and features 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)
 WA7MBL BBS for the PC (Versions 3.31, 4.31 & 5.12)
 W0RLI BBS for the PC (Versions 6.xx, 7.xx, 8.xx, 9.xx, 10.xx)
 MSYS BBS for the PC running KISS TNC's  (Version 1.07 & 1.08)
 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...

*** I will also be trying to allow dialup SLIP in the very near future, so
    users of the KA9Q software can actually use the package to access my
    system.  If anybody is interested in helping me test this option, please
    let me know...

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

Date: 18 Jul 90 18:25:32 GMT
From: mejac!orchard.la.locus.com!prodnet.la.locus.com!lando.la.locus.com![e-mail]  (Dana H. Myers)
Subject: Running a PC on 12V
To: [e-mail]

In article <[e-mail]> [e-mail] (James THIELE) writes:
>||>
>||> The drive motors operate off 12V (the car is a little hot for that, but
>||> it really *shouldn't* be a problem),
>
>But it is.  A very fine EE consultant I know had a lot of trouble
>with this, and he only needed +5V.  The transients are terrible,
>due in part to various inductive loads (for instance, wiper motors).
>As an experiment, put a scope on your +12 when you use your horn.
>
>Or consider...
>
>|
>|Be wary of hooking to the +12V DC rail in a automotives electrical
>|system.  The gotcha is load dump.  With a very heavy discharged battery,
>|the alternator will be putting out plenty of current.  If you hit a bump
>|and the battery cable jumps around, you'll see the output dumped back
>|into the +12VDC rail.  Of course, the regulator will dampen the voltage
>|swing, but it's feedback has a slow time constant compared to that of
>|the silicon in a PC.
>|
>|N6RCE
>
>As implied by the previous parts of this message you probably will have
>big problems.  There is tons of noise in a car's electical system,
>and the +12V in your computer is used to a regulated source.  You'll
>need to isolate your computer from the car's electrical system.
>
>If anyone knows a simple and reliable method of doing this, other
>than using a seperate battery [:-(] I'd love to hear it.
>
>James Thiele -- microsoft!jamesth


    I'm surprised your very fine engineer friend had trouble getting a
good +5V from an automotive electrical system. If his current requirements
were moderate, there are 3 pin regulators which work very well under
automotive conditions.

  As for operating a PC from an automotive source, you've got more than
one problem. Getting power is a big one, but providing reasonable shielding
is another, and believe me, this is more important. The PC must be shielded
from electrical noise in the car; this can come in on any cable connected
to the computer. The symptoms of insufficient shielding could include
erratic operation or a hard failure of the PC (requiring  repair). It isn't
hard to protect yourself; you may wish to insert 100 ohm/ .001 uF RC
networks on all the incoming RS-232 pins, etc.

  The power itself is funny. You need to protect against high voltage
transients, the voltage may run 100V+ during a load dump. You also may
experience negative transients on the power rail. Voltage on the rail
will range from 8V while cranking the starter to 15V+ while running at
high RPM.

  Deriving a clean 5V supply is pretty straightforward under these
conditions, but the other (-5, +12, -12) voltages you may need are not
as easy. I'd suggest one of two approaches:

1. Build a clean +5V supply and derive other voltages from this source
   using DC-DC converters. If the current requirements on the other
   supplies are moderately low, this may work well. I'm not sure how
   much current you want from the +12V supply; hard disks have historically
   consumed significant current during startup. Even floppy drives get
   hungry. The usefulness of this approach depends on your configuration.

2. Build a DC-DC switching supply which runs of the filtered automotive
   rail and produces all of the voltages. This may be your best bet if
   you want good +12V current. The downside is you'll probably have
   to design and roll your own on this, even so far as winding your own
   power transformer(s). Amidon Associates in North Hollywood sells
   very useful cores (toroidal and E-type) and offers a fair amount of
   data on this. I'd also suggest looking at some of the power MOSFET
   literature in power conversion; essentially, build a PC power
   supply that uses 8-12V in rather than 160VDC rectified line current.


 Enjoy.


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

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

Date: 19 Jul 90 00:41:06 GMT
From: [e-mail]  (Brian Kantor)
Subject: Running a PC on 12V
To: [e-mail]

Well, I have one of those $25-at-the-swapmeet XT clones running just
fine off 12v.  Turns out the -5 isn't used at all, and the -12 is used
only for the RS232 drivers on the serial port, which in violation of all
standards works just fine if you tie it to ground - seems a lot of RS232
line receivers just don't care very much.  At least, it talks to my
loran receiver's serial port.  Perhaps a printer might care more.

The automotive +12 (actually, about 13.5) comes in through a hulking
great choke I stole out of an old car radio, then several thousand uF
and a 16v MOV to ground, then into a 3-terminal regulator which gives me
about 12v when the battery is topped up, a little less when the
headlights are on.  The floppy and RS232 don't seem to care.  The output
of the choke also goes into a pass transistor (actually, two in
parallel) driven off a three-terminal regulator to give me about 10
amps of +5, which turns out to be more than I really need.  PWROK is
driven by a 555 timer.

It works.  A scope shows the 50+v spikes during engine cranking to hit
about +18v or so after the choke; that's well within the 37v max of the
regulators.  The input voltage drops to about 8v or so during cranking;
the processor continues to run but the floppy drive looses speed and
gets errors.  I haven't tried a hard drive yet.
    - Brian

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

Date: 19 Jul 90 04:55:43 GMT
From: bacchus.pa.dec.com!jumbo![e-mail]  (Ed Satterthwaite)
Subject: Running a PC on 12V
To: [e-mail]

In article <[e-mail]>, [e-mail] (Brian Kantor) writes:
> ...
> fine off 12v.  Turns out the -5 isn't used at all, and the -12 is used
> only for the RS232 drivers on the serial port, which in violation of all
> standards works just fine if you tie it to ground - seems a lot of RS232
> line receivers just don't care very much.  At least, it talks to my
> loran receiver's serial port.  Perhaps a printer might care more.

I recently experimented a bit to test the tolerance of RS232 receivers.  A
TTL low (~ 0.4V) seems to work fine in practice, but there's very little
noise margin, as I discovered by loading the driver.  A CMOS driver that
goes closer to ground seemed pretty bullet-proof.  On a small sample, the
1489 receiver did somewhat better than the MAX232 with these marginal
levels.

Ed n6plo

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

Date: 18 Jul 90 20:00:32 GMT
From: zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!wb3ffv![e-mail]  ( WB3FFV)
Subject: Source for NOS?
To: [e-mail]



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

Date: Thu, 19 Jul 90 11:30:47 JST
From: "KOMATSU Toshiki ." <[e-mail]>
Subject: W0RLI Mailbox in US ???
To: packet radio redistribution  <[e-mail]>

     Dear OM,
     In JA , It seems many Mail boxes that used W0RLI/WA7MBL type have changed
to TCP/IP station . But , most users used 8-bit(i,e,Z80) cannot read from
TCP/IP , and removed network . It remains now , some pakctters hate TCP/IP .
     I know TCP/IP is exactry good for networking , but cannot this technology
support 'all packetters' ? I think packet radio became very popular because of
easyily of cannecting Rig , and Computers against to Rtty or Amtor .
     Please show me how you solve this probrem against JA .
     Thank you .

/ KOMATSU Toshiki
Dept.of CHEMISTRY,Univ.of Tsukuba.  E-mail:[e-mail]
phone :[phone]            mail  :P.O.Box 53,Tsukuba-Gakuen,
HAMnet:JF7WED@JI1ZMW.#12.JNET1.JPN           Ibaraki 305 JAPAN

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

Date: (null)
From: (null)
    Hello Hank,

I suppose it is time once again for me to post the information on my BBS to
the net one more time.  I will note that I soon expect to have dialup SLIP
avalible to those that would like to use that method to access my system.
Please look in this group or rec.ham-radio for the information.


-------------------------------------------------------------------------------
Internet  : [e-mail]     |       Howard D. Leadmon
UUCP      : wb3ffv!howardl              |       Advanced Business Solutions
TELEX     : 152252474                   |       210 E. Lombard St - Suite 410
Telephone : [phone]              |       Baltimore, MD  21202

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

End of Packet-Radio Digest
******************************
Date: Fri, 20 Jul 90 04:30:04 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #91
To: packet-radio


Packet-Radio Digest         Fri, 20 Jul 90       Volume 90 : Issue  91

Today's Topics:
             Running a PC on 12V

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests 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".
----------------------------------------------------------------------

Date: 18 Jul 90 21:30:41 GMT
From: usc!zaphod.mps.ohio-state.edu!sunybcs!uhura.cc.rochester.edu!rochester!rit!cci632![e-mail]  (Just another hired gun (n2hkd))
Subject: Running a PC on 12V
To: [e-mail]

In article <[e-mail]> [e-mail] (James THIELE) writes:
>In article <[e-mail]> [e-mail] writes:
>>
>>In article <[e-mail]>, [e-mail] (David J Bell) writes:
>||> Doug, you should have very little trouble, as far as I can see...
>
>Sounds like someone who hasn't tried it.
>need to isolate your computer from the car's electrical system.
>
>If anyone knows a simple and reliable method of doing this, other
>than using a seperate battery [:-(] I'd love to hear it.
>
>James Thiele -- microsoft!jamesth

Yes you have to regulate the 12V supply and the 5V supply.
work engine except for the RF vs COmputer problems.
I have had more problems with the rally computer wiping out
2M frequency then computer failure. There are some minor
adjustments to resolve this problem. The processor reset ciruit
seems to be a real problem if it isn't protect by clamps and
caps. There you are driving down the road, oops miss the turn,
almost stall the engine, and your comupter resets. Well you
obviously left out a MOV in the power circuit, Curtis!.
There are a few special things to do for car applications,
a  better case, a better ps (bullet proof), a better pcb (like
a multilayer clone bd), etc.

Good luck, but I know that it can be done, actually I'd  recommend
the ampro 86/286 type boards that fit on top of a disk drive....



--

email:   cb@cci632  or !rochester!kodak!n2hkd!curtis
Curtis Braun, N2HKD, Computronics, PO Box 1002 Fairport NY, 14450

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

End of Packet-Radio Digest
******************************
Date: Sat, 21 Jul 90 04:30:02 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #92
To: packet-radio


Packet-Radio Digest         Sat, 21 Jul 90       Volume 90 : Issue  92

Today's Topics:
             TNC-2 bootstrap rom: works?
         What's wrong with Internet on radio (2 msgs)

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests 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".
----------------------------------------------------------------------

Date: 20 Jul 90 17:48:42 GMT
From: hpcc01!col![e-mail]  (Bdale Garbee)
Subject: TNC-2 bootstrap rom: works?
To: [e-mail]

>I recently burned the EPROM that comes in the TNC_TNC2 archive.  It
>is SUPPOSED to allow me to upload intel hex ercords to the TNC-2,
>but it does not work.  Nor does it echo back all bytes sent to it
>on startup.
>
>I'm using an MFJ-1274 - anybody have any thoughts on what the problem
>may be?  It simply freezes, with both lamps on.

You need to use either a 2764 or the top 8k of a 27256, if I remember
correctly.  This was to allow the code to ignore JMP6.  It's been a while
though, so I may have this fuzzed...

Bdale

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

Date: 11 Jul 90 19:14:18 GMT
From: usc!elroy.jpl.nasa.gov!grian!puffin![e-mail]  (Mike Curtis, ax.25 wd6ehr@k6iyk [phone])
Subject: What's wrong with Internet on radio
To: [e-mail]

In message <[e-mail]>, [e-mail] (Brian Kantor) writes:
> >The internet and the tcp/ip packet radio network that emulates it is
> >a huge collection of terminal servers, etc.
>
> If I were to accept your view of what the real world of packet radio,
> and what the internet is, I'd have to admit that your arguments make
> sense.
>
> But I don't want to limit myself to that view.  I want more.
>
> I want closely-coupled distributed computing, databases, communications.
> I want to play chess against your computer while you challenge mine.  I
> want digital voice, images, text, printed pages.  I want to see if I can
> be in two or more places at one time with virtual realities.  I want to
> span space and time - visit places I can never go.  I want to see the
> Earth from orbit, travel undersea, hear the winds in a ballon as I
> control it from my easy chair.  I want to know if the Cokes in the
> machine down the hall or across the planet are cold yet.  What's the
> weather like in New Jersey, or off the end of the Scripps Pier?

My "dreams" are much more simplistic and limited - I'm working on a
very preliminary concept of multi-megabit mountaintop trunks feeding
many low-level cell sites with a 56kB downlink, who would then use
selectable 1200, 9600, and 56kB to end users.

The microwave "repeaters" would be point to point, and would be handling
mostly data from the rest of the network.  Additional data from the cell
sites would be mux'd into this data stream.

Users on any cell site could "connect" to any other cell site in the
system, and from there connect to another end user.

Sounds a bit like high-speed TEX-NET, doesn't it?

I'm also trying to get a 9600 baud end user frequency for 2 meters.  It's
an uphill battle.  there are those here who want everything on 2 meters
for 1200 baud, even though 9600 baud k9ng format @ 3 KHz deviation requires
only 12 KHz bandwidth and easily fits within a 20 KHz channel!  (BTW, we've
seen quite a few 1200 baud stations that are using MORE than 20 KHz because
of improper radio/TNC adjustment!)
>
> These are only a few of the things that can be done with an experimental
> digital network.  Some of them are history, some are happening now; some
> are a few years off.  Some might never happen - but we'll never know
> until we try.
>
> Please, oh please! don't try to make everyone equal by cutting them all
> down to a uniform size.  It is the dreamers, the experimenters, the
> imaginative few who are willing to try to do the impractical, the
> impossible, the glorious - these are the kinds of people we need most in
> ham radio - nay, in society!

Yup - and there are always the nay-sayers standing in our way, i.e. Who's
going to buy all this microwave stuff?  Don't you know it's expensive?
And besides, what we have right now works just fine, thank you!  I can
type to my buddy down the street just fine.

Well, microwave _can_ be expensive, but underused technology usually is.
I remember the first electronic clock.  It was $1500.00, and had LED's
in a circle, like the face of a clock.  It told hours and minutes.
I can now purchase a much smaller, more sophisticated DIGITAL watch for
under a buck!  So it's totally realistic to expect microwave stuff to
come down in price as demand becomes greater.

And what we have now does _not_ work just fine.  If you want to transfer
a decent size file on 1200 baud packet, expect it to take all night, _if_
it goes at all.
The ax.25 users cry up a storm over tcp/ip "hogging the channel".  And
they're absolutely right.  We _do_ hog it!  The amount of information in
and out of my station is incredible, as far as ax.25 users are concerned.
Something that's intended to be adequate for what basically amounts to
shared frequency RadioTeletype (RTTY) will fall far short of adequacy
for a LAN.
>
> And think, even if only one or two of us succeeds only in 1% of what we're
> dreaming of doing, even unimaginative uses of the network will be all
> the better for it.

Yes, again, Brian!!!
What skin off your collective noses is it if a bunch of us nerds wants
to try something that won't work?

Remember the bumblebee.  Do you realize that it's scientifically impossible
for him to fly?  But the bumblebee, being totally ignorant of scientific
fact, ..................

Perhaps Albert Einstein said it best:
What we know about the Universe, compared to what there is to know, is
like a man who desires a closer look at the Moon, so he climbs onto
his roof.

My favorite bumper sticker (at least while composing this) would have to be:

LEAD, FOLLOW, OR GET OUT OF THE WAY

>
> Please don't take my toys away, Daddy.  I don't want to go to bed yet.
>       - Brian
>
Me too, Daddy; me too.......

              73, Mike Curtis

  _________________________________________________________________________
 | [e-mail]             | "I  didn't invent the talking machine- |
 | packet [e-mail]   | God did.  I just  made the  first  one |
 |                                | that can be turned off." (-;           |
 | 7921 Wilkinson Avenue          | -Thomas Edison, following several long |
 | North Hollywood CA 91605-2210  | speeches at a banquet in honor of  his |
 | [phone]                 | invention of the phonograph.           |
  -------------------------------------------------------------------------

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

Date: 20 Jul 90 18:01:11 GMT
From: pacbell.com!tandem!moe![e-mail]  (Kevin J. Rowett)
Subject: What's wrong with Internet on radio
To: [e-mail]

In article <[e-mail]>
|>
|> The microwave "repeaters" would be point to point, and would be handling
|> mostly data from the rest of the network.  Additional data from the cell

There's merit in this!

|> Users on any cell site could "connect" to any other cell site in the

Go all the way.  Allow users to connect end to end without having
to know every darn point along the way.

|> Sounds a bit like high-speed TEX-NET, doesn't it?

Nope, sounds like the Internet model, really.

|> Yup - and there are always the nay-sayers standing in our way, i.e. Who's
|> going to buy all this microwave stuff?  Don't you know it's expensive?

See the Dec 89 issue of HR.  $150 per end.


Want to work on soemthing truely interesting:  What happens when the
whole of packet radio is pt-to-pt?

N6RCE

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

End of Packet-Radio Digest
******************************
Date: Sun, 22 Jul 90 04:30:04 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #93
To: packet-radio


Packet-Radio Digest         Sun, 22 Jul 90       Volume 90 : Issue  93

Today's Topics:
                TNC-1 speedup
         What's wrong with Internet on radio

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests 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".
----------------------------------------------------------------------

Date: 21 Jul 90 12:38:22 GMT
From: uhccux![e-mail]  (Antonio Querubin)
Subject: TNC-1 speedup
To: [e-mail]

I have an original TNC-1 and am considering runnning it at a higher clock
speed in KISS mode.  Is there any advantage to be gained by doing this?  Does
it for example process packets any faster thus reducing txdelay requirements
of the 'other' station?

I've already tried moving JP7 and that didn't seem to work.  I know, the
manual says you need higher-speed components but I wanted to see if it would
take it anyway.  Just which components in the TNC-1 are clock-speed sensitive?
The manual doesn't say.  Are there any special adjustments that need to be
done when I run it at the higher speed?

73's
AH6BW
[e-mail]
antonio-querubin_manoa@uhplato (BITnet)

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

Date: 21 Jul 90 07:41:46 GMT
From: usc!elroy.jpl.nasa.gov!grian!puffin!wd6ehr.ampr.org![e-mail]  (Mike Curtis)
Subject: What's wrong with Internet on radio
To: [e-mail]

In article <[e-mail]> [e-mail] (Kevin J. Rowett) writes:
>|>
>|> The microwave "repeaters" would be point to point, and would be handling
>|> mostly data from the rest of the network.  Additional data from the cell
>
>There's merit in this!
>
>|> Users on any cell site could "connect" to any other cell site in the
>
>Go all the way.  Allow users to connect end to end without having
>to know every darn point along the way.

That's what I meant.
>
>|> Sounds a bit like high-speed TEX-NET, doesn't it?
>
>Nope, sounds like the Internet model, really.
Then I suppose this aspect of Tex-net is patterned after Internet?
Tex-net allows users to route throughout the Tex-net network without
knowing specific routing (as I understand it, anyway).
The point I was trying to make is: this ain't nothin' new!
>
>|> Yup - and there are always the nay-sayers standing in our way, i.e. Who's
>|> going to buy all this microwave stuff?  Don't you know it's expensive?
>
>See the Dec 89 issue of HR.  $150 per end.

Yup - you and I know this - but that's what the NAY-SAYERS are saying.
In other words, some folks find fault with everything.  Remember the
bumblebee... It's scientifically impossible for him to fly!  But the
bumblebee, being ignorant of scientific fact,.........
>
>Want to work on soemthing truely interesting:  What happens when the
>whole of packet radio is pt-to-pt?
 ^^^^^
I agree, sorta.  A good point-to-point packet system will be nifty for
many things.  But for _all_ of packet???   I really hope not.
In order to make advances, we need the freedom to experiment,
and just plain old dork around with stuff that hits our fancy at a
particular time and place.  If the WHOLE of packet is thus restricted,
it'll never progress.  Let me try the stupid idiot stuff I've got in
my meshuginer head.  What is it going to hurt?

(Hope I didn't take you out of context???  But it is a point that needs
discussion anyway .....)

There are those that would abolish amateur tcp/ip because their view of
packet is restricted to the present-day.  "Your dumb tcp/ip has long
headers.  It bogs down the 110 baud link in Oshkosh...  and who died and
left YOU boss anyway?....... I've been passing traffic for 1E06 years,
and we've always ......", etc.

Many speak eloquently of "freedom of speech" (I call it "freedom to flush
their toilet-mouth", so you know where I stand ;-), but the freedom to
experiment is MUCH more important than someone being able to cuss and be
rude in \public :-)  I've seen a tremendous emphasis placed (locally, at
least) on certain peoples idea of a network, that encompasses ALL of the
currently available 2 meter frequencies.  Right or wrong, if it stifles
the inventiveness that's already in short supply, it's categorically BAD!
We need to really be cautious about dogmaticisms, and try to give
encouragement to those taking the lead in development of new, untried,
and underimplemented technologies.

I appreciate your input and opinions.  Thanks for the reply.


              73, Mike Curtis

  _________________________________________________________________________
   [e-mail]               "I  didn't invent the talking machine-
   packet [e-mail]     God did.  I just  made the  first  one
                    that can be turned off." (-;
   7921 Wilkinson Avenue            -Thomas Edison, following several long
   North Hollywood CA 91605-2210    speeches at a banquet in honor of  his
   [phone]                   invention of the phonograph.
  -------------------------------------------------------------------------

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

End of Packet-Radio Digest
******************************
Date: Mon, 23 Jul 90 04:30:02 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #94
To: packet-radio


Packet-Radio Digest         Mon, 23 Jul 90       Volume 90 : Issue  94

Today's Topics:
    Interfacing a PSK Modem to an ICOM IC-R7000 Receiver (2 msgs)

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests 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".
----------------------------------------------------------------------

Date: Sun, 22 Jul 90 22:46:26 EDT
From: [e-mail]
Subject: Interfacing a PSK Modem to an ICOM IC-R7000 Receiver
To: "Info-Hams Digest" <[e-mail]>, [e-mail]

Has anyone modified an ICOM IC-R7000 to track the Doppler shifts of
satellites?  I am interested in interfacing the PacComm PSK-1 modem
to the R7000 to automatically follow the frequency shifts of the
Microsats.  Unfortunately, unlike with transceivers, there is no
direct up/down frequency control of the R7000 except via the remote
controller.  At the moment I'm looking at connecting the PSK-1's step-
up and step-down tuning outputs across the remote controller's
frequency up and down switches.  A slight problem with this is that
the PSK-1's output pulses for shifting the frequency of the radio are
only 30 to 40 milliseconds wide and that's not long enough for the
remote controller to generate the signal for the R7000 to change
frequency.  This means that a pulse stretcher will be necessary
between the PSK-1 and the remote controller.  I'll probably go ahead
and build a one or two chip circuit to do this, but I was wondering
if there's an alternative approach to interfacing the PSK-1 to the
R7000.  Any ideas?

================================================================================
 Richard B. Langley                            BITnet: [e-mail] or [e-mail]
 Geodetic Research Laboratory                  Phone:  [phone]
 Dept. of Surveying Engineering                Telex:  014-46202
 University of New Brunswick                   FAX:    [phone]
 Fredericton, N.B., Canada  E3B 5A3
================================================================================

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

Date: 23 Jul 90 04:24:37 GMT
From: [e-mail]  (Brian Kantor)
Subject: Interfacing a PSK Modem to an ICOM IC-R7000 Receiver
To: [e-mail]

I can't speak to the Pac-com PSK modem, but I have one of the TAPR PSK
modems connected to my R-7000 and it's working just great.

The trick is that the up/down outputs of the PSK modem can be made
available as uncommitted transistors - and you can use those to bridge
the two row and one column inputs on the command scan matrix inside the
radio.  The service manual clearly shows which pins on the connector
for the remote control module are used for these functions.

What I did was to run a piece of cable into the R-7000 to pick up
ground, recorder audio, and the three wires needed to run the receiver
up or down.  The other end of the cable goes to the 5-pin DIN connector
that plugs into the modem.

With the receiver set for 100 Hz dial steps, it tracks all the
microsats and FO-20 just fine.  You will need a preamp; with a
40-element KLM beam tracking the microsats the internal noise and
numbness of the R-7000 doesn't let you use low-angle passes.  However,
the $18 GaAs-FET preamp from Hamtronics works well - stick it in a
Pomona box and put it in the antenna line to the R-7000, and you might
well be able to hear the microsats from horizon to horizon.  I do.
    - Brian

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

End of Packet-Radio Digest
******************************
Date: Tue, 24 Jul 90 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #95
To: packet-radio


Packet-Radio Digest         Tue, 24 Jul 90       Volume 90 : Issue  95

Today's Topics:
                Administrivia
             Internet on Radio Revisited
             Packet on SCO Xenix
         What's wrong with Internet on radio

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests 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".
----------------------------------------------------------------------

Date: Mon, 23 Jul 90 22:01:12 -0700
From: brian (Brian Kantor)
Subject: Administrivia
To: digests:;

I just found a bug in the digestification software that would cause a digest
to be truncated if a message contained a dot on a line by itself.  That is
now fixed.  Sorry, dudes!       (cure - invoke sendmail with -oi )

Your fearless list maintainer and digestificationer.
    - Brian

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

Date: 24 Jul 90 05:00:06 GMT
From: bionet!hayes.fai.alaska.edu!acad3.fai.alaska.edu![e-mail]  (MUNTS PHILLIP A)
Subject: Internet on Radio Revisited
To: [e-mail]

     The consensus seems to be that I was all wet saying that the Internet
model was inappropriate for amateur packet radio.  Obviously, I just don't
know how to use TCP/IP properly.  So tell me...

     How do I ftp or telnet through a store and forward satellite?  Would
TCP/IP even work through a store and forward satellite?  How about on HF?
(also essentially store and forward due to propagation, interference, and
low bandwidth.)

     These are currently the only packet channels between Alaska and CONUS.
It is about 2500 road miles between Fairbanks and CONUS.  A terrestrial
microwave relay system would require 50 stations if we could manage 50 miles
a hop on the average.  What is the likelihood of installing and then
maintaining such a backbone?  (Our 9600 bps intra-state BBS backbone is
piggybacked, I understand, on state owned microwave equipment.)

     Vast areas of Canada, western U.S., South America, Asia, Australia,
Africa etc. have the same problem.  High bandwidth backbones don't appear
from thin air just because the design requires it.  A lot of the world is
going to be serviced by store and forward channels for a long time whether
we like it or not; my question still unanswered is TCP/IP appropriate for
that?

     I read recently (IEEE Network I think) that one of the design criteria
for ARPANET and hence TCP/IP was 9600 bps effective between any two nodes
anywhere on the network.  This was accomplished with long haul links at 230
Kbps links (no doubt much faster now).  My observations have been that this
is barely enough at the best of times and totally inadequate during the
business day.  What kind of radio network hardware do we need to provide this
level of service?  With a couple orders of magnitude more nodes and much less
reliable long haul links?

Philip Munts N7AHL
NRA Extremist, etc.
University of Alaska, Fairbanks

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

Date: 23 Jul 90 22:23:00 EDT
From: "SWEIGERT, DAVID" <[e-mail]>
Subject: Packet on SCO Xenix
To: "packet-radio" <[e-mail]>

Anyone have an experience running packet radio
on an 80386 server with Santa Cruz Operatyion Xenix..
cheers..
WB9VKO

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

Date: 23 Jul 90 15:34:43 GMT
From: hpcc01!col![e-mail]  (Bdale Garbee)
Subject: What's wrong with Internet on radio
To: [e-mail]

A few more thoughts...

>>|> Sounds a bit like high-speed TEX-NET, doesn't it?
>>Nope, sounds like the Internet model, really.
>Then I suppose this aspect of Tex-net is patterned after Internet?
>Tex-net allows users to route throughout the Tex-net network without
>knowing specific routing (as I understand it, anyway).
>The point I was trying to make is: this ain't nothin' new!

No, but it's amazing how often it's ignored.

TexNet still doesn't match the focus of the Internet model that many of us are
hoping comes into common use on packet.  TexNet is a good approximation of the
way the Internet used to be, when mainframes were king, and a user connected to
his favorite machine with a terminal, and then could hit any other machine
without knowing the routing.  A TexNet user connects to his local node, and can
get to any other node without knowing the routing.

The advent of workstations has led to a slight revision of the model, where a
given user is *already* on his favorite host, and is really doing a user to
user direct connection without knowing the routing, in a computer'ish kind of
way.  This is the model I'd really like to see.  Users with computers
communicating with other users with computers.  TexNet doesn't do this, as the
interface to users or user machines is an AX.25 "terminal node" connection.

Just as the Internet continues to support terminal service on hosts and on
specialized terminal servers, packet radio IP will and does today support
terminal users both on hosts and with specialized "AX.25 terminal servers", but
that is not and should not be the focus.  It's a backwards-compatibility issue
only.

>the freedom to
>experiment is MUCH more important than someone being able to cuss and be
>rude in \public :-)  I've seen a tremendous emphasis placed (locally, at
>least) on certain peoples idea of a network, that encompasses ALL of the
>currently available 2 meter frequencies.  Right or wrong, if it stifles
>the inventiveness that's already in short supply, it's categorically BAD!

There are two strongly conflicting issues here.  One is that we need to have
the freedom to experiment.  That is a fundamental truth, to me.

The other is that if we're ever going to have any wide-area high-speed network
to play with, at some point folks are going to have to talk to each other, and
agree on some fundamental points.  Not the data rate of links, or the protocols
to be run, though those are certainly issues that can/should be addressed.  I
am talking about really fundamental issues, like agreeing to work together to
achieve common goals.

The difficulties we face building high-speed packet networks on amateur radio
are today much less based in technology than in human social systems.

Bdale

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

End of Packet-Radio Digest
******************************
Date: Wed, 25 Jul 90 04:30:02 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #96
To: packet-radio


Packet-Radio Digest         Wed, 25 Jul 90       Volume 90 : Issue  96

Today's Topics:
             Internet on Radio Revisited
             Packet on SCO Xenix (2 msgs)

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests 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".
----------------------------------------------------------------------

Date: 24 Jul 90 19:01:56 GMT
From: bellcore-2!envy![e-mail]  (Phil R. Karn)
Subject: Internet on Radio Revisited
To: [e-mail]

If I understand Phil Munts' argument, the TCP/IP architecture was
primarily designed for use over subnetworks with continuous,
ubiquitous, real time coverage. On the other hand, much of amateur
packet radio uses slow, part-time links that are suitable only for
handling store-and-forward traffic in non-real time.

Fair enough. The Internet protocols WERE originally designed for the
ARPANET, the first packet switching network. ARPANET used government
sponsored links, and sites that were on it enjoyed virtually
continuous connectivity with other sites. And of course TCP/IP and the
applications it supports are most "at home" in this kind of world.

But the Internet has grown far beyond the bounds of the original
ARPANET (which no longer exists, having been replaced with the NSF
Backbone Network). Not all of the links in the current far-flung
Internet are dedicated leased lines or highly reliable local area
networks.  Some are commercial X.25 networks. Others are dialup phone
lines. And some are even amateur packet radio paths. In other words,
the Internet is no longer based on "continuous duty" facilities, and
it hasn't been for some time.

One place where this is especially true is electronic mail. The
Internet now reaches many other kinds of electronic mail networks,
many of whom do not use TCP/IP. Examples include UUCPNET, BITNET,
Compuserve, MCIMail, SPANNet, and even the amateur packet radio BBS
network. Now, strictly speaking, you could say that these other
networks are not really "on the Internet", because they don't
specifically speak TCP and IP. But what does "being on an internet"
really mean?

An internet (note lower case 'i') is usually defined as a set of of
connected networks that share a common set of upper layer protocols
and a global name space even though they may differ widely in their
lower layer protocols.  What's interesting about Internet mail is that
even some networks that don't use TCP/IP have adopted the Internet's
electronic mail standards, either as their native tongue or as a
lingua franca. In a very real sense, we have built an
"inter-internet", and the new "inter-internet datagram" is the
electronic mail message. Some people have followed the Internet
client/server model even further by setting up "mail archive" servers
that accept mail messages requesting files that are automatically sent
back in return mail.

To be sure, the facilities of this inter-internet are not as
transparent, flexible, or as powerful as those of the "real" Internet,
because they are typically built on slower non-real-time facilities
that are better suited for store-and-forward traffic such as email.
But they work, and they do not deny those to do have the resources to
build a "real" TCP/IP Internet the opportunity to do so while
retaining the capability to exchange email with those who are not as
well endowed.

So, after that lengthy monologue, on to some of Phil's specific questions.

> How do I ftp or telnet through a store and forward satellite?

In theory, you could. You store each IP datagram as a separate message
in the satellite. After two passes over the client and one over the
server, you've completed your three-way TCP handshake, and now the
server's ready to send the FTP greeting....

Ah hem. Obviously, real time services like FTP and Telnet are not
appropriate THROUGH a non-real-time satellite like Microsat. But
there's no reason that you couldn't use them to talk TO the satellite,
using it as an FTP "staging area". People do the same thing all the
time on the ground, especially when their computers have only
intermittent connectivity to the Internet (portable laptops, for
example).

You might think the use of TCP/IP unnecessary if each user talks
directly to the satellite. But the use of TCP/IP on the satellite
could make it much easier for the users in a local community to share
a common satellite ground station. The TCP "end-points" would be on
the satellite at one end, and at the individual user stations at the
other. The shared ground station would just be a concentrating IP
router/gateway. By the way, there's much to be said for the gateway
approach to using satellites, aside from being able to share the cost
of the equipment. By funneling the users' uplink packets through a
common queue and transmitter, you avoid the contention between them
that would otherwise occur if they each transmitted to the satellite
directly.

> How about on HF?
> (also essentially store and forward due to propagation, interference, and
> low bandwidth.)

It depends. A satellite can have an onboard computer and memory, while
HF is just a propagation channel. If it's available and goes where you
want to go, there's no reason it couldn't be used in real time.
Otherwise it could be used in store-and-forward mode to handle email
or file transfer.

The point I've been trying to make all along is that TCP/IP does NOT
necessarily preclude store-and-forward operations or vice versa. The
popularity of the MX (mail exchanger) extensions to the domain system
prove this.  The MX facility has dramatically improved the ability of
Internet users to communicate easily and transparently with off-net
sites, most of whom are joined only through slow and intermittent
store and forward paths -- just like amateur packet radio.

> I read recently (IEEE Network I think) that one of the design criteria
> for ARPANET and hence TCP/IP was 9600 bps effective between any two nodes
> anywhere on the network.  This was accomplished with long haul links at 230
> Kbps links (no doubt much faster now).

Actually, the ARPANET backbone links were almost all 56kb/s. This
bandwidth had to be shared across all active users. Depending on how
many users there are and where they wanted to go, they might or might
not receive an effective throughput of 9600 bps. This had nothing to
do with the protocols, but with basic arithmetic -- no protocol can
cram ten pounds of users into a five pound network.

To be sure, there is still plenty of room for improvement in extending
the Internet model to cover less-than-ideal network paths. I believe
amateur packet radio has already made some contributions in this area;
a robust round time measurement algorithm that I invented several
years ago while trying to get TCP to perform better over amateur
packet radio was picked up by the Internet community and is now a
required part of the TCP standard.  The protocol implementations
should also be tuned to accomplish more in fewer round-trip packet
exchanges. TCP allows data, acknowledgements and control messages to
be piggybacked in the same packet. For example, it's perfectly legal
for an FTP server to send its TCP SYN/ACK and initial banner all in
the same packet, but few do. Also, it's legal to "batch up" a series
of SMTP commands in the same packet in order to minimize the effect
of long round trip delays. NN2Z's SMTP sender does this.

We also need to devise application interfaces that are less dependent
on real time connectivity. FTP clients (including mine) are a classic
example. Why should a user have to sit there and manually log into a
remote server and interact with it even when he knows in advance
everything he will type? He ought to be able to tell his local machine
"get this file from that machine, and use the following user name and
password". His machine would then do everything automatically, even if
the remote system is momentarily unavailable when the user requests
the transaction.  Similarly, I should be able to say "send this file
to user so-and-so" and have the rest occur automatically.  The
interactive model has persisted on the Internet largely because there
has been little pressing need to fix it. But this doesn't mean that it
can't be. This is another way that amateur radio could give something
back to the Internet community.

I'm fond of telling non-amateur Internet groups that if we can make
TCP/IP work on ham radio, with its unbelievably brain-damaged links,
then we can make it work ANYWHERE.  And with the phenomenal growth in
the Internet (it has been doubling roughly every 12-13 months for the
past 5 years) the problems ham radio encounters today could well be
those the real Internet will encounter several years in the future.
I'd like to think that this helps serve ham radio's reason for being.

Phil

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

Date: 23 Jul 90 22:23:00 EDT
From: "SWEIGERT, DAVID" <[e-mail]>
Subject: Packet on SCO Xenix
To: "packet-radio" <[e-mail]>

Anyone have an experience running packet radio
on an 80386 server with Santa Cruz Operatyion Xenix..
cheers..
WB9VKO

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

Date: 24 Jul 90 19:21:15 GMT
From: usc!cs.utexas.edu!samsung!sol.ctr.columbia.edu!emory!kd4nc!n4hgf![e-mail]  (Warren Tucker)
Subject: Packet on SCO Xenix
To: [e-mail]

In article <[e-mail]> [e-mail] ("SWEIGERT, DAVID") writes:
>Anyone have an experience running packet radio
>on an 80386 server with Santa Cruz Operatyion Xenix..
>cheers..
>WB9VKO

I use an AEA PK-232 with my 386, now running SCO UNIX, but I used
XENIX or a couple of years.  I use a homebrew program to control my
FT-980 radio and a regular async terminal program for the TNC.
If you or anyone wants more details, let me know.

A sample screen display:

 meow980 1.20
.------- Status --------.  F1-Commands      . IF shift -------------  +0 ---.
| LSB     VFO       GEN |  F2-Directory     `...............^...............'
| HAM VFO:     7,000.00 |  F3-Set Freq      . IF width ------------- 127 ---.
| GEN VFO:     8,053.70 |  F4-Mode          `...............^...............'
| AFSK EQUIV:  8,051.50 |  F5-Clarifier
+------ Clarifier ------+  F6-IF Shift       Freq Delta  1000  100    10
| off                   |  F7-IF Width                +  Home  CurUp  PgUp
`-----------------------'  F9-Quit                    -  End   CurDn  PgDn
OPMODE SIGNAL
cmd:
0.85:  101 baud, AMTOR, RXREV OFF
0.96:  100 baud, AMTOR, RXREV OFF
0.94:  100 baud, ok
OPMODE   was SIGNAL
OPMODE   now AMTOR
cmd:WSF4969 WSL8587 WSP6069 WSRY WSX7458 WTT9408 WTU2727 WTX7657
WUU9221 WXQ4541 WYQ8711 WZL8900 WZY8015
QSWQSW NMH 3EFO4 3FIH2 3FMF2 C6CG C6CM6 C6CN2 C6II4 ELIR8
ELJV7_E_LY5 ELNG6 HZ21 LAEB2 LAQA2 LNQX OWWI2 P3ON2 SLKM3576
SWA7953 TCQG WAH4569 WAH9131 WAK5522 WEKL WKGY WLKA WQE4546
WSF4969_ 2')8587 WSP6069 WSRY WSX7458 WTT9408 WTU2727 WTX7657
WUU9221 WXQ4541 WYQ8711 WZL8900 WZY8015
-AR-
FTFT AAA 900623-1.15ZCZC OT35
CQ CQ CQ DE WOO WOO WOO

--------------------------------------------------------------------
Warren Tucker, TuckerWare emory!n4hgf!wht or [e-mail]
E = I * R, if you're lucky, and only then on alternate Tuesdays.

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

End of Packet-Radio Digest
******************************
Date: Thu, 26 Jul 90 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #97
To: packet-radio


Packet-Radio Digest         Thu, 26 Jul 90       Volume 90 : Issue  97

Today's Topics:
            Historical Correction

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests 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".
----------------------------------------------------------------------

Date: Wed, 25 Jul 1990 15:23:51 PDT
From: Billy Brackenridge <[e-mail]>
Subject: Historical Correction
To: [e-mail]

Phil -- Long before there were local area networks there were packet radio
networks. Remember Aloha? Where do you think the name EtherNet came from?

The first internet gateway was a PDP-11 that linked the arpanet to SRI's
packet radio net. In those days packet radios took an entire air conditioned
van to haul around the PDP-11s, radios, and terminals. The data rates were
higher than today's 1200 baud amateur radio, but the notion of linking
networks with different packet sizes, transmission rates, and delay
characteristics was fundimental to the design of the internet protocols.

Certainly we have learned a great deal since then about the truly
pathological cases. We certainly never expected to extend timeouts to the
lenghts that are sometimes seen over amateur packet radio or through
congested (or sometimes just sick!) gateways.

It would be nice to think that the designers of the internet were able to
predict the future. In fact the rise of the LAN was completely unpredicted.
Nobody expected workstations on every desk. We expected terminals talking via
phone lines, satellite links, and packet radio to central time sharing
systems.

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

End of Packet-Radio Digest
******************************
Date: Fri, 27 Jul 90 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #98
To: packet-radio


Packet-Radio Digest         Fri, 27 Jul 90       Volume 90 : Issue  98

Today's Topics:
              Air Force HF packet freqs
          AMPRNet Address Coordinators list
     Interfacing a PSK Modem to an ICOM IC-R7000 Receiver
             Internet on Radio Revisited
             MFJ1270B,4 TX audio mod file

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests 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".
----------------------------------------------------------------------

Date: 26 Jul 90 03:32:21 GMT
From: linus!philabs!briar![e-mail]  (Robert Casey)
Subject: Air Force HF packet freqs
To: [e-mail]

copied from packet:
+Msg# TSF  Size #Rd  Date  Time From   MsgID        To
 3617 BF   1210   1 24-Jul 2217 KM4NY  11090_WA4TFZ ALL@USA ()
  Sb: U.S. AIR FORCE HF-PACKET

  U.S. AIR FORCE AND U.S. ARMY MARS STATIONS SHARE SEVERAL HF FREQS. FOR
  PACKET...

  MODE=USB/300BAUD. AT THIS TIME THERE ARE TWO CH. THAT ARE VERY ACTIVE.
  NODES, BBSs, and PORTS ARE USED. MOST STATIONS ARE LOCATED ON MILITARY
  BASES.

  WORLDWIDE: 14.528.8 MHZ. +/-/USB.
  NATIONWIDE: 6.996.0 MHZ. +/-/USB.

  MOST MESSAGES PERTAIN TO HEALTH/WELFARE, BUT DURING
  NATIONAL/INTERNATIONAL INCIDENCES INVOLVING THE U.S. MILITARY, YOU
  MIGHT READ BETWEEN THE LINES.  IF ANYONE KNOWS OF U.S. NAVY HF-PACKET
  FREQS. PLEASE FORWARD TO ME. (JOE)

   KM4NY @ WA4TFZ.VA.USA.NA.   THANKS AND ENJOY THE PRINT. 73's.

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

Date: 26 Jul 90 15:18:40 GMT
From: [e-mail]  (Brian Kantor)
Subject: AMPRNet Address Coordinators list
To: [e-mail]

07/25/90

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  Joe Dubner              K7JD    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  Jim Posiadlo            AE1C    Boston
44.058  Rich Clemens            KB8AOB  West Virginia
44.060  Howard Leadmon          WB3FFV  Maryland
44.062  Jim Dearras             WA4ONG  Virginia (not DC)
44.064  Phil Karn               KA9Q    New Jersey: northern
44.065  John Pearce             WB2MNF  New Jersey: southern
44.066  unassigned
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  Bill Babson             WA1IVD  District of Columbia
44.098  Garry Paxinos           (waiting)       Florida
44.100  Jere Sandidge           K4FUM   Alabama
44.102  Steven Corso            KV8G    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.120  unassigned
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  G6KVK   Gareth Howell
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.193  Outer Space-AMSAT       W3IWI           Tom Clark

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

Date: 26 Jul 90 18:27:25 GMT
From: wang!wiis.wang.com![e-mail]  (Gary Field)
Subject: Interfacing a PSK Modem to an ICOM IC-R7000 Receiver
To: [e-mail]

[e-mail] writes:

>Has anyone modified an ICOM IC-R7000 to track the Doppler shifts of
>satellites?  I am interested in interfacing the PacComm PSK-1 modem
>to the R7000 to automatically follow the frequency shifts of the
>Microsats.  Unfortunately, unlike with transceivers, there is no
>direct up/down frequency control of the R7000 except via the remote
>controller.  At the moment I'm looking at connecting the PSK-1's step-
>up and step-down tuning outputs across the remote controller's
>frequency up and down switches.  A slight problem with this is that
>the PSK-1's output pulses for shifting the frequency of the radio are
>only 30 to 40 milliseconds wide and that's not long enough for the
>remote controller to generate the signal for the R7000 to change
>frequency.  This means that a pulse stretcher will be necessary
>between the PSK-1 and the remote controller.  I'll probably go ahead
>and build a one or two chip circuit to do this, but I was wondering
>if there's an alternative approach to interfacing the PSK-1 to the
>R7000.  Any ideas?

How about using the serial computer interface (ICOM CIV) to step
the frequency up and down. I believe it has such commands. This would
require an interface with a microprocessor (8051 etc) but should be
fairly simple still. The remote control method is bound to be somewhat
unreliable (interference with the beam etc).




/*===========================================================================
|   Gary A. Field - WA1GRC          |    GGG     A    RRRR   Y   Y     FFFFF
|   Wang Labs M/S 019-72B           |   G   G   A A   R   R  Y   Y     F
|   1 Industrial Ave                |   G      A   A  R   R   Y Y      F
|   Lowell, MA 01851-5161           |   G  GG  AAAAA  RRRR     Y       FFFFF
|   [phone]                  |   G   G  A   A  R  R     Y       F
| email: [e-mail] |    GGGG  A   A  R   R    Y       F
|----------------------------------------------------------------------------
|          Anything not worth doing, is not worth doing well.
============================================================================*/

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

Date: 25 Jul 90 16:13:49 GMT
From: news-server.csri.toronto.edu!torsqnt!geac!alias![e-mail]  (C. Harald Koch)
Subject: Internet on Radio Revisited
To: [e-mail]

In <[e-mail]> [e-mail] (Phil R. Karn) writes:

>We also need to devise application interfaces that are less dependent
>on real time connectivity. FTP clients (including mine) are a classic
>example. Why should a user have to sit there and manually log into a
>remote server and interact with it even when he knows in advance
>everything he will type? He ought to be able to tell his local machine
>"get this file from that machine, and use the following user name and
>password". His machine would then do everything automatically, even if
>the remote system is momentarily unavailable when the user requests
>the transaction.  Similarly, I should be able to say "send this file
>to user so-and-so" and have the rest occur automatically.  The
>interactive model has persisted on the Internet largely because there
>has been little pressing need to fix it. But this doesn't mean that it
>can't be. This is another way that amateur radio could give something
>back to the Internet community.

The Internet community already has a solution to this. Check out BFTP
(described in RFC 1068 and available from venera.isi.edu). It works very
well from my experience, especially recently (many people have upgraded to
new versions of the ftp daemon since the Morris worm).

There are also many sites out there who run 'shadow archives' by contacting
the official archive sites via FTP and retrieving all new files; this is also
all done automatically without user intervention.

Amateur Radio would be the ultimate stress-testing ground for these systems.
But they have already been invented, and there's no sense us re-inventing
them.

Improving them, on the other hand, would be worthwhile...

--
C. Harald Koch  VE3TLA                Alias Research, Inc., Toronto ON Canada
[e-mail]      [e-mail]      [e-mail]
"Open the Zamboni! We're coming out!" - Kathrin Garland and Anson James, 2299

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

Date: 26 Jul 90 03:54:50 GMT
From: linus!philabs!briar![e-mail]  (Robert Casey)
Subject: MFJ1270B,4 TX audio mod file
To: [e-mail]

copied from packet:
 Msg# TSF  Size #Rd  Date  Time From   MsgID        To
 3626 BF   1057   1 24-Jul 1806 W3CSG  2079_WB4D    MFJMOD@USA ()
 *Sb: More TX audio from MFJ1270B/1274

 Need more TX audio to drive a commerical radio or inject past the limiter?
 The following mod will increase the stock output from a MFJ1270B or 1274
 TNC from about 200mv with tone twist to about 500mv with no tone twist.

 Change R56 from 7.5K to 4.7K
 Jumper out cap C71
 Remove cap C73
 Install 1mfd caps at C34 and C35  (caps shown on board but missing)

 The above changes will make the TNC TX audio the same as the older
 MFJ1270 and TAPR TNC2 units.

 I am presently using this mod in order to drive Motorola and GE radios
 in my node stack.

 73 Royce W3CSG @ WB4D.VA.USA.NA

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

End of Packet-Radio Digest
******************************
Date: Sat, 28 Jul 90 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #99
To: packet-radio


Packet-Radio Digest         Sat, 28 Jul 90       Volume 90 : Issue  99

Today's Topics:
           Amiga Packet Terminal Pgm needed
         What's wrong with Internet on radio

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests 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".
----------------------------------------------------------------------

Date: 28 Jul 90 02:47:15 GMT
From: swrinde!emory!ducvax.auburn.edu![e-mail]  (HALL_MARK)
Subject: Amiga Packet Terminal Pgm needed
To: [e-mail]

Needed:  One packet terminal program for the Amiga.  I've been using
Online!, NComm, and AZComm, but I have problems with the backspace
embedding characters in the message.  Does anyone ahve or know where I may
find a good PD terminal pkg for packet that will overcome these problems?  Also,
if you know of any patches for these pgms, I would love to hear about them.
Thanks for any assistance!

73's de N4ZUK

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

Date: 27 Jul 90 16:55:39 GMT
From: hpl-opus!hpnmdla![e-mail]  (Glenn Elmore)
Subject: What's wrong with Internet on radio
To: [e-mail]

Bdale writes:

>
>The difficulties we face building high-speed packet networks on amateur radio
>are today much less based in technology than in human social systems.
>

 Amen.

and to a previous response I add:

( and yes, the ideal is *all* of packet radio point-point if we are
to make efficient use of our resources. We won't likely make it in
our lifetime, entry level/lower performance access and uncoordinated uses
like emergencies must be supported, but physics demands it for optimum
information transfer. Any omni use must be over vanishinly
small areas. My CNC submission re: this topic is almost done.)

Glenn Elmore -N6GN-

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

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

End of Packet-Radio Digest
******************************
Date: Sun, 29 Jul 90 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #100
To: packet-radio


Packet-Radio Digest         Sun, 29 Jul 90       Volume 90 : Issue 100

Today's Topics:
              Packet-Radio Digest V1 #99

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests 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".
----------------------------------------------------------------------

Date: Sat, 28 Jul 90 17:25:21 MST
From: mocvax!miranda![e-mail] (Marc Sarrel)
Subject: Packet-Radio Digest V1 #99
To: mocvax!elroy!UCSD.Edu![e-mail]

unsubscribe [e-mail]

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

End of Packet-Radio Digest
******************************
Date: Mon, 30 Jul 90 04:30:04 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #101
To: packet-radio


Packet-Radio Digest         Mon, 30 Jul 90       Volume 90 : Issue 101

Today's Topics:
                 Mailing list

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests 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".
----------------------------------------------------------------------

Date: 29 Jul 90 14:28:32 EDT
From: David Sweigert <[e-mail]>
Subject: Mailing list
To: <[e-mail]>

How can I get on the packet radio mailing list...?

[e-mail]

WB9VKO
cheers

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

End of Packet-Radio Digest
******************************
Date: Tue, 31 Jul 90 04:30:02 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #102
To: packet-radio


Packet-Radio Digest         Tue, 31 Jul 90       Volume 90 : Issue 102

Today's Topics:
             Multi-cast and packet radio
              Tip for PK-232/PK-88 Users

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests 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".
----------------------------------------------------------------------

Date: 31 Jul 90 01:57:36 GMT
From: mejac!orchard.la.locus.com!prodnet.la.locus.com!lando.la.locus.com![e-mail]  (Dana H. Myers)
Subject: Multi-cast and packet radio
To: [e-mail]

  I'm curious.

  Has anyone ever implemented multi-cast as part of TNC firmware?

   For those not familar, multi-cast is the ability for one network
interface to respond to a list of addresses. TNCs in KISS mode just
hand all data to the host; this is wasteful if the TNC can easily toss
out data that isn't intended for the host.

  Other kinds of network interfaces (like Ethernet) normally respond
only to a unique address and a broadcast address. Most Ethernet interfaces
may be programmed to respond to a list of addresses, with certain limitations.

  For instance, someone running NET might program their TNC to respond to
1. The station address (KK6JQ-3, for instance), 2. IP broadcast address (QST)
3. NET/ROM broadcast (NODES), 4. (you name some).

   For a station which is used mostly for keyboard to keyboard, this could
make a 9600 baud host interface useful with a high data rate channel (56 kb?).
Even running multiple AX.25 sessions and/or TCP isn't so bad. With a maximum
of 7 outstanding frames per AX.25 connection, a practical limit of 10 AX.25
sessions results in a maximum of 70 frames buffered before the "other guy"
shuts up and waits, even if it is for just one frame to be removed. TCP
set to a window of 432 bytes results in two oustanding frames on each
TCP session; this amounts to 2 frames/session, or 40 frames for 20 concurrent
sessions. Of course,  a user is not limited to 10 AX.25 sessions or 20 TCP
connections; exceeding these limits (or some combination of them) simply
results in increased possibility of overrun in the TNC. If the TNC dedicates
30k to frame buffers in an efficient manner, 100 buffers is not an
unreasonable number.

   While the mechanism is a little different, the synchronous nature of
the connections would result in an effective persistance of less than 1.0.
(essentially, hosts could not introduce traffic to the channel quickly
enough to be a channel hog).

 I'll address the issue of keyboard/keyboard on a high rate channel in
another posting.
*****************************************************************
* Dana H. Myers KK6JQ           | Views expressed here are      *
* [phone] (ex WA6ZGB)    | mine and do not necessarily   *
* [e-mail]                | reflect those of my employer  *
*****************************************************************

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

Date: 31 Jul 90 04:19:51 GMT
From: swrinde!cs.utexas.edu!milano!lad-shrike![e-mail]  (R M Kriss)
Subject: Tip for PK-232/PK-88 Users
To: [e-mail]

QST: Tip for PK-232/PK-88 Users

I have been having trouble getting my PK-232MBX to ACK the Austin TexNet
node. I could connect to AUSTIN, but could not get ACKs after the connect
and would retry out. I tried the WHYNOT command and was getting a note
about the received signal being below the DCD level. At this point I
messed with the Threshold setting and it did not help.

I contacted AEA and they suggested changing the CUSTOM setting from the
default setting of $0015 (or $0A15 on some models) to $0A14. I tried it
and it seems to have cleared my problem.

The binary of $0A14 is 101000010100 and when you read the manual you will
note bit 0 is now a '0' rather than the default '1'. The manual says
"...If bit 0 is set to 1, then the PK-232 will discard a received packet
if the signal is too weak to cause the DCD led to light. If set to 0 (the
AEA suggested setting $0A14), packets will be received regardless of the
setting of the Threshold control". Per telecon with AES, the $0A14 setting
increases the PK-232's sensitivity. (I question if it really increases
sensitivity)

Try it!

73 de Dick, KD5VU @ KB5PM.#AUS.TX.USA.NA
=====================================================================
   Richard (Dick) Kriss:  ARPANET: [e-mail]
      904 Dartmoor Cove:  Packet Radio: KD5VU @ KB5PM.#AUS.TX.USA.NA

    Austin, Texas 78746:  Phone: [phone] (O) or 327-9566 (H)
  My employer has nothing to do with this message! ...  _._
=====================================================================

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

Date: mon, 30 jul 90 11:40:00 mest
From: [e-mail]
To: [e-mail]

unsubscribe


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

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