HDTenEightyP/NetNews huggingface dataset:
From: bcoleman@hayes.com (Bill Coleman)
Newsgroups: rec.radio.amateur.policy
Subject: Re: ARRL Plan - The next step?
Date: 14 Aug 92 17:49:23 EDT
Organization: Hayes Microcomputer Products, Norcross, GA

In article <14600034@hpnmdla.sr.hp.com>, alanb@hpnmdla.sr.hp.com (Alan Bloom) writes:
[ discussion of ARRL broadcast legality deleted ]
> 
> 97.101(d)
>      No amateur operator shall willfully or maliciously interfere
>      with or cause interference to any radio communication or signal.
> 
> Any interference caused cannot be willful (or certainly malicious)
> if the transmitting operator does not know there is someone on frequency.

Excellent point!

Now, explain to me how an automated packet station could be in violation
of 97.101(d) if there were other users (most likely using a different mode)
on the frequency at the time.

Since this is a major contention of the current ARRL digital proposal, 
perhaps we can upset the apple cart by pointing this out.

-- 
Bill Coleman, AA4LR                ! CIS: 76067,2327    AppleLink: D1958
Principal Software Engineer        ! Packet Radio: AA4LR @ W4QO
Hayes Microcomputer Products, Inc. ! UUCP: uunet!hayes!bcoleman
POB 105203 Atlanta, GA 30348 USA   ! Internet: bcoleman%hayes@uunet.uu.net
Disclaimer: "My employer doesn't pay me to have opinions."
Quote: "The same light shines on vineyards that makes deserts." -Steve Hackett.
From: jbloom@arrl.org (Jon Bloom)
Newsgroups: rec.radio.amateur.policy
Subject: Re: ARRL SNAFU
Date: 17 Aug 92 16:07:59 EDT
Organization: American Radio Relay League

In rec.radio.amateur.policy, paulf@w6yx.Stanford.EDU (Paul Flaherty) writes:
>(34) An amateur station that automatically retransmits the signals of
>	other stations.
>
>
>Sounds like UAA digital operations would fit right in.

There's a Catch 22 embedded in this reasoning.  To wit: if a digipeater
(or BBS, or whatever) is a repeater, it can't be operated below 29.5
MHz *at all* per 97.205(b).

No, in spite of the definition, FCC doesn't consider a store-and
forward digital device a repeater as defined in 97.1.  The distinction
appears to be the *unaltered* retransmission of a repeater vs. the
*altered* retransmissions of a digital station.  That is, the digital
station doesn't retransmit an exact copy of the bits, or signal, it
receives.  (Please, no nitpicking about distortion in audio repeaters.)

Unfortunately, you can't call the digital box a repeater in order to
apply the freedoms allowed a repeater and then turn around and call
it *not* a repeater to avoid the restictions placed on repeaters!

   [deleted]
>This is *the* problem.  Clearly the non-WARC HF bands are pretty full.  So,
>it is only fitting that new spectrum be used for new operations.   If this is
>not the case, that ham radio as we know it is dead; the strength of existing
>operations is such that no new modes or operations may be introduced.

Succintly put.
-------
Jon Bloom, KE3Z                   |  jbloom@arrl.org
American Radio Relay League       |
225 Main St.                      |
Newington, CT 06111               |
Newsgroups: rec.radio.amateur.packet
From: ag807@cleveland.Freenet.Edu (Steve Wolf)
Subject: Re: APLink and RTTY MBOs
Organization: Case Western Reserve University, Cleveland, Ohio, (USA)
Date: Wed, 19 Aug 92 11:10:32 GMT


Hi ....
     For a source of APLINK or RTTY programs you might try anyone
on the ARRL Digital Committee.
73,
Steve, NO8M

-- 
Xref: sparky rec.radio.amateur.packet:2212 rec.radio.amateur.misc:14159
From: gary@ke4zv.uucp (Gary Coffman)
Newsgroups: rec.radio.amateur.packet,rec.radio.amateur.misc
Subject: Re: New packeteer frustration
Date: 20 Aug 92 12:23:36 GMT
Reply-To: gary@ke4zv.UUCP (Gary Coffman)
Organization: Gannett Technologies Group

In article <5888.2a92524b@hayes.com> bcoleman@hayes.com (Bill Coleman) writes:
>In article <1992Aug17.125034.22941@ke4zv.uucp>, gary@ke4zv.uucp (Gary Coffman) writes:
>> 
>> Direct FSK symbol encoding is second only to AFSK in being spectrally
>> inefficient and error prone on a HF channel. 
>
>Nope. I'm afraid that OOK takes the top prize! (On / Off Keying)

No, on/off keying is fairly spectrally efficient, better than FSK. With
weak signals and poor decoders, it's error rate can be higher though.

>> PSK methods available today can push 9600 bps over good HF channels. 
>
>There's a couple of problems using PSK over normal HF channels. First of
>all, most crystal filters in HF radios have really gross phase characteristics.
>This causes some signal degradation with FSK, but more with PSK.

Well if you insist on using Japanese voice radios, you shouldn't expect
good performance. Military radios with mechanical filters don't seem to
have a problem.

>Second, (and most important) is that multipathing of HF signals introduces
>tremendeous phase distortion. The only way to combat this problem is to
>lower the symbol rate so that the distortions don't last longer than the
>symbols. (Which is also why 45 baud RTTY and even 100 baud AMTOR work
>on 80m, but 300 baud packet does not)
>
>Another way to combat the multipath distortion problem is to always operate
>near the MUF, which results in clean, single path signals. Tom Clark had
>some success running 1200 baud PSK on 10m, for example. 

Multipath selective fading can be a serious problem. Operating near the
MUF is the best dodge around this, but diversity reception will also 
help a lot. 9600 bps on HF is not going to be a weak signal mode.
Systems like Piccolo and Clover that use multiple carriers to transmit
bits in parallel with long symbol durations are likely a more robust
way to go at HF.

>> But the rules prevent it.
>
>Not really. The rules dictate a maximum symbol rate (300 baud below 28 MHz)
>and a maximum shift (1000 Hz below 30 MHz). Other than that, the rules are
>remarkably open.
>
>Of course, you'd have a hard time stuffing 9600 bps data down a channel
>with the characteristics of most HF radios....

You can encode 9600 bps into 600 baud, but cramming it into 300 baud
is a remarkable achievement even on excellent circuits. With the quality
of typical HF paths, QPSK is about all you could do today. I'd love to
be proven wrong of course.

Gary KE4ZV
Newsgroups: rec.radio.amateur.packet
From: michel@neptunus.rivm.nl (Michel van Best)
Subject: KA9q with slip and ethernet
Organization: RIVM
Date: Thu, 13 Aug 1992 07:40:20 GMT

Hello,

I'm using KA9q as a slip host. Now i have a connection to the ethernet.  
Now i was wondering if its possible to route the slip packets to the ethernet. Is this possible
with ka9q?


Thanks Michel



-- 
                            Michel van Best		
EMAIL: michel@rivm.nl      Phone: +31 30 742984          FAX: +31 30 742971
      National Institute of Public Health and Environmental Protection
              P.O. Box 1, 3270 BA, Bilthoven, The Netherlands
From: dgilmour@osc.COM (David Gilmour)
Newsgroups: rec.radio.amateur.packet
Subject: NOS Hackers -- help
Keywords: NOS TCPIP
Date: 22 Aug 92 18:31:08 GMT
Organization: Versant Object Technology, Menlo Park, CA

I am having problems successfully building NOS from several sources off
UCSD.EDU -- and can't seem to locate any documentation that gives hints
for debugging NOS when the program is very large compared to available
memory.  Can anyone suggest a document that helps beginning NOS hackers
and/or addresses issues related to building NOS in Borland C++ 3.0?  I
also could use a hint as to what is the most stable version to work
from these days.  NOS_1229 seemed OK, but has loads of compile errors
(at least, the version from UCSD.EDU seems to...)  Thanks! Dave, WQ1K
(dgilmour@osc.com)
From: Jay.Townsend@f3.n346.z1.spk.wa.us (Jay Townsend)
Newsgroups: rec.radio.amateur.packet
Subject: Hostmaster vs Ka-Gold...comments?
Date: 17 Aug 92 22:06:44 GMT


 MM> Newsgroups: rec.radio.amateur.packet
 MM> Reply-To: rapw20@email.sps.mot.com

 MM> Does anyone have any comments regarding Hostmaster vs Ka-Gold for a KAM? 

Well I have used both.  There is a lot of difference in the two pieces of
software, but each does do similar things.  The KaGold is a very nifty piece of
software.  I am reviewing it in the next issue of the RTTY Digital Journal and
have previously reviewed the HostMaster II.  

There is a test drive of the KAgold which is available I would try it before I
purchased it.  The KaGold so far seems to win the race.  Its fabulous on Packet
and works quite well in the other modes.  Has some very nice features. I think
the HostMaster's screen is easier to configure.

KaGold does things quite different from traditional amateur software, it has
conferences, file transfers and lots of bells and whistles.  Hostmaster II
seems to do most things fine.  Both are examples of pretty good software in my
opinion and each harness' the power of the KAM.

Each also still has some minor bugs in the software.  Gosh they hate it when I
point those out :-)  But each appears to still be in dynamic change.  I think
that some of the features in HostMaster II grew out of things in KaGold, which
is a nice competitive spirit.

73, Jay Ws7i



 * Origin: Radio Therapy BBS (1:346/3)
Newsgroups: rec.radio.amateur.packet
From: towne@unixg.ubc.ca ()
Subject: MFJ 1278 GOING BRAIN DEAD IN KISS MODE ! PLEASE HELP !
Summary: WORKED FOR 1 YEAR IN KISS MODE AND THEN STOPPE.
Keywords: WORKS IN AX.25 MODE ,BUT NOT IN KISS MODE
Organization: University of British Columbia, Vancouver, B.C., Canada
Date: Thu, 20 Aug 1992 23:19:58 GMT


Well I have been using the MFJ 1278 for TCP/IP (KISS MODE) working 
flawlessly for the last year. Well now when I start up kiss mode and
start running msys or ka9q it works for a few seconds, and then
stop working. (Specifically it will not key the transmitter.)
PS-The battery inside the TNC is fine (first thing i checked).


The kicker:

If I use AX.25 mode and run normal packet it works perfectly.
I called MFJ and they said that they want me to ship it to them
for a modification for $60 US. (PS it is out of warranty)

IF you even think that you might have an idea, I would appreciate
any help, suggestions, hints.

Sincerely
Jerry

Newsgroups: rec.radio.amateur.packet
From: tedwards@src.umd.edu (Thomas Grant Edwards)
Subject: Re: Packet Networks today and tommorrow
Organization: Systems Research Center, Maryversity of Uniland, College Park
Date: Thu, 20 Aug 1992 20:07:51 GMT

>In rec.radio.amateur.packet, gary@ke4zv.uucp (Gary Coffman) writes:
>>Al Gore, yes *that* Al Gore, is pushing a bill to commercialize the 
>>networks we are now using for free. When we start receiving a monthly 
>>bill based on bits/buck, using the landline networks is going to look 
>>a lot less attractive. I just want people to keep their options open. 
>>If we lock ourselves into the landlines for long haul packet, we may
>>regret it later.

(excuse me if I messed up the author of the quote...)

Which bill are you referring to?  I understand the NREN will be a
national research and education network paid for by the government.
It might be capable of providing pay services, but the internet
already is (Well, CARL, etc.)

Incidently, I'd wager Al Gore is the only person on a presidential
ticket who even knows that the internet is.

de N3HAU
From: BTITMARS%ESOC.BITNET@vm.gmd.DE (BARRY TITMARSH)
Newsgroups: rec.radio.amateur.packet
Subject: DX Cluster systems
Date: 22 Aug 1992 18:50:27 -0700
Organization: European Space Agency
NNTP-Posting-Host: ucsd.edu

I know that the current DX Clusters use netrom and an agressive VC mode
to get the information to its logged on users.. Has any one thought that
the TCPIP telnet session is far more efficient way of doing the same thing
with out so much QRM on the much used links, Then perhaps the 3.rd world
wars that are currently happening in most parts of Europe between tcpip users
and the DX Cluster users who think that the DXC is the only thing on the
network, may stop.. Thoughts? after all Netrom is dead! is it not..
hi tech tcpip auto-routers are far more efficient..
Barry...
DC0HK / G8SAU sometimes GM8SAU/ GB7SAU mostly 44.130.24.71-74
Flames please..
From: michael.solinas@gate.micromed.com (Michael Solinas)
Newsgroups: rec.radio.amateur.packet
Subject: Standard C528A Mods
Date: 17 Aug 92 12:55:00 GMT
Reply-To: michael.solinas@gate.micromed.com (Michael Solinas)
Organization: Micro-Medic Network Gateway - +1 408 280-1610 - Public access BBS

I have heard that someone has worked out mods for the Standard C528A
handheld.  Does anyone here have a copy that they could send me?  I'm
interesting in opening up the receive range.
                                                                        
Newsgroups: rec.radio.amateur.packet
From: andyw@aspen32.cray.com (Andy Warner)
Subject: Re: New packeteer frustration
Originator: andyw@aspen32
Organization: Cray Research, Inc.
Date: 21 Aug 92 15:46:21 CDT


In article <20850@nntp_server.ems.cdc.com>, tbruseha@kafka.ems.cdc.com (Tom Brusehaver) writes:
> In article <15046@ksr.com> jfw@ksr.com (John F. Woods) writes:
> >tbruseha@kafka.ems.cdc.com (Tom Brusehaver) writes:
> >>All this frustration of long distance stuff, rules and other info got
> >>me thinking.  Are there any rules about how fast someone can send CW?
> >>I doubt it.  WHat if computers were sending CW (I think the rules
> >>specify morse, which is fine), how fast can they listen?  On 80 meters
> >>a cycle takes about 2.7e-7 seconds, if you could get computers to deal
> >>with 3-5 cycles as a dit, and 9-15 cycles as a dah, you could really
> >>push some bits trough.
> >
> >First, calculate the bandwidth of the proposed modulation scheme.
> 
> 
> Ahh, 1Hz?.. I am talking CW (Carier Wave).
> 
> [...]
> There was an aritcle many years ago about a Z80 based morse reader
> that was good to maybe 80-100WPM.  Ok fine, how about upping that to a
> 68020, or a RISC chip, could that reliable handle 500-1000WPM (more?).
> With current DSP chips the S/N ratio could be pretty good before the
> morse reader ever saw it.  How fast can the xmitter be keyed, that
> might be more of a limiting factor.  It ain't gonna be cheap, but we
> are talking about the inter-city links for the long distance network.

And thinking about it, the BW isn't going to be 1Hz any more,
either. There are better ways to tackle this.. Ways that actually
exploit the things DSP is good at..

> Another alternative that telebit uses are multiple carriers (tones)
> allowing for more 'parallel' transmissions.  Using DTMF tones would
> give you 8 bits at a time.  Are there rules about this?  

Clover & piccolo work along these lines (getting more bits per baud).

-- 
andyw.	N0REN/G1XRL

andyw@aspen.cray.com	Andy Warner, Cray Research, Inc.	(612) 683-5835
From: adsb@bnr.co.uk (Andrew Benham)
Newsgroups: rec.radio.amateur.packet
Subject: Pac-Comm KISS mode
Date: 12 Aug 92 12:17:14 GMT
Distribution: rec.radio.amateur.packet
Organization: BNR Europe Limited, Harlow, GB

(From G8FSL: home QTH London, UK)
A few of us in London running TCP/IP, using Pac-Comm TNCs in KISS mode,
are having problems with packet collisions.
Even on a quiet frequency with just 2 stations 6 miles apart using a direct
link (link quality to all intents is 100%), one TNC will transmit while
the other station is still sending packets. This naturally slows the link
down enormously.
We've done experiments with frame lengths, persist values, slottimes, and
cannot fix the problem UNLESS we ditch the Pac-Comm code (version E1.1.6D4)
and run G8BPQ KISS code. Unfortunately this means that the TNC cannot be used
for vanilla AX25 use without changing the ROM back.

This problem happens with TNC2 clones running Pac-Comm software, and also
with the TNC-220 (mind you, the TNC-220 has so many problems with KISS mode
{locks up at power on if signal is received during startup sequence, if
configured to use port 1 it switches to port 2 when the first transmit
packet is sent from the computer}). If we use PK-232s there is no problem,
and (as stated above) G8BPQ KISS ROMs work OK in the TNC2s. Unfortunately
G8BPQ TNC220 KISS ROMs don't seem to transmit ... ever!

Is there a known problem in this area, and can anyone suggest a fix
(especially for the TNC-220s, which are gathering dust as a result)?

73, Andrew    adsb@bnr.co.uk
              g8fsl@g8fsl.ampr.org [44.131.19.45]
From: alanb@hpnmdla.sr.hp.com (Alan Bloom)
Date: Thu, 13 Aug 1992 19:19:42 GMT
Subject: Re: How to power a PC motherboard from car battery?
Organization: Hewlett-Packard, Santa Rosa, CA
Newsgroups: rec.radio.amateur.packet

In rec.radio.amateur.packet, dannie@coplex.com (Dannie Gregoire) writes:

>I would like to set up a portable packet station for use in my car.
>I would like to avoid the cost of purchasing an expensive DC-AC
>(cigarette lighter) power converter, and instead downgrade/condition the 
>power for use directly into the motherboard--no standard PC power
>supply needed.

The PC uses +5V, -5V, +12V and -12V as I recall.  

+5 is no problem if you don't mind wasting a lot of power in the 5V
regulator.  You'll need a large heat sink.  You could also build
a simple buck converter (switcher) to regulate more efficiently.

+12 is used for the disc drives and serial interface.  Use a low-
dropout type regulator from the car battery (about +13V).

-12 V is normally only used for the serial interface.  A low-current
DC-DC converter IC should suffice.

I think -5V is not normally used.  You can probably leave it out.

AL N1AL

Newsgroups: rec.radio.amateur.packet
From: mark@adec23.uucp (Mark Salyzyn)
Subject: Re: Data Carrier Detect and Packet
Organization: ADEC Systems Inc.
Date: Fri, 14 Aug 92 21:20:18 GMT

jangus@skyld.UUCP (Jeff Angus) sez:
>The MFJ-1270b does not have "true" DCD ...
You mean a fully functional DCD. They detect DCD with a state machine (digital),
but when it drops out due to noise or signal strength, the packet is lost by
another (impatient) TNC starting to transmit. The DCD mod from TAPR hangs
the DCD on to allow for this poor noise response.

>Since most VHF packet is done on FM, and most FM stations are either there or
>they aren't, simple 'is there noise present' DCD works.
But this is flawed as this requires your Squelch control to be on threshold,
or at least track the background noise. In practice, many set the control
too high and cause hidden transmitter problems. Idealy, the squelch threshold
on typical rigs should be set so that it breaks open with no signal about
once every ten seconds ... `just' on threshold.

>Unfortunately it also thinks the channel is busy when it hears music, voices,
>intermods etc.
And this is BAD? Ok, so you want to transmit a packet when you have no
hope of hearing the ack packet? This causes a problem ONLY for impatient
people that know not what they do.

>The trick to HF packet is to set the receive audio level so that the background
>noise just barely get the (stupid) DCD circuitry to flicker and then back off a
>bit.
True, but a state machine (digital) DCD still works better here than noise
based units.

Ciao, 73 de VE6MGS/Mark -sk-
Newsgroups: rec.radio.amateur.packet
From: kwfriber@mtu.edu (Kenberg Frieth)
Subject: Re: New packeteer frustration
Organization: Michigan Technological University
Date: Wed, 19 Aug 1992 23:26:59 GMT

In article <20489@nntp_server.ems.cdc.com> tbruseha@kafka.ems.cdc.com (Tom Brusehaver) writes:
>
>All this frustration of long distance stuff, rules and other info got
>me thinking.  Are there any rules about how fast someone can send CW?
>I doubt it.  WHat if computers were sending CW (I think the rules
>specify morse, which is fine), how fast can they listen?  On 80 meters
>a cycle takes about 2.7e-7 seconds, if you could get computers to deal
>with 3-5 cycles as a dit, and 9-15 cycles as a dah, you could really
>push some bits trough.  Assuming you had a really good error
>correction code, there could easily be reliable communications.  If
>the computers paid attention to error rates, the speed could vary
>depending on noise, and other stuff.
>
>Or we could plead with the ARRL to change the rules (Sorry, couldn't
>resist, I thought the ARRL ran the FCC).

The only problem is making them hear each other.  The faster you send, the
wider your signal is.  9600 baud PSK is about as wide as an FM voice channel
(not quite, but close enough), and going faster would just be worse.  One 
possibility would be to use tone encoding so that each baud represented several
bits.  If you could handle 4 tones instead of 2, you could fit twice as much 
data in the same period of time.  I don't know how much more bandwidth that 
would require, however.

73 de n8pbe

Newsgroups: rec.radio.amateur.packet,rec.radio.amateur.misc
From: awoodhull@hamp.hampshire.edu
Subject: Re: New packeteer frustration
Organization: Hampshire College
Date: Mon, 17 Aug 1992 13:38:11 GMT

In article <q47m26a.feustel@netcom.com>, feustel@netcom.com (David Feustel) 
   writes:

> ...My impression is that packet is just toooo slow
> for me. I can connect to Australia via ftp at kilobytes/sec. This
> makes packet seem rather useless to me at the moment, 

Packet certainly isn't the Internet, but a lot of people in other
countries, or for that matter, young people, people with non-technical
professions and many others in the developed world *do* have access to
ham radio.

Those of us with some experience have seen a lot of progress... When I
first got into  ham radio I made many interesting (to me) contacts with
5 words/minute Morse, and by the time I got up to 20 words/minute I
realized it was true that, given all the abbreviations possible with
Morse (the equivalent of modern digital compression techniques?) and
all the non-informative  time-wasting words that are heard in the usual
voice radio contact, it was true what the old-timers said, that Morse
can be a satisfying way of carrying on a conversation and transmitting
useful information.

My first on-line experiences were with a 110 baud modem. It hurts now 
when I have to use 1200 instead of 2400 baud to connect to some
systems, but back then 110 baud opened  up wonderful possibilities for
access to powerfal facilities,  file transfer, and e-mail.

My first computer had 256 bytes of available memory which could be
programmed only by switches that entered data in binary. I would
*never* go back to such a system, but at the time it presented an
enormous range of interesting, and, yes, even useful possibilities.

At a later stage that computer used cassette tape at 2400 baud for mass
storage. It seemed OK at the time, but when I got a floppy disk I never
wanted to go back. When I got a hard disk I never wanted to use
floppies again.  My Apple seemed pretty fast before I saw an XT, and
that seemed  fast enough until I got my 486...

The point I want to make is that at each level there are useful things
that can be done. Let's not discourage those who don't have Internet
access by denigrating packet radio. Packet is still useful for many
purposes. 

Just as with the comparison I made between efficient Morse and sloppy
voice communication, it is worth keeping in mind that wider bandwidth
and faster hardware doesn't always get the job done better.  When I
graduated from a 256 byte to a 16 Kbyte computer it allowed me to write
programs in BASIC rather than setting bits, but the programs actually 
executed more slowly. Much of the power of today's PCs and Macs is used
to create easy-to-use graphic interfaces, but the programs that run in
these environments are slowed because so many resources are being used
to provide user convenience.

73 de Al Woodhull   N1AW
awoodhull@hamp.hampshire.edu



From: alanb@hpnmdla.sr.hp.com (Alan Bloom)
Date: Thu, 20 Aug 1992 19:59:05 GMT
Subject: Re: Packet speed
Organization: Hewlett-Packard, Santa Rosa, CA