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: <[email protected]> Date: Thu, 31 Jan 91 04:30:06 PST From: Packet-Radio Mailing List and Newsgroup </dev/[email protected]> Reply-To: [email protected] Subject: Packet-Radio Digest V91 #30 To: [email protected] 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: <[email protected]> Send subscription requests to: <[email protected]> Problems you can't solve otherwise to [email protected]. 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: [email protected] (Stuart Phillips) Subject: 2 DRSI Boards and NET/NOS? To: [email protected] In article <958400001@techsup>, [email protected] 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: [email protected] (Stuart Phillips) Subject: <None> To: [email protected] In article <[email protected]> [email protected] (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: [email protected] (Kevin J. Rowett) Subject: Help! What is it? To: [email protected] In article <[email protected]>, [email protected] (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!lrk@apple.com (Lyn R. Kennedy) Subject: Help! What is it? To: [email protected] [email protected] (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: [email protected] (Mike Ferrara) Subject: Need 56 Kbps info from .ba folks To: [email protected] 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 (707) 794-4479 mikef%[email protected] [email protected] ------------------------------ Date: Wed, 30 Jan 91 15:03:05 GMT From: "Pete Lucas, NCS-TLC, Holbrook House, Swindon" <[email protected] wallingford.ac.uk> Subject: Omni vs Beam? To: [email protected] To all of you who have entered the above discussion... Thanks! you've just earned me a beer!! Pete Lucas [email protected] [email protected] ------------------------------ Date: Wed, 30 Jan 91 11:45:18 EST From: [email protected] (Barry McLarnon DGBT/DIP) Subject: Omni vs beam antennas. To: [email protected] 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: [email protected] | | Packet BBS: VE3JF@VE3JF AMPRnet: [email protected] [44.135.96.6] | ------------------------------ Date: 29 Jan 91 17:54:41 GMT From: [email protected] (Glenn Elmore) Subject: Omni vs beam antennas. To: [email protected] > In rec.ham-radio.packet, [email protected] (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: [email protected] ------------------------------ Date: 31 Jan 91 01:46:44 GMT From: [email protected] (Brandon S. Allbery KB8JRR) Subject: Omni vs beam antennas. To: [email protected] As quoted from <[email protected]> by [email protected] (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: [email protected] 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! [email protected] (Carl Peterson) Subject: PACKET->Internet Gateway To: [email protected] 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 (206) 944-2745 | | Hewlett-Packard | | Vancouver Division (R&D Lab) | | P.O. Box 8906 | | Vancouver, WA 98668-8906 | | HPDesk: Carl Peterson/HPD300/04 | | Unix to Unix: [email protected] | | {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: [email protected] (frode weierud) Subject: Piccolo info. To: [email protected] 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 : 41 22 7674794 * * CERN, SL Fax : 41 22 7823676 * * CH-1211 Geneva 23 E-mail : [email protected] * * Switzerland or [email protected] * ************************************************************************** ------------------------------ Date: 31 Jan 91 03:06:51 GMT From: [email protected] (Phil R. Karn) Subject: Problem with NET and another TSR To: [email protected] In article <[email protected]>, [email protected] (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.