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: <9101311230.AA02220@ucsd.edu> Date: Thu, 31 Jan 91 04:30:06 PST From: Packet-Radio Mailing List and Newsgroup Reply-To: Packet-Radio@ucsd.edu Subject: Packet-Radio Digest V91 #30 To: packet-radio@ucsd.edu Packet-Radio Digest Thu, 31 Jan 91 Volume 91 : Issue 30 Today's Topics: 2 DRSI Boards and NET/NOS? 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: Send subscription requests to: Problems you can't solve otherwise to brian@ucsd.edu. 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!stu@ucsd.edu (Stuart Phillips) Subject: 2 DRSI Boards and NET/NOS? To: packet-radio@ucsd.edu In article <958400001@techsup>, kenb@techsup.UUCP 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!stu@ucbvax.Berkeley.EDU (Stuart Phillips) Subject: To: packet-radio@ucsd.edu In article <860@idacrd.UUCP> mac@idacrd.UUCP (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!kevinr@ucsd.edu (Kevin J. Rowett) Subject: Help! What is it? To: packet-radio@ucsd.edu In article , andreap@ms.uky.edu (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: packet-radio@ucsd.edu andreap@ms.uky.edu (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!mikef@hplabs.hpl.hp.com (Mike Ferrara) Subject: Need 56 Kbps info from .ba folks To: packet-radio@ucsd.edu 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%hpsadle@hp-sde.sde.hp.com mikef@hpsadle.hp.com ------------------------------ Date: Wed, 30 Jan 91 15:03:05 GMT From: "Pete Lucas, NCS-TLC, Holbrook House, Swindon" Subject: Omni vs Beam? To: PACKET-RADIO@ucsd.edu To all of you who have entered the above discussion... Thanks! you've just earned me a beer!! Pete Lucas PJML@UK.AC.NWL.IA G6WBJ@GB7SDN.GBR.EU ------------------------------ Date: Wed, 30 Jan 91 11:45:18 EST From: barry@dgbt.doc.ca (Barry McLarnon DGBT/DIP) Subject: Omni vs beam antennas. To: packet-radio@ucsd.edu 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: barry@dgbt.doc.ca | | Packet BBS: VE3JF@VE3JF AMPRnet: barry@bbs.ve3jf [44.135.96.6] | ------------------------------ Date: 29 Jan 91 17:54:41 GMT From: hpl-opus!hpnmdla!glenne@hplabs.hpl.hp.com (Glenn Elmore) Subject: Omni vs beam antennas. To: packet-radio@ucsd.edu > In rec.ham-radio.packet, koning@koning.enet.dec.com (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: packet-radio@ucsd.edu ------------------------------ Date: 31 Jan 91 01:46:44 GMT From: usenet.ins.cwru.edu!ncoast!allbery@g.ms.uky.edu (Brandon S. Allbery KB8JRR) Subject: Omni vs beam antennas. To: packet-radio@ucsd.edu As quoted from <1991Jan28.223338.2863477@locus.com> by dana@locus.com (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: allbery@NCoast.ORG 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!carlp@apple.com (Carl Peterson) Subject: PACKET->Internet Gateway To: packet-radio@ucsd.edu 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: carlp@hp-vcd.hp.com | | {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!frode@uunet.uu.net (frode weierud) Subject: Piccolo info. To: packet-radio@ucsd.edu 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 : frode@cernvax.cern.ch * * Switzerland or weierud@cernvm.cern.ch * ************************************************************************** ------------------------------ Date: 31 Jan 91 03:06:51 GMT From: epic!karn@bellcore.com (Phil R. Karn) Subject: Problem with NET and another TSR To: packet-radio@ucsd.edu In article <19585@shlump.nac.dec.com>, gettys@regent.enet.dec.com (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!gbastin@ucsd.edu (Gary Bastin 60293) Subject: Procomm Bug in Packet Use To: packet-radio@ucsd.edu 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: gbastin@x102c.ess.harris.com Mail Stop 102-4826 | phone: (407) 729-3045 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!steve@ucsd.edu (Steve Schallehn) Subject: Shareware on Packet To: packet-radio@ucsd.edu 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!steve@uunet.uu.net (Steve Schallehn) Subject: TCP/IP over long distances To: packet-radio@ucsd.edu 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!warlock@ucsd.edu (John Kennedy) Subject: Trolling for suggestions To: packet-radio@ucsd.edu 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: warlock@ecst.csuchico.edu | 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 ] [ torbortc@clutx.clarkson.edu Colton NY ] [ 315-262-1123 ] [ Remember, if you win the rat race, you're still a rat ] ------------------------------ End of Packet-Radio Digest ******************************