HAM Radio 1/HamRadio.cdr/packet/packpro2/pd91030.txt

Internet Message Format | 1991-01-31 | 27KB

From wang!elf.wang.com!ucsd.edu!packet-radio-relay Thu Jan 31 16:13:58 1991 remote from tosspot
Received: by tosspot (1.63/waf)
    via UUCP; Thu, 31 Jan 91 21:31:51 EST
    for lee
Received: from somewhere by elf.wang.com
    id aa15335; Thu, 31 Jan 91 16:13:53 GMT
Received: from ucsd.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA02805; Thu, 31 Jan 91 09:39:02 -0500
Received: by ucsd.edu; id AA02236
    sendmail 5.64/UCSD-2.1-sun
    Thu, 31 Jan 91 04:30:30 -0800 for hpbbrd!db0sao!dg4scv
Received: by ucsd.edu; id AA02220
    sendmail 5.64/UCSD-2.1-sun
    Thu, 31 Jan 91 04:30:12 -0800 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -fpacket-radio-relay packet-radio-list
Message-Id: <[e-mail]>
Date: Thu, 31 Jan 91 04:30:06 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #30
To: [e-mail]


Packet-Radio Digest         Thu, 31 Jan 91       Volume 91 : Issue  30

Today's Topics:
                      2 DRSI Boards and NET/NOS?
                                <None>
                      Help! What is it? (2 msgs)
                   Need 56 Kbps info from .ba folks
                            Omni vs Beam?
                   Omni vs beam antennas. (4 msgs)
                       PACKET->Internet Gateway
                            Piccolo info.
                   Problem with NET and another TSR
                      Procomm Bug in Packet Use
                         Shareware on Packet
                      TCP/IP over long distances
                       Trolling for suggestions

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

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

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

Date: 17 Jan 91 20:39:07 GMT
From: pacbell.com!tandem!Tandem.COM![e-mail]  (Stuart Phillips)
Subject: 2 DRSI Boards and NET/NOS?
To: [e-mail]

In article <958400001@techsup>, [e-mail] writes:
|>
|>
|> a local ham, no newsgroup access, is trying to run nos with 2
|> DRSI boards.  he has the following:
|>
|> drsi pcpa type 2 @ 300h
|> drsi pcpa type 1 @ 310h
|>
|> both use int 7 (not sure if this is selectable on the board -- i
|>                 don't own drsi boards)
|>
STUFF DELETED
|> ... isit possible to use 2 drsi
|> boards with net or nos?  if so, what version of net/nos?  also,
|> i'd appreciate a sample set of attach commands for each board to
|> pass along.

The DRSI driver will only support one card; its not too difficult to change
but (as the author of the driver) I don't intend to make the change.  You
would be well advised to have separate interrupts for each board.

You should be able to configure the scc driver to handle two boards but
you will need two interrupts.  Unfortunately I dont have any example of
how this would be configured.

The interrupt is switch selectable on the board.

Good luck !
Stu N6TTO

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

Date: 17 Jan 91 20:34:34 GMT
From: att!pacbell.com!tandem!Tandem.COM![e-mail]  (Stuart Phillips)
Subject: <None>
To: [e-mail]

In article <[e-mail]> [e-mail] (Robert McGwier) writes:
>Howdy:
>
>Is there anyone on this net that can answer from first hand knowledge
>whether or not DRSI has closed its doors?
>

I saw an earlier posting asking the same question and so phoned DRSI this
morning.  Andy DeMartini assured me that he and his company were very much
still in the land of the living and doing well.  Seems I was the third person
to call and ask.

DRSI are 100% still in business - Mr D. is interested in discovering the
source of the rumor !

Stuart N6TTO

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

Date: 29 Jan 91 21:57:45 GMT
From: pacbell.com!tandem!tandem![e-mail]  (Kevin J. Rowett)
Subject: Help! What is it?
To: [e-mail]

In article <[e-mail]>, [e-mail] (Peach) writes:
|> I have discovered a packet radio signal, locally, on 412.875 MHz.
|> While it is not in the ham band, it sounds very similar to 1200
|> baud packet.

More than likely it is your local police department using AR packet
technology (DRSI may very have well sold it to them, Sunnyvale, CA
bought theirs from DRSI).  The modem frequencies aren't the same
to keep the obviously uneducated out, but it's not even encrypted.

N6RCE

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

Date: 30 Jan 91 16:17:56 GMT
From: sun-barr!cs.utexas.edu!evax!utacfd!letni!rwsys!kf5iw!k5qwb![e-mail]  (Lyn R. Kennedy)
Subject: Help! What is it?
To: [e-mail]

[e-mail] (Peach) writes:

> I have discovered a packet radio signal, locally, on 412.875 MHz.
> While it is not in the ham band, it sounds very similar to 1200
> baud packet.
>
Most likely this is a wind shear system at your local airport.
Signal strength should confirm that.
It's probably not anything similar to ax.25 but I have not examined
one, however I've never found x.25 signals in this band.

lrk

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

Date: 30 Jan 91 01:43:27 GMT
From: hpl-opus!hpnmdla!hpsadle![e-mail]  (Mike Ferrara)
Subject: Need 56 Kbps info from .ba folks
To: [e-mail]

We're working on a 2Mb/s one here. Expect the first hardware to
be running late '91. We'll be using either 3400MHz or 5700 MHz.


  Mike Ferrara M/S 2LRR
  HP Signal Analysis Div R&D
  1212 Valley House Drive
  Rohnert Park, CA 94928
  [phone]
  [e-mail]
  [e-mail]

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

Date: Wed, 30 Jan 91 15:03:05 GMT
From: "Pete Lucas, NCS-TLC, Holbrook House, Swindon" <[e-mail]>
Subject: Omni vs Beam?
To: [e-mail]

To all of you who have entered the above discussion...

Thanks!     you've just earned me a beer!!

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

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

Date: Wed, 30 Jan 91 11:45:18 EST
From: [e-mail] (Barry McLarnon DGBT/DIP)
Subject: Omni vs beam antennas.
To: [e-mail]

One situation in which I think it makes sense to use directional antennas
is a CSMA LAN with a full-duplex repeater.  The repeater typically has a
central location and uses an omni antenna (or separate omni receive and
transmit antennas).  If the users have directional antennas aimed at the
repeater site, there are several benefits: they are less likely to have
interference (from out-of-band sources causing intermod, or in-band sources
that the repeater can't hear), they radiate less energy away from the
intended coverage area, and the higher link margins allow the repeater ERP
and/or antenna heights to be reduced.  In essence, the gain antennas help
to define a "tighter" coverage area for the LAN, so the frequencies can
be re-used with less geographical spacing.  Of course, users near the
repeater can use omni antennas if they wish - it's more important for the
users on the fringes to use gain antennas, so as not to extend the
coverage (in terms of susceptibility and interference-causing potential)
of the LAN beyond that defined by the repeater itself.

Barry

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

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

Date: 29 Jan 91 17:54:41 GMT
From: hpl-opus!hpnmdla![e-mail]  (Glenn Elmore)
Subject: Omni vs beam antennas.
To: [e-mail]

> In rec.ham-radio.packet, [e-mail] (Paul Koning) writes:
>
>
>     Sure, CSMA requires/assumes you hear the other participants.  That's why
>     packet radio only faintly (at best) resembles CSMA: often you can't hear
>     other participants, and/or you hear non-participants.  The use of beams
>     aggrevates the former problem, while helping the latter.  Which one is the
>     bigger effect is likely to vary.
>
>     To put it bluntly, how much MORE broken could it get when you use beams?
>     Or when you don't, for that matter?

CSMA is not an efficient architecture to implement over a divergent
( radio ) environment. It indeed is "broken" when applied to radio.
Multiple Access does not coexist with efficient information (energy)
transfer in a radio environment. This is one of the points I attempted
to make in my paper in the 9th ARRL Computer Networking Conference
proceedings.
  However, if we are to exchange a large amount of information among a
large number of users over a wide area we *must* use directed beams.
Fortunately for amateur radio the fact that CSMA doesn't suit a network
of directed beams doesn't preclude other solutions.
For a comparison of a network of omni with one of directed beams and
some practical implications in an amateur radio environment please see
the paper.

73
Glenn Elmore n6gn

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

Date: 31 Jan 91 04:35:18 GMT
From: snorkelwacker.mit.edu!usc!cs.utexas.edu!uwm.edu!rpi!clarkson!@bloom-beacon.mit.edu  (Tadd, KA2DEW, ,3152621123)
Subject: Omni vs beam antennas.
To: [e-mail]



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

Date: 31 Jan 91 01:46:44 GMT
From: usenet.ins.cwru.edu!ncoast![e-mail]  (Brandon S. Allbery KB8JRR)
Subject: Omni vs beam antennas.
To: [e-mail]

As quoted from <[e-mail]> by [e-mail] (Dana H. Myers):
+---------------
|    If a topology was in use where a central node was serving a number
| of remotely located nodes, and these nodes could not hear each other
| anyway, and the remote nodes have poor signals into the central node, then
| using beams at the remote nodes would probably make sense, though the
| efficiency of this topology would never be as good as a completely
| interconnected topology.
+---------------

This is *exactly* the situation on 144.99 in NE Ohio; we have one central site
in Chardon, a few of us in Mentor and Painesville, and two outlying nodes (one
in the southern part of Geauga County and one near Youngstown).  The Chardon
node used a beam for a few months, then was switched to an omni.

In our particular case, the omni improved things for the Mentor and
Painesville nodes but didn't lose the "DX" nodes:  we (M/P) were working the
back of the beam, which was aimed at the distant nodes, and packets from the
northern end got lost quite often.  The DX nodes are still in the network
because they both have beams pointed at Chardon.

In this particular case, complete interconnection is rather difficult --- as
an example, I live in an apartment, which limits the height of antennas I can
put up (it's a real coup that I was permitted my Ringo at 25ft.!), but the two
remote nodes would require me to put up an antenna high enough to go over a
freeway overpass and a Finast superstore, respectively.  :-(  The other M/P
nodes have similar problems, and the DX nodes would have to drill signals
through hills to get to anything other than the Chardon node.  In this
particular case, therefore, beams are a win for the distant nodes but a loss
for the local ones.

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

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

Date: 31 Jan 91 06:20:54 GMT
From: julius.cs.uiuc.edu!rpi!uwm.edu!spool.mu.edu!sdd.hp.com!hp-pcd!hp-vcd![e-mail]  (Carl Peterson)
Subject: PACKET->Internet Gateway
To: [e-mail]

Although I know of know gateway/routers for connecting from amateur
TCP/IP or AX.25, I don't think that it would be very difficult to
create on; especially given that many internet connected machines
run Phil's TCP/IP code in preference to their original vendor
supplied code.

If you set up a gateway/router you would have to take a great
deal of care about what addresses could access which services.
Obviously, you could not allow a non 44. address to initiate
a connection to a 44 address.  This is doable.  Within HP we
restrict or gateways so that non-HP addresses cannot access our
subnet.  As the trustee of such a gateway I would be very nervious
about someone making such a connection.  I'd also be nervious
about the type of traffic going across my gateway/router, but
all amateur node operators suffer from that.  The SMTP handler
code would have to be configured to allow periodic trys to forward
over several days before bouncing mail to account for most
stations not being on the air at all times.  The only real problem
is registering the 44 address for routing purposes within internet.
Couldn't we set up an open internet name/domain server for 44
addresses across the country?

I've been thinking about a more limited system for AX.25 traffic.
Hosts could be set up for AX.25 which would act as a worm holes.
The interface would be like any of the popular packet BBS systems,
except that some of the nodes accessable would actually be similar
systems in distantly located cities.  The AX.25 packets would be
completely encapsulated in standard TCP/IP.  No access would be
given to internet at large thus protecting the trustees of the
nodes from problems about non-amateur access.  One of the biggest
frustrations I have with packet is not being able to connect 'live'
to friends in distant cities (no I don't have HF packet, and that's
not very reliable).  Think how this could substatually improve
the throughput of mail and emergency messages (assuming that
normal packet nodes are up and connect to an internet worm hole
host that is up).

            Carl Peterson N6RZA

+------------------------------------------------------+
|   Carl Peterson    [phone]                      |
|   Hewlett-Packard                                    |
|   Vancouver Division (R&D Lab)                       |
|   P.O. Box 8906                          |
|   Vancouver, WA 98668-8906                           |
|   HPDesk: Carl Peterson/HPD300/04                    |
|   Unix to Unix: [e-mail]                  |
|      {your path}!ucbvax!hplabs!hp-vcd!carlp          |
|   or {your path}!ucsd!hp-sdd!hp-vcd!carlp            |
|   CompuServe:  71301,2532                            |
+------------------------------------------------------+

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

Date: 31 Jan 91 11:10:46 GMT
From: mcsun!cernvax![e-mail]  (frode weierud)
Subject: Piccolo info.
To: [e-mail]

I recently posted a reply to a few of the articles that
delt with the multi-tone telegraphy system Piccolo.
Unfortunately I think I forgot to specify the distribution
and it was only posted locally so I will redistribute the
earlier posting.  Here comes ...


There has recently been some interest in the British
PICCOLO system and its French derivative COQUELET.

PICCOLO was developed back in 1957 by a team lead by
J.D. Ralphs at the Diplomatic Wireless Service, which
today is called the Communication Engineering Department
of the British Foreign and Commonwealth Office.  The
PICCOLO equipment has gone through several complete
redesigns.  The first equipment occupied a major part of
a standard 19 inch rack, while today's unit, PICCOLO Mk 6,
which is made by RACAL and is commercially available as
LA 1117 is a rather small unit by comparison.

PICCOLO is still in use by the British Foreign Office as
its main HF communication mode and several frequencies
are daily active for this purpose on HF bands.

PICCOLO and its development has been described in detail
in several publications, the first article appeared in 1963.

1)   H.K. Robin, D. Bayley, T.L. Murray and J.D. Ralphs,
     "Multitone signalling system employing quenched
     resonators for use on noisy radio-teleprinter
     circuits", Proceedings of I.E.E., Vol. 110, No. 9,
     September 1963, pp. 1554-1568.

2)   D. Bayley and J.D. Ralphs,
     "Piccolo 32-tone telegraph system in diplomatic
     communication", Proceedings of I.E.E., Vol. 119, No. 9,
     September 1972, pp. 1229-1236.

3)   J.D. Ralphs,
     "The application of m.f.s.k. techniques to h.f.
     telegraphy", The Radio and Electronic Engineer,
     Vol. 47, No. 10, October 1977, pp. 435-444.

4)   J.D. Ralphs,
     "An improved 'Piccolo' m.f.s.k. modem for h.f.
     telegraphy", The Radio and Electronic Engineer,
     Vol. 52, No. 7, July 1982, pp. 321-330.

5)   J.D. Ralphs,
     "Principles and practice of multi-frequency
     telegraphy", (book), Peter Pelegrinus on
     behalf of The Institute of Electrical Engineers,
     Peter Pelegrinus Ltd., London 1985,
     ISBN 0-86341-022-7.

There have as well been a few non-technical articles on
PICCOLO and COQUELET in Monitoring Times.

6)   Jack Albert,
     "Just When You Thought It Was Safe to Turn on the
     Radio", Monitoring Times, February 1989, page 47.


7)   Jack Albert,
     "U.S. Hobbyist First to Copy Piccolo",
     Monitoring Times, July 1989, page 47.

8)   Jack Albert,
     "Piccolog", Monitoring Times, August 1989, page 47.

9)   Jack Albert,
     "A New Piccolo System", (The French Coquelet System)
     Monitoring Times, March 1990, page 47.


The only decoder available on the market that can decode
both PICCOLO and COQUELET is CODE3 from HOKA Electronics,
The Netherlands, equipped with the PICCOLO and COQUELET
options.

73 de Frode, LA2RL/HB9CHL

**************************************************************************
*    Frode Weierud        Phone    :    [phone]         *
*    CERN, SL        Fax    :    [phone]         *
*    CH-1211 Geneva     23    E-mail    :    [e-mail]     *
*    Switzerland               or    [e-mail]     *
**************************************************************************

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

Date: 31 Jan 91 03:06:51 GMT
From: epic![e-mail]  (Phil R. Karn)
Subject: Problem with NET and another TSR
To: [e-mail]

In article <[e-mail]>, [e-mail] (Bob
Gettys N1BRM) writes:
>
>I'm having a problem wich I hope someone on the net can help with. I'm
>running the KA9Q Internet Protocol Package, v890421.1i.tl DS=7a57 with
NET/ROM
>support added by Dan Frank, W9NK and Window support by Frank Knight,
KA1SYF.

That is a *really* old version.

>I'm also trying to run the WXDATA program for the Heath ID-5001
weather
>computer. They have a definite interaction that hurts only the KA9Q
net
>program. Without the WXDATA TSR running, the net program runs just
fine. With
>the WXDATA program running, the net program gets many bad checksum
packets to
>the point that communications is immpossible.

Offhand, I suspect that your WXDATA TSR is taking over the machine
with interrupts disabled for long periods of time, starving the
interrupt handlers in NET that handle the serial port. This results in
lost characters and corrupted packets.

Your best bet is to a) upgrade to a recent version of NOS and b)
replace your 8250 or 16450 serial chips with NS16550A chips. These
chips provide 16-byte FIFO buffering on both transmit and receive
which substantially reduces interrupt latency requirements; hopefully
this will give you the margin you need to run WXDATA and NOS at the
same time.

NOS is required here because the 16550A chips require a little extra
software to enable FIFO mode that is not in the old NET versions.
However,
the 16550As will work fine with your other communication programs, even
those that don't know about them, because they come up in 8250
compatibility
mode by default.

Phil

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

Date: 30 Jan 91 21:02:18 GMT
From: sdd.hp.com!samsung!rex!uflorida!mlb.semi.harris.com!trantor.harris-atd.com!x102c.ess.harris.com![e-mail]  (Gary Bastin 60293)
Subject: Procomm Bug in Packet Use
To: [e-mail]

In the process of debugging a packet AX.25 LAN, an obscure bug was
discovered in Procomm Version 2.4.X, as well as Procomm Plus.
Namely, if there is a busy channel, with collisions, the XON/XOFF
function of Procomm doesn't work properly.  Procomm, all versions,
has a built-in timer of ~20 seconds that times the duration from
the last XOFF.  If, within this 20 seconds, XON is not performed,
then after 20 seconds, Procomm assumes that a noise burst caused
the XOFF.  Data is then dumped anyway.  For the case of sending a
file, and if collisions occur, then the tnc may not be ready to
receive more data within 20 seconds.  If this is the case, then
the tnc buffer is overflowed!  This was the case on a military
AX.25 LAN!

As for the fix, Datastorm Technology has a patch program called
DT_PATCH which can patch the Procomm Plus executible to set the
timer from 20 seconds up to 18 hours.  As received out of the box,
though, Procomm Plus has the 20 second feature/bug.  The patch
program must be run to fix the problem.  No patches exist for the
older shareware versions 2.4.X, and Datastorm plans no future
patches to these versions.  Fortunately, an upgrade from the
shareware versions 2.4.X to the new Procomm Plus is available for
$39.00.  This is better than the full retail price of $119.

Hopefully, knowledge of this feature/bug in Procomm, all versions,
may save someone else some grief!  73, Gary


Gary Bastin, WB4YAF      /-/-/      Internet: [e-mail]
Mail Stop 102-4826         |        phone: [phone]
Harris Corporation GASD    |
P.O.B. 94000, Melbourne FL 32902    Speaking from, but not for, Harris!

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

Date: 31 Jan 91 04:40:34 GMT
From: sdd.hp.com!uakari.primate.wisc.edu!umriscc!maverick.ksu.ksu.edu!matt.ksu.ksu.edu![e-mail]  (Steve Schallehn)
Subject: Shareware on Packet
To: [e-mail]

A question was posed to me by an amateur who is interested in getting
into packet.  It seems he has a large collection of shareware on his
land-line BBS and he was wondering if he could legally set up his
BBS on packet and allow shareware downloads.

I know about the avoiding business in amateur radio, but does
shareware count?

-Steve Schallehn, KB0AGD
 Kansas State University

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

Date: 31 Jan 91 04:56:22 GMT
From: maverick.ksu.ksu.edu!matt.ksu.ksu.edu![e-mail]  (Steve Schallehn)
Subject: TCP/IP over long distances
To: [e-mail]

In the last issue of QEX magazine, the "Gateway" had a listing
of finger and mail services for TCP/IP.  A question popped into my
head as why such a list was given in a national magazine.

Since we do not have a nationwide TCP/IP network in the USA, is
connectivity to these services a problem or is it
possible for ANY TCP/IP'er to use these services.


-Steve Schallehn, KB0AGD
 Kansas State University

PS:  I just got my IP address and I don't have anyone to talk to! :-(

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

Date: 31 Jan 91 05:28:20 GMT
From: usc!ucselx!petunia!csuchico.edu![e-mail]  (John Kennedy)
Subject: Trolling for suggestions
To: [e-mail]

  How is this for getting my feet wet?

  I've just got my license (sent in the paperwork near Xmas, got the license
today -- KC6RCK).  What I'm looking to do is latch a packet radio onto a UNIX
machine.  The goal is to get all the advantages of packet TCP/IP without
actually having to resort to an IBM.  (-:

  I do have the UNIX machine.  I've yet to get the transceiver, but I'm
thinking about a Kantronics KAM (lots of goodies to use, some overkill, but
a few that I'd like to take advantage of eventually, with a bay for an extra
modem).  Then it's off to scrounge for the rest.

  If anybody's already done this, I'd be interested in hearing from them, as
well as any commonts from other people.
--
Warlock, AKA        +-----------------------------------------------+
John Kennedy        |    internet:       [e-mail]    |
 CSU Chico        +-----------------------------------------------+
   KC6RCK             IBM, You BM, We All BM for IBM!

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

Date: (null)
From: (null)
Pete,
  Using omni directional antennas would only be better if it was your
intention to have all of the stations on the frequency able to hear
each other.  That means that there could only be one LAN on the frequency
in your whole region.  This might be greedy, depending on where you were.
  Using beams puts you in a classic hidden transmitter syndrome situation.
One of the solutions to that situation occurs when there is only one
station that does 95% of the transmitting.  In that case all you must make
sure of is that the one station is heard by everybody else.  Thus the beams.
In that senario the one station is -more or less- controlling the
frequency.  It actually works.  What you have to do is keep the other
stations from transmitting alot of data.
  One application of this is where a BBS has it's user access port on a
2m channel.  The users access the BBS on that channel and perhaps route
through the BBS using the G8BPQ driver to the network.  THe BBS MUST do
its forwarding and network linking on another, non-interfering frequency.
                                     Tadd - KA2DEW

[ North East Digital Association - Editor             Tadd Torborg ]
[ Clarkson University, Potsdam NY                     Box 330      ]
[ [e-mail]                         Colton NY    ]
[                                                     315-262-1123 ]
[ Remember, if you win the rat race, you're still a rat            ]

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

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