World of Ham Radio 1994 January

home *** CD-ROM | disk | FTP | other *** search

/ World of Ham Radio 1994 January / AMSOFT_1994.iso / packet / docs / pd198904.doc < prev next >

Wrap

Text File | 1993-12-31 | 305.2 KB | 6,992 lines

PACKET-RADIO Digest Sat, 1 Apr 89 Volume 89 : Issue 85 Today's Topics: USA Packet Stats WWPACKET Stats For all Countries-------------------------------------------------------- -------------- Date: Fri, 31 Mar 89 11:04:14 EST From: D H Bennett AMCRM-FTM <dbennett@alexandria-emh1.army.mil> Subject: USA Packet Stats United States Recap by State As of 03-31-1989 by K4NGC The following is a computed recap of the WWPACKET.DBF file I maintain for the United States. It reflects the number and type of activities by state. If you have any changes to this file please address them to K4NGC @ K4NGC. State PBBS DIGI TOTAL PERCENT---------------- ---- ---- ----- ------Alabama 26 35 61 2.15% Alaska 8 19 27 0.95% Arizona 37 23 60 2.11% Arkansas 15 19 34 1.20% California 154 87 241 8.48% Colorado 47 69 116 4.08% Connecticut 20 18 38 1.34% Delaware 3 3 6 0.21% Dist of Columbia 0 1 1 0.04% Florida 83 94 177 6.23% Georgia 31 29 60 2.11% Guam 0 0 0 0.00% Hawaii 10 10 20 0.70% Idaho 2 7 9 0.32% Illinois 32 63 95 3.34% Indiana 43 60 103 3.63% Iowa 20 20 40 1.41% Kansas 20 10 30 1.06% Kentucky 17 41 58 2.04% Louisiana 17 4 21 0.74% Maine 9 11 20 0.70% Maryland 48 59 107 3.77% Massachusetts 37 29 66 2.32% Michigan 41 29 70 2.46% Minnesota 14 25 39 1.37% Mississippi 12 8 20 0.70% Missouri 23 44 67 2.36% Montana 14 21 35 1.23% Nebraska 12 19 31 1.09% Nevada 2 14 16 0.56% New Hampshire 16 15 31 1.09% New Jersey 65 45 110 3.87% New Mexico 16 17 33 1.16% New York 88 57 145 5.10% North Carolina 22 23 45 1.58% North Dakota 7 5 12 0.42% Ohio 63 60 123 4.33% Oklahoma 16 25 41 1.44% Oregon 9 9 18 0.63% Pennsylvania 66 49 115 4.05% Puerto Rico 0 0 0 0.00% Rhode Island 5 4 9 0.32% South Carolina 20 11 31 1.09% South Dakota 6 7 13 0.46% Tennessee 24 18 42 1.48% Texas 52 29 81 2.85% Utah 9 30 39 1.37% Vermont 8 7 15 0.53% Virginia 41 70 111 3.91% Virgin Islands 0 0 0 0.00% Washington 32 17 49 1.72% West Virginia 8 14 22 0.77% Wisconsin 31 24 55 1.94% Wyoming 11 16 27 0.95% ---- ---- ---- -------Total 1417 1424 2841 100.00% The WWPACKET.DBF files are available on my LandLine Bulletin Board to all who want it. My Landline BBS telephone number is 703-680-5970. These files are in text, ARC and dBase formats. Don Bennett (K4NGC) 15016 Carlsbad Road Woodbridge, Va 22193 (Home) 703-670-4773 (Work) 703-274-9355/56 (LLBBS) 703-680-5970 (ARPANET) dbennett@amc-hq.arpa (Packet) K4NGC @ K4NGC ------------------------------ Date: Fri, 31 Mar 89 11:03:44 EST From: D H Bennett AMCRM-FTM <dbennett@alexandria-emh1.army.mil> Subject: WWPACKET Stats For all Countries World Wide Recap by Countries As of 03-31-1989 by K4NGC The following is a computed recap of the World Wide WWPACKET.DBF file I maintain. It reflects the number and type of activities by country. If you have any changes to this file please address them to K4NGC @ K4NGC. State DIGI PBBS TOTAL PERCENT-------------------------- ---- ---- ----- ------Argentina 0 2 2 0.05% Australia 38 59 97 2.37% Austria 5 4 9 0.22% Belgium 0 8 8 0.20% Bermuda 0 0 0 0.00% Bolivia 0 0 0 0.00% Brazil 0 0 0 0.00% Brunei 0 0 0 0.00% Bulgeria 0 0 0 0.00% Canada 29 101 130 3.18% Chile 0 0 0 0.00% China 0 0 0 0.00% Colombia 15 13 28 0.69% Costa Rica 6 2 8 0.20% Cuba 0 0 0 0.00% Denmark 0 15 15 0.37% Dominican Republic 0 0 0 0.00% Ecuador 0 1 1 0.02% Egypt 0 0 0 0.00% El Salvador 0 0 0 0.00% Finland 18 19 37 0.91% France 9 40 49 1.20% French Polynesia 0 0 0 0.00% German Demo. Rep. 0 0 0 0.00% Germany, Federal Rep 63 22 85 2.08% Greece 2 3 5 0.12% Greenland 0 0 0 0.00% Guatemala 0 0 0 0.00% Haiti 0 0 0 0.00% Honduras 0 0 0 0.00% Hong Kong 0 9 9 0.22% Hungary 4 4 8 0.20% Iceland 0 2 2 0.05% India 0 2 2 0.05% Indonesia 0 19 19 0.46% Ireland 0 5 5 0.12% Israel 0 4 4 0.10% Italy 49 91 140 3.43% Japan 6 158 164 4.01% Korea, North 0 0 0 0.00% Korea, South 6 2 8 0.20% Lebenon 0 0 0 0.00% Liechtenstein 0 0 0 0.00% Luxembourg 0 1 1 0.02% Malaysia 0 2 2 0.05% Mexico 0 3 3 0.07% Monaco 0 0 0 0.00% Morocco 0 0 0 0.00% Netherlands 0 0 0 0.00% New Zealand 0 2 2 0.05% Nicaragua 0 0 0 0.00% Norway 52 25 77 1.88% Pakistan 0 0 0 0.00% Panama 0 0 0 0.00% Paraguay 0 0 0 0.00% Peru 0 1 1 0.02% Phillipines 0 18 18 0.44% Poland 0 0 0 0.00% Portugal 0 0 0 0.00% Romania 0 0 0 0.00% Saudi Arabia 0 0 0 0.00% Singapore 0 0 0 0.00% South Africa 13 12 25 0.61% Spain 0 16 16 0.39% Sweden 0 33 33 0.81% Switzerland 0 1 1 0.02% Syria 0 0 0 0.00% Taiwan 0 0 0 0.00% Thailand 0 0 0 0.00% Turkey 0 0 0 0.00% United Kingdom 1 164 165 4.04% United States 1424 1417 2841 69.51% Uruguay 0 0 0 0.00% USSR 0 1 1 0.02% Venezuela 7 2 9 0.22% Yugoslavia 18 5 23 0.56% ---- ---- ---- -------Total 2321 1766 4087 100.00% The WWPACKET.DBF files are available on my LandLine Bulletin Board to all who want it. My LandLine BBS telephone number is 703-680-5970. These files are in Text, ARC and Dbase formats. Don Bennett (K4NGC) 15016 Carlsbad Road Woodbridge, Va 22193 (Home) 703-670-4773 (Work) 703-274-9355/56 (LLBBS) 703-680-5970 (ARPANET) dbennett@amc-hq.arpa (Packet) K4NGC @ K4NGC ------------------------------ End of PACKET-RADIO Digest ****************************** 2-Apr-89 04:07:40-MDT,2379;000000000000 Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL> Date: Sun, 2 Apr 89 01:30:37 MST From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL Subject: PACKET-RADIO Digest V89 #86 To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL PACKET-RADIO Digest Sun, 2 Apr 89 Volume 89 : Issue 86 Today's Topics: Ham Radio On Space Shuttle!--------------------------------------------------------- ------------- Date: 1 Apr 89 03:07:02 GMT From: att!homxb!hotps!ka2qhd!kd2bd@ucbvax.Berkeley.EDU (John Magliacane Wall Township NJ) Subject: Ham Radio On Space Shuttle! ARRL BULLETIN 14 ARLB014 FROM ARRL HEADQUARTERS NEWINGTON CT MARCH 27 1989 TO ALL RADIO AMATEURS AN AMATEUR RADIO STATION IS SCHEDULED TO FLY ABOARD THE SPACE SHUTTLE IN MARCH 1990. APPROVAL FOR THE INCLUSION OF THE SPACE SHUTTLE AMATEUR RADIO EXPERIMENT CALLED SAREX ON THE SECONDARY PAYLOAD LIST OF FLIGHT STS 35 HAS BEEN RECEIVED FROM NATIONAL AERONAUTICS AND SPACE ADMINISTRATION HEADQUARTERS. RON PARISE, WA4SIR, A PAYLOAD SPECIALIST FOR THE ASTRO 1 PAYLOAD TO BE CARRIED ON THAT FLIGHT WILL OPERATE THE STATION IN THE ORBITING SHUTTLE. REPRESENTATIVES OF ARRL AND SAREX, COSPONSORS, THE RADIO AMATEUR SATELLITE CORPORATION, AMSAT, STATED THAT THEY LEARNED OF THE APPROVAL AT A MEETING WITH NASA OFFICIALS HELD ON MARCH 14 AT THE LYNDON B JOHNSON SPACE CENTER IN HOUSTON. WA4SIR WILL COMMUNICATE WITH AMATEUR OPERATORS WORLDWIDE USING VOICE AND VIDEO COMMUNICATIONS AS WELL AS PACKET RADIO. THE ORBIT OF THE SHUTTLE WILL ALLOW AMATEURS LOCATED BETWEEN APPROXIMATELY 46 DEGREES NORTH AND 46 DEGREES SOUTH LATITUDES TO COMMUNICATE DIRECTLY WITH THE SHUTTLE. THE SAREX TRANSMISSIONS FROM THE SPACE SHUTTLE WILL BE SUCH THAT A STANDARD SCANNER RADIO CAN RECEIVE THEM. THE APPROVAL FOR SAREX OPERATION IS CONTINGENT ON FINAL APPROVAL BY JOHNSON SPACE CENTER OF THE SAREX HARDWARE AND OPERATIONS PLAN AND ON PRIORITIZATION OF SECONDARY PAYLOADS FOR THE STS 35 FLIGHT. -- UUCP : ucbvax!rutgers!petsd!tsdiag!ka2qhd!kd2bd PACKET : KD2BD @ NN2Z (John) ..."There is no expedient to which a man will not resort to avoid the real labor of thinking." ....Sir Joshua Reynolds. ------------------------------ End of PACKET-RADIO Digest ****************************** 3-Apr-89 01:26:19-MDT,5949;000000000000 Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL> Date: Mon, 3 Apr 89 00:31:01 MDT From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL Subject: PACKET-RADIO Digest V89 #87 To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL PACKET-RADIO Digest Mon, 3 Apr 89 Volume 89 : Issue 87 Today's Topics: 4SALE items on BBS is legal. UFQBBS V0.91 available-------------------------------------------------------- -------------- Date: 1 Apr 89 21:40:31 GMT From: portal!cup.portal.com!Ed_Eric_Mitchell@uunet.uu.net Subject: 4SALE items on BBS is legal. 4 SALE IS LEGAL. The following quote comes from the The FCC Rule Book, page 6-9, published by the American Radio Relay League, and is followed by an additional written policy statement from the FCC: Q. In the United States there are many nets that cater to hams selling and buying their ham radio equipment. Are these so-called 'swap and shop' nets legal? A. Yes, within certain constraints. Amateurs may use their stations from time to time to discuss the availability of a piece of Amateur Radio equipment, but such activity would be limited to that of an occassional nature. It's best not to discuss price on the air. Instead, swap phone numbers with the interested party and finish the dickering off the air. Activities could not include any items of a personal nature, such as a camera or ordinary broadcast radios. Hams should not engage in regular 'flea market' or business activities on swap nets so as to derive a profit by buying and selling ham gear on a regularly scheduled basis (97.112). END OF QUOTE FROM ARRL PUBLICATION Direct quote from FCC PR Docket 88-139, page 5 (i.e. this is a policy statement direct from the Federal Communications Commission): 36. Current policy permits amateur stations to transmit information about the availability of amateur radio equipment, notwithstanding Section 97.110, 47 C.F.R. Section 97.110, prohibiting business communications. In this context, amateur radio equipment is equipment normally used in an amateur station by an amateur operator. An asking price may be mentioned, but no subsequent negotiations or bartering may take place. If interest is expressed, the amateur operators should exchange mailing addresses or telephone numbers and finish negotiations using means of communication other than amateur service frequencies. Delaers may not take advantage of this exception. Amateur operators who derive a profit by buying and selling amateur radio equipment on a regular basis are considered dealers and violate the business prohibition if they use amateur service frequencies for this purpose. Proposed Section 97.219(c) codifies these policies. END OF FCC QUOTE Clearly, under written policy statements from both the ARRL, and the FCC, in 1988, the posting of 4 sale items concerning Amateur Radio equipment is completely and unequivocably legal, including, as stated above, the posting of an asking price. Note also that the FCC interpretation is slightly more liberal than the ARRL interpretation. While Section 97.219(c) is a part of the proposed rules rewrite, the FCC has made it explicitly clear in this section of the NPRM that the FCC's own interpretation of the existing Part 97 is that the posting of 4 SALE items, including an asking price is legal. I urge all SYSOPS to adhere to the this FOR SALE policy. There is no need to censor messages that fall within the above described categories. signed, Ed Mitchell WA6AOD (SYSOP) @ N6IIU Palo Alto, California. .. ------------------------------ Date: 1 Apr 89 22:17:56 GMT From: mcvax!kth!osiris!sics.se!klemets@uunet.uu.net (Anders Klemets) Subject: UFQBBS V0.91 available Version V0.91 of the multiuser mailbox UFQBBS is available with anonymous ftp on the Internet from tomcat.gsfc.nasa.gov. The files are in the bbs/ufqbbs directory. Unfortunately the files have been archived with a program called ZIP. I cannot run ZIP on this UNIX machine so I have not been able to check the files. I have uploaded the ZIP program as well, so any user with a PC should not have troubles with extracting the files. The files on tomcat happened to be uploaded on April 1st. This is purely unintentional... The BBS provides a NET/ROM lookalike interface called "The Node". You can connect to it and it will work just like a normal NET/ROM node but there is one extra command, "BBS", that connects you to the BBS. The software works with any TNC that supports KISS mode. Here follows a release note received on packet. Please send any questions to the author, G4GOU, and not to me. Good luck, Anders SM0RGV - - - - To :UFQBBS@EU From:G4GOU @GB7LNX.GBR.EU Msg MID:CC3A6F0D Hi, The latest version of the UFQBBS (0.91) is now ready and can be downloaded from my phone bbs on 0522-511277 (Net 2:258/46) This code is much improved, and fixes most of the bugs in previous versions. It is fully multi-user, and will support several tnc's with multi-connect on each running in a single 170k Desqview window. (The distributed version is limited to two tnc's with 9 simultaneous connects on each) It is fully compatible with version 3.01 of THE NODE. It also allows for forwarding to occur simultaneously to several stations. In addition to the usual BBS commands (very similar to MBL & RLI) it also supports gateway connects and a conference facility whereby several users can chat to one another - something which is difficult to do with a normal packet qso. File Upload/download is not yet implimented, but should be ready soon. For more information contact me at this bbs or QTHR. 73 Mike G4GOU sysop GB7LNX & GB7LX ------------------------------ End of PACKET-RADIO Digest ****************************** 3-Apr-89 11:13:36-MDT,18440;000000000000 Mail-From: KPETERSEN created at 3-Apr-89 10:25:44 Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL> Date: Mon, 3 Apr 89 10:25:43 MDT From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL Subject: PACKET-RADIO Digest V89 #88 To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL PACKET-RADIO Digest Mon, 3 Apr 89 Volume 89 : Issue 88 Today's Topics: Gateway 17-Mar-89-------------------------------------------------------- -------------- Date: 3 Apr 89 01:41:03 GMT From: osu-cis!n8emr!gws@tut.cis.ohio-state.edu (Gary Sanders) Subject: Gateway 17-Mar-89 ============================================================== | Relayed from packet radio via | | N8EMR's Ham BBS, 614-457-4227 (1200/2400/19.2 telebit,8N1) | ============================================================== Gateway: The ARRL Packet Radio Newsletter Stan Horzepa, WA1LOU, Editor - Sal Prado, Gateway Circulation Volume 5, Number 13 March 17, 1989 ROSE SWITCH ON The long awaited ROSE (RATS Open Systems Environment) X.25 Packet Switch software has been released by The Radio Amateur Telecommunications Society (RATS). This release of the ROSE Switch software runs in a TNC 2 (or clone) or in a PacComm DR-200 two-port controller. TNC 2s may also be operated in a "back-to-back" configuration. The software was written by Tom Moulton, W2VY, and is free, for Amateur Radio use only. It may be obtained by downloading it from CompuServe's HamNet (filename: ROSESW.ARC). from J. Gordon Beattie, Jr, N2DSY via CompuServe's HamNet TAPR FOCUSES ON ON-GOING PROJECTS AT ANNUAL MEETING The board and members of Tucson Amateur Packet Radio (TAPR) met on February 24-26 in Tuscon, Arizona, to discuss activities of the past and forthcoming year. Heavy TAPR support, both financial and technical, for AMSAT's MicroSat project has been the major activity of the past year, followed closely by the digital signal processing (DSP) project (see Gateway, Volume 4, Numbers 4, 8 and 12 and Volume 5, Number 10). While the MicroSat project should be winding down after launch in a few months, the DSP project should "ramp up" toward production of DSP units. Other TAPR projects discussed at the meeting included modem upgrade retrofits for the TNC 2 and an upgrade to the TNC 1 to allow it to run TNC 2 firmware (see Gateway, Volume 5, Number 9). Numerous talks were given, including updates on TexNet, TCP/IP, MicroSat, DSP and the HF message-forwarding network. Technical talks introduced a prototype IBM PC plug-in compatible intelligent packet-radio controller by Mike Chepponis, K3MC; a DSP-based analysis by Dan Morrison, KV7B, of filter-type vs phase-locked loop FSK demodulators; and prototype 1.2-GHz transverters designed by Glenn Elmore, N6GN, for use with WA4DSY 56-kbit/s modems. The theme of the weekend, or, at least, the most discussed subject, was TAPR's support for some type of new Amateur Radio license class that does not require a knowledge of Morse code. The TAPR board of directors, which met on the 24th and 25th, appointed Harold Price, NK6K, to oversee the generation of a specific proposal by TAPR. That proposal is to be forwarded to the ARRL No-Code Study Committee. Newly elected TAPR board of directors were announced: Franklin Antonio, N6NKF; Bdale Garbee, N3EUA; Steve Goode, K9NG; Eric Gustafson, N7CL; Lyle Johnson, WA7GXD. by Jon Bloom, KE3Z CALL FOR PAPERS: ARRL COMPUTER NETWORKING CONFERENCE The eighth ARRL Amateur Radio Computer Networking Conference will be held on Saturday, October 7, 1989, at the Air Force Academy in Colorado Springs, Colorado. Technical papers are invited on all aspects of Amateur Radio digital communications via ionospheric, tropospheric, meteor-scatter and satellite modes. Topics may include network development, architecture, protocols, standards, hardware, software, modulation and encoding schemes, applications, frequency planning and practical experience, such as traffic handling. Of particular interest are digital signal processing, digital speech and image transmission, and new space programs employing digital communications. Prospective contributors should request an author's kit and identify the topic of their paper immediately. The deadline for receipt of camera-ready manuscripts is August 28, 1989. Author kit requests and camera-ready manuscripts should be mailed to Lori Weinberg at ARRL headquarters. Printed proceedings will be available at the conference and by mail from ARRL headquarters. PACKET RADIO IN WEST GERMANY In the following exclusive Gateway report, Ekki Plicht, DF4OR, the official in charge of visual communications for Deutscher Amateur Radio Club (DARC), describes the state of the art of amateur packet radio in the Federal Republic of Germany, where it is one of the fastest growing, if not the fastest growing, Amateur radio mode. In the Beginning... Packet radio in DL-land started on one 2-meter frequency, 144.675 MHz. While some enthusiasts enjoyed a quiet frequency and made connections through the whole country, even DX contacts into France, Switzerland and Austria, the growing interest in this new form of communications made efficient "normal" digipeating impossible, due to the increase in the number of collisions. So, in those early years, DARC started to develop a plan which would offer reliability and promise for future years. This plan stated that o On 2 meters there are too few frequencies for packet radio (exactly three for digital communications); o Therefore, user input frequencies should be placed on 70 cm and higher; o Internode communications should take place on 23 cm and higher and the link between two nodes should be exclusive and realized with directional antennas and the lowest power possible. This scheme developed well, although some people still favor 2-meter operation due to availability of less expensive equipment. To understand the situation in West Germany, let me explain some of the more important differences between West Germany and US. The 2- meter band is much smaller than in the US (only 2 MHz, from 144.000 to 146.000 MHz). Digital communications occur from 144.625 to 144.675 and 145.300 MHz. This is not enough for a network, since there are still other digital activities besides packet radio, such as RTTY, FAX, etc. On the average, West Germany is more densely inhabited than the US, thus, a digipeater has to serve a greater number of users. To avoid collisions between digipeaters serving different areas on the same frequency, they should not be located at good DX sites. Therefore, it is necessary to install a large number of medium-range digipeaters in order to build a nationwide network. This is possible only on 70 cm, where enough room is available (10 MHz, 430.000 to 440.000 MHz). (There is no 220-MHz band in Region 1, and 6-meter operation is not allowed in West Germany.) The Situation Today In early 1989, 74 digipeaters and 24 PBBSs are active in West Germany. Three digipeaters are still on 2 meters, the so called "NORD><LINK experiment." These are some of the earliest digipeaters in West Germany which were set up to learn about utilization of the 2-meter band for packet radio. Except for one station on 23 cm (a user input), all of the other stations are on 70 cm. The subbands used on 70 cm are: o 433.625-433.775 MHz: simplex, digipeater, station-to-station o 438.025-438.175 MHz: simplex, PBBS, digipeater, station-to-station o 438.200-438.525 MHz: duplex output, 7.6-MHz shift, digipeater (not yet in use) Duplex digipeaters are preferred for their improved throughput and collision avoidance, even though they consume twice the space. Besides, they are a perfect way to defend our endangered 70-cm band. (For a fair presentation of the situation here, it must be said that ATV operators are not happy with the frequency allocations in the upper part of the 70-cm band.) All nodes use 1200-bit/s modems on the user frequencies with one experimental station near Bonn using 4800-bit/s. Most digipeaters are connected to some other node via 23-cm links. There are still some links on 70 cm, but they will be moved to 23 cm or higher when possible. The 23-cm links are on exclusive duplex frequencies, so collisions should be minimal. The necessity of using 23 cm for internode communication led to some interesting developments in UHF equipment. To name one, there is a reasonably-priced, one-watt transceiver kit developed by DF9IC and DL5UY from Karlsruhe, that is capable of 1200-bit/s, half-duplex operation. It is ready to connect to a 1200-bit/s AFSK modem and covers the 23-cm band from 1240 to 1300 MHz. Many experiments are taking place on higher frequencies. For example, in the Munich area (Bavaria), some experiments are in progress using the 6-cm and 10-GHz bands. PACKET RADIO IN WEST GERMANY - (Part 2) Modem Hardware Besides the standard 1200 bit/s modems using TCM3105, AMD7911 and XR2211 chips, there are other modem developments. DJ4ZC of AMSAT-DL has developed the "RSM-Modem" which uses rectangular spectrum modulation. It is capable of 9600 bit/s full-duplex operation and is under test on two digipeaters. NORD><LINK's DK4EG has developed a 4800-bit/s modem. Elsewhere, tests are being conducted with G3RUH's 9600-bit/s modems. Digital Hardware...on Hilltops About 50% of the digipeaters in West Germany use standard TNCs including many compatible clones of the well-known TNC 2. Most, if not all, use NET/ROM or TheNet. Another large number of digipeaters use the so-called "RMNC" (RheinMain-Network Controller) which was developed by DH1FAB and others in Frankfurt. It uses the 6809 microprocessor and is contained on one printed circuit board that includes the CPU, 32-kbyte of RAM, 32-kbyte of ROM, SCC, VIA and a TCM3105 modem. It is available at a reasonable price. A few digipeaters use homebuilt hardware or software. For example, the HP9000-series computers with homebuilt slot modems used in the Stuttgart area running UNIX, another 6809 system running FLEX, etc. A large number of hams use the Commodore C-64 for packet-radio operation running DIGICOM>64 Version 2 software and an inexpensive user-port modem. Another large chunk of the packet-radio population use TNCs, PK-232s, KAMs or similiar controllers. Digital Hardware To Come Rumors concerning recent new hardware developments include a larger CPU for the RMNC by DG8FAC and another board for the RMNC using the H16-series computers by DK7WJ. Software...on Hilltops Nearly all of the TNC-equipped digipeaters use NET/ROM or TheNet. Plans are to further improve TheNet as far as code-space considerations will allow. The latest development for TNCs is a converse-mode EPROM from DL8ZAW which is linked to a NET/ROM node via the EIA RS-232-C interface. Software that is available for the RMNC (RMNC V1.6) includes a simple tool that uses an unchanging routing table in EPROM with no hop-to-hop acknowledgement or connectability. Another software design is DK7WJ's FLEXNET. It has a lot of capabilities including hop-to-hop acknowledgment (without changing the SSIDs), an information system, MHeard list, converse mode and more. Currently, it is used on one digipeater equipped with professional hardware (6809 multiprocessor), but it will be ported to the low-cost RMNC, resulting in the Version 2 of the RMNC software (whenever I finish the low-level I/O). In Karlsruhe, DL5UY/N1EOV and DJ0VL developed their own software running on an 68000 OS-9 system, incorporating a PBBS, standard digipeating and TCP/IP facilities based on KA9Q's software. DK5SG developed another program under UNIX, running on a HP9000 series computer, which includes a PBBS, autorouter and, again, TCP/IP based on Phil's code. This is the so-called "WAMPES" (Wuertemberg Amateur Packet Experimental System). It is currently used by four or five stations in the Stuttgart area. WAMPES now has an extension which makes it compatible to NET/ROM-like internode communications (Layer 3/Layer 4 protocols). FLEXNET (and, by that, the RMNC) will follow by the summer of this year. Thus, we hope to get a consistent network all over the country. The DARC department for visual communications will try to bring the major software developers of central Europe together for a conference where standardization and extension of the Layer 3/Layer 4 protocol will be discussed. Software at Home Many hams use the famous DIGICOM>64 software for the Commodore C-64/C- 128 computers written by DL8MBT. Its capabilities and user interface is nearly unbeaten by any other software. It is also used in the US as well. People who use TNCs are running TAPR (V1.1.4) or WA8DED (V2.1) firmware. The latter software has been rebuilt by the NORD><LINK group and is available under the name "TheFirmware." It has some nice improvements (clock, MHeard, KISS-mode) and is mostly used as host- mode software. There are some host-mode programs for the IBM PC, for example, TURBO HOST by DL1BHO, PCT by DD6CV, and CTERM by DD5KZ. All of these use windowing, file I/O and enhance the TNC with many features. For the PK-232, there is PC-PAKRATT. Most of the mentioned software and firmware is public domain. There is a little TCP/IP operation in West Germany, mainly in regions where a TCP/IP PBBS or digipeater is reachable. (One digipeater in West Germany is running KA9Q TCP/IP code.) Nevertheless, several hams have improved the KA9Q program with windowing (DK3SI) and other features (DK8GD). PACKET RADIO IN WEST GERMANY - (Part 3) PBBS Software Until about a year and half ago, the WA7MBL PBBS software was used throughout Germany. But, then DF3AV, from the NORD><LINK group developed PBBS software called "DIEBOX" or "TheBox." Its greatest advantage is its multiuser capability that can handle up to eight users per TNC. This was badly needed for the crowded PBBSs serving hundreds of users in various regions of West Germany. Its store-and- forward scheme is compatible with the WA7MBL/W0RLI standard. The user interface uses a completely different approach than the WA7MBL PBBS. Another feature is its "lifetimer" which keeps the amount of information to a reasonable size. The average throughput of some mailboxes is approximately 75 Mbytes per month. PBBSs running under UNIX or OS-9 (DK5SG and DL5UY) use improved WA7MBL software. Packet Radio on HF On HF, one mailbox is in operation: DK0MWX on 14.099 MHz. Most of our international traffic is handled through this mailbox, but, because of some legal uncertainty with third-party traffic, no direct contact is made between West Germany and US. We hope that will change in the future. Many private stations are on 20 meters and should be operating below 14.099 MHz. The latest IARU Region 1 HF conference, held in late 1988, announced that a 100-kHz subband on 10 meters is allocated for narrow-band FM packet radio. This is from 29.200 to 29.300 kHz with 29.250 MHz as the center of activity. Other Activities A regular packet-radio conference is held in Frankfurt once a year. This meeting was attended by approximately 150 people last year, mainly PBBS SYSOPs and hardware/software developers. A beginners' conference was also held in Frankfurt in 1987 and should be repeated this year. A software conference with a small circle of "gurus" is badly needed to catch up with the fast development of new software everywhere. It should ensure compatibility with all of the new programs without stopping anyone from writing new software or reinventing the wheel for the n+1 time. The Future We are far from having nationwide coverage by a packet-radio network, but the path seems clear. The number of new licenses for digipeaters has decreased a little, but some regions have not yet come on-line. What we need now is to improve internode communications by means of hardware and software. The expected interest in packet radio indicates that the 1200-bit/s links are not fast enough. Roughly, about 10% (5000-plus hams) are QRV on packet radio and the number is still growing. Again, to give a complete picture of the situation in West Germany, it must be said that not everyone is content with the concept that DARC has for packet radio. Also, there are people who think that packet radio has nothing to do with good ol' ham radio at all and should be abandoned altogether. Admittedly, packet radio is not everything the beautiful hobby of ham radio can give us, but for many people it is one of the most fascinating parts of it. And, if we keep on talking with each other, there should be room for us all. "vy 73 and happy packeting" For contacts or more information write to: Ekki Plicht, DF4OR BuS-Referat Altheimweg 2 D-6100 Darmstadt 12 Federal Republic of Germany telephone: (country code 49) 6151-377369 packet-radio address: DF4OR @ DB0GV.DL.EU DF4OR.AMPR.ORG [44.130.024.013] GATEWAY CONTRIBUTIONS Submissions for publication in Gateway are welcome. You may submit material via the US mail to: Gateway Stan Horzepa, WA1LOU 75 Kreger Drive Wolcott, CT 06716-2702 or electronically, via CompuServe to user ID 70645,247. Via telephone, your editor can be reached on evenings and weekends at 203-879-1348 and he can switch a modem on line to receive text at 300, 1200 or 2400 bit/s. The deadline for each issue of Gateway is the Saturday preceding the issue date (which is typically a Friday). REPRODUCTION OF GATEWAY MATERIAL Material may be excerpted from Gateway without prior permission, provided that the original contributor is credited and Gateway is identified as the source. ------------------------------ End of PACKET-RADIO Digest ****************************** 5-Apr-89 02:45:16-MDT,5444;000000000000 Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL> Date: Wed, 5 Apr 89 01:31:16 MDT From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL Subject: PACKET-RADIO Digest V89 #89 To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL PACKET-RADIO Digest Wed, 5 Apr 89 Volume 89 : Issue 89 Today's Topics: HAPN-problems HELP! HELP!------------------------------------------------------------ ---------- Date: 4 Apr 89 10:18 +0100 From: Magne Maehre <m_maehre%avh.unit.uninett%NORUNIX.BITNET@CUNYVM.CUNY.EDU> Subject: HAPN-problems I tried this one some weeks ago, but haven't yet received any answers so I try again. LA4BM is the only one in this LAN running the HAPN-card. Therefore we don't know if there is a problem with his card or if it is a common problem. The problem is; Every time the card detects traffic on the channel it keys the transmitter for some milliseconds (or so). It behaves normal if the traffic is meant for him, but as soon as there is traffic meant for someone else it starts acting this way. This makes of course trouble for the other users since almost all response-packets (ACK, NAK etc) is doubled with this keying. Is there any reasonable solution to the problem?? I will be very pleased to hear from any HAPN-user (or anyone else with an opinion). Please mail responses to me directly as well as to the net. Vy 73 de Magne LA1BFA E-Mail : m_maehre%avh.unit.uninett%norunit.bitnet@cunyvm.cuny.edu (PUH) DEC-Net : 56720::M_MAEHRE Mailbox : LA1BFA @LA8GE ------------------------------ Date: Mon, 3 Apr 89 12:38:57 EST From: D H Bennett AMCRM-FTM <dbennett@alexandria-emh1.army.mil> Subject: HELP! HELP! SUBJECT: World Wide Packet Radio Listing Again, I have received a message telling me that my Stats for the USA and Foreign countries are incorrect. AGAIN I WILL TELL YOU THAT YOU ARE RIGHT. As long as YOU do not send me updates I can not correct the problem you tell me about. This is just like a doctor telling you that your are SICK but NOT telling you how to solve the problem. As long as you my fellow hams do not give me the information then IT WILL BE INCORRECT. I have received messages from Europe telling me that there are more digipeaters and PBBS in a certain country, but they will not tell me what to change or what to add or what to delete. I dont mind people telling me that the data is incorrect, but I do mind when they will not give me the answers to correct the problem. How does anyone expect me to keep this list current if they wont give me the information. I have had to beg, scream, plead, etc. to get this information. Well, if the HAM community does not want to help then I will be glad to discontinue the database of Digipeaters and PBBS. It would be a shame, because there is a lot of usefully information in it that the BBS Operators use, in addition a lot of BBS Users and NTS Operators are using it so that they can forward mail directly to certain BBSs. So what about it people, Lets see those changes, deleteions, additions, and confirmations come in. Make me work late at night to keep the list up to date. If you want to help please provide the following information for each and every Digipeater and PBBS in your area or areas that you know about. 1. Call Sign 2. SSID 3. City 4. State/Provence 5. Country 6. ZIP/Postal Code 7. MAP Grid 8. Frequency 9. Type Activity (Digi or PBBS) 9. Activity Code(s) (See below) Activity Code - A - DIGI - TNC-1 or Clone (Dumb Digipeater) B - DIGI - TNC-2 or Clone (Dumb Digipeater) C - DIGI - Layer 3/4 Node (Network Node) D - DIGI - VC Switch (COSI) E - DIGI - TEXNET F - DIGI - TCP Switch G - DIGI - TCP Gateway H - DIGI - KANODE (Without Gateway) I - DIGI - KANODE (With Gateway) J - DIGI - 9600 Baud TNC K - DIGI - 56 KB TNC L - DIGI - Packet Radio Repeater M - DIGI - Converse TNC # - DIGI - This is a Backbone Frequency and users are requested not to use it. 1 - PBBS - BBS, Local User access and Mail Forwarding 2 - PBBS - BBS, Forwarding ONLY (No Users) 3 - PBBS - BBS, Local User access and No Mail Forwding 4 - MBOX - Personnel Mailbox (NOT PBBS) that PBBS can forward to. Please let me know of any corrections, deletions, additions or verifications to this file. Send them to me - K4NGC @ K4NGC via one of the Packet Radio PBBS mailboxes. Any call signs listed on this list will be purged if the update date exceeds 2 years, therefor verification is necessary. 73's Don Bennett -- K4NGC 15016 Carlsbad Road Woodbridge, Va 22193 USA (Home) 703-670-4773 (Office) 703-274-9355/56/63/64 (K4NGC LLBBS) 703-680-5970 (ARPANET) dbennett@amc-hq (PACKET RADIO) K4NGC @ K4NGC ------------------------------ End of PACKET-RADIO Digest ****************************** 6-Apr-89 02:34:02-MDT,5096;000000000000 Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL> Date: Thu, 6 Apr 89 01:30:57 MDT From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL Subject: PACKET-RADIO Digest V89 #90 To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL PACKET-RADIO Digest Thu, 6 Apr 89 Volume 89 : Issue 90 Today's Topics: AJ3-to-anything adapter Distribution of KA9Q code (2 msgs)------------------------------------------------------------ ---------- Date: 5 Apr 89 15:31:36 GMT From: mailrus!sharkey!atanasoff!ceres!deimos.cis.ksu.edu!harris.cis.ksu .edu!mac@tut.cis.ohio-state.edu (Myron A. Calhoun) Subject: AJ3-to-anything adapter I'd like to find an AJ3-to-BNC or AJ3-to-SO239 or AJ3-to-anything !-) adapter so I could use my TH-21AT with an antenna other than its little stubby-duck. I asked a Kenwood representative at a local hamfest and was directed to a large parts distributor, but the latter said they discontinued carrying the adapter over a year ago. Does anyone have any suggestions?-- Myron A. Calhoun, PhD EE, W0PBV, (913) 532-6350 (work), 539-4448 (home). INTERNET: mac@ksuvax1.cis.ksu.edu BITNET: mac@ksuvax1.bitnet UUCP: ...{rutgers, texbell}!ksuvax1!harry!mac ------------------------------ Date: 5 Apr 89 06:26:03 GMT From: ka9q.bellcore.com!karn@bellcore.com (Phil Karn) Subject: Distribution of KA9Q code For some time, I've been getting mail of the form "I want a copy of your code but I can't FTP from here". Lately these requests have reached a fever pitch. It has gotten to the point where I simply have no choice but to put my foot down and say that I can't honor any more such requests. Figuring out how to get a large binary file to somebody through a jury-rigged chain of UUCP sites and/or FOOBARNET mail gateways is extremely time-consuming and tedious. I'm sure people would rather have me spend my time coding! Furthermore, shipping large files like the KA9Q TCP/IP sources through the mail gateways that do exist to other networks is, in my opinion, abusing the hospitality of the gateway operators. In most (if not all) cases, these paths use dialup phone links, with the gateway operators footing their own phone bills in order to provide a courtesy to others. If you cannot access the anonymous FTP directories on flash.bellcore.com or louie.udel.edu, I suggest the following alternative ways to obtain the code: 1. If you are at a university, commercial or governmental institution that has an internal computer network, jump up and down until you convince your management that you should join the Internet. With the development of the NSFNET backbone and the regional networks, Internet connectivity is now available to almost any organization doing research or development, not just those with DoD contracts. The Internet is so incredibly useful for so many things that it is becoming at least as essential as telephone service for an awful lot of people. 2. If you cannot get on the Internet, find a friend who *is* on the net and get them to fetch the code for you. I encourage people to set up informal "networks" to distribute copies of my code to their friends, as long as the use is non-commercial. You may ship disks around, use bulletin boards or do direct phone or packet radio transfers; your choice. I strongly encourage those with Internet access to make current copies of the code available to others, e.g., by public access UUCP a la N3EUA's or WB3FFV's UNIX systems. Given the time it takes to send the stuff even at 2400 baud, I'm sure these two systems could use some help in sharing the load. 3. If all else fails, wait until the new releases are announced as being available through the TAPR office on floppy. You will have to wait a while, as TAPR prefers to deal only with "official" releases, not the "snapshots" of development code I've been regularly putting out for testing. The only exception I will make to my rule of staying out of the code distribution business is for people who have already proven themselves as contributors to the coding effort. For these relatively few people I am willing to prepare and mail floppies when necessary, but because of the time and expense I am simply unable to do this for everyone who asks. Thanks for your understanding. Phil Karn, KA9Q ------------------------------ Date: 5 Apr 89 17:27:37 GMT From: sun.soe.clarkson.edu!nelson@tcgould.tn.cornell.edu (Russ Nelson) Subject: Distribution of KA9Q code I'll put bits on Clarkson's archive server as I get them. Send 'help' to archive-server@sun.soe.clarkson.edu. If you get no reply, include a 'path' command that gives a path to you from an Internet site.-- --russ (nelson@clutx [.bitnet | .clarkson.edu]) If you can, help others. If you can't, | Leftoid and proud of it at least don't hurt others--the Dalai Lama | ------------------------------ End of PACKET-RADIO Digest ****************************** 8-Apr-89 02:37:48-MDT,10190;000000000000 Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL> Date: Sat, 8 Apr 89 01:30:29 MDT From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL Subject: PACKET-RADIO Digest V89 #91 To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL PACKET-RADIO Digest Sat, 8 Apr 89 Volume 89 : Issue 91 Today's Topics: 4 Sale Items ok/clarification FCC's recognition of repeater coordination is a disaster Packet BBS for AMIGA available.------------------------------------------------------- --------------- Date: 7 Apr 89 03:48:16 GMT From: portal!cup.portal.com!Ed_Eric_Mitchell@uunet.uu.net Subject: 4 Sale Items ok/clarification There seems to have been widespread misunderstandings about my original 4 sale item legal on BBS systems. It was sent to rec.ham-radio.packet under the presumption that active packet radio operators read that news group. The posting referred specifically to messages posted on packet BBS via packet connected ham radio operators. I had no intentions of suggesting that 4 sale items *gatewayed from internet to ham bbs* were meant to acceptable. I am the sysop at the 610 user N6IIU BBS located at the American Red Cross Chapter, Palo Alto and we have received quite a bit of mail from some areas of the country where sysops delete nearly every for sale message they see. My message referred to those bbs systems, and not specifically with this news net. I am sorry that some of you misinterpreted my posting regarding for sale items. It was also posted to SYSOP @ ALLUS (or @USA) and I have received 12 very positive replies and 2 sysops who still thought 4 sale was illegal. KI6PR @ K6RAU telephoned the FCC, Washington, DC on March 30, 1989 and also verified that the 4 sale policy for BBS systems that I printed in my notes is exactly the policy that they are using. We have it in writing from the FCC in PR Docket 88-139, and verbally over the telephone on 3/30/89. Please note that the FCC has established their policy and, in effect, said that there are exceptions to their rules on this issue. Also, its true that two hams were cited in 1987 (and one again in 1988). These citations were rescinded by the FCC Washington office. This latter information comes from the Northern California Packet Assoc. meeting on 4/2/89. Ed Mitchell WA6AOD @ N6IIU.#NOCAL.CA.USA.NA ------------------------------ Date: 7 Apr 89 23:33:00 GMT From: delni.dec.com!goldstein@decwrl.dec.com (Fred R. Goldstein dtn226-7388) Subject: FCC's recognition of repeater coordination is a disaster (originally To: DECWRL::"splut!jay@uunet.uu.net" in response to a dialogue on a mailing list) Yes, Jay, it's not an easy question! How can coordinators make room for new services (i.e., packet repeaters) when FM users have already claimed all of the frequencies? The problem is basically that YOU are being asked to decide it, rather than allowing the "forces of nature" to take their course. Let's go back a couple of decades to the last two major shifts in band occupancy. Between 1955 and 1965, the HF fone bands went from mostly-AM to mostly-SSB. The first SSB pioneers got sneers of derision about their "Donald Duck" transmissions, but they crept between the carriers, found their niches, and spread out. Eventually the AMers shrank back to niches and today they have a single spot on each band. No coordinator made up a bandplan; the bands just evolved. Between 1968 and 1971, 2M went from mostly-AM to mostly-FM. In 1967, I belonged to an AM net that met on 146.898, weekly, and to a "midnight net" that met on 145.71. Local activity was centered on 145.32. This was in Northern NJ, btw. The .898 net moved down to .71 by 1968 or so, as 146.94 got busier as the National FM frequency. Then the FMers filled up the 60 kHz channels from 146.94 to 146.64, then the "splits". The uniform 600 kHz repeater business took place around '71, creating the FM bandplan for 146-147. FM stayed above 146, though; OSCAR was to claim 145.8-146.0. And the FCC noticed and allowed Techs to move into the previously-empty space above 147. Eventually the AM retreated to niches around 144.3. That evolution was pretty smooth, except for the chaotic era of the Walkerrules. I was the editor of 73 Inc.'s "World Atlas of Repeaters 1976". That was the first wide-ranging repeater atlas to feature maps. I did a LOT of work putting it out, checking hundreds of club newsletters, etc. I couldn't just ask the coordinators who was where; not every area had one, and not every repeater was coordinated. But there were only a few places where hams didn't work things out amicably. In the NY area, co-channel repeater spacing was sometimes as low as 30 miles. Yeah, they argued, but it wasn't all that different from 20 meters -- you try to avoid interference and understand that the bands are crowded. Or you have a repeater war for fun. (Why not? Many of the repeaters were totally redundant, just there for ego-tripping, so repeater operation was itself the thrill, not repeate use. And repeater wars are the Radiosport of repeater ownership.) Eventually FM repeaters were allowed to claim the 144.5-145.5 band, and when packet came out, all that was left was the simplex space around 145.0. All of the repeater pairs had been given out (in many areas), by the time the FCC's coordination procedure was recognized. Now the repeater wars of 1972 weren't all good (or all bad, really; I enjoyed watching some) but the FCC's recognition of coordination really stopped evolution dead in its tracks. Coordinators were no longer "voluntary", making their job tougher. After all, before, if you didn't like their decision, you could ignore them, and if the "free market" was with you, the coordination would become nugatory or moot. Now, though, they're effectively stuck playing Gosplan, allocating resources among competitive interests, with little or no market mechanism. So what's a coordinator to do? Well, there are two approaches. One (which is rather idealistic) is for coordinators to declare their decisions "non-binding", legally, so they revert to their 1972-era standing. They could also declare some coordinations to be more binding than others, "protecting" only a critical backbone of repeaters, and "suggesting" frequencies to others on a purely voluntary basis. Another is for the coordinators, in their unpleasant GosRepeater role, to recognize that FM voice users are no longer so preponderant on 2M (and elsewhere; I just know 2M better) that they deserve as large a percentage of the band as they did in 1979. New, non-voice allocations could then be made where voice allocations already exist. Which exisiting allocations get booted? Well, in a "free market", the least-used and most private machines would be the easiest ones to, uh, "share frequencies with" and "encourage them to move". The 3-user PL-access machine on Joe Bxzftlp's roof 30 miles outside of town might be a good frequency to "share". So a coordinator would prioritize existing allocations and ask the low-priority ones to move. Maybe let someone offer to buy a new set of crystals. Prioritization of amateur operation is no fun, but one could posit someting like this: 1. Open repeaters with high usage. 2. Closed repeaters with high usage. 3. Open repeaters with little usage and unique features. 4. Closed repeaters with little usage and unique features. 5. Open repeaters with little usage and no unique features. 6. Closed repeaters with little usage and no unique features. 7. Historical allocations no longer actively used. Others might give more weight to openness; I tend to accept closed-ness if there's justification, such as experimentation. Individual coordinators, of course, would get to make up their own priorities and apply them to the user base as they see fit. The low-priority allocations then have to double up on frequencies, or use closer co-channel or adjacent-channel distances to find new homes. That can free up a few repeater pairs for packeteers and other future users. It's not an easy situation, but ham radio is stagnant enough without applying the Force of Law to maintain frequency allocations in a time warp simply because to change them would force some users to retune their radios or, heaven forbid, learn to share frequencies. I know from sad experience that 2M packet is a total mess, and I know from technical analysis that full duplex repeaters give far more than twice the throughput of single-frequency digipeaters. But to gain such efficiency, we need repeater pairs, and they're all full up. That's why I think the FCC's coordination rules are a disaster. They can be changed, or the coordinators can recognize the problem and, at the risk of making a few enemies, do the tough job themselves. fred k1io ------------------------------ Date: 7 Apr 89 17:33:02 GMT From: att!alberta!dvinci!hardie@ucbvax.Berkeley.EDU (Peter Hardie ) Subject: Packet BBS for AMIGA available. I have finally managed to port the CBBS version of the W0RLI from its original IBM version to the AMIGA. It will run on a 512K amiga with only one floppy if absolutely necessary. In order to use it you MUST be able to use the CLI and an editor in order to configure it for your own environment. Send me a disk and sufficient postage to pay for return mail. U.S. ops please note that I will take equivalent LOOSE U.S. stamps but don't stick them on ur SASE. Canada Post expects me to use Canadian stamps! If you want me to supply the disk and stamps send a money order for $4. The disk contains an executable version of the bbs plus the entire C source code (for Manx 3.6A). Pete Hardie VE5VA 338 113th St., SASKATOON, SASK S7N 2L2 CANADA ------------------------------ End of PACKET-RADIO Digest ****************************** 10-Apr-89 02:09:26-MDT,2637;000000000000 Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL> Date: Mon, 10 Apr 89 01:30:36 MDT From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL Subject: PACKET-RADIO Digest V89 #92 To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL PACKET-RADIO Digest Mon, 10 Apr 89 Volume 89 : Issue 92 Today's Topics: DIGIPAC. DRSI with no problems?-------------------------------------------------------- -------------- Date: 10 Apr 89 8:36 +0100 From: Karl Georg Schjetne <schjetne%vax.runit.unit.uninett%NORUNIX.BITNET@CUNYVM.CUNY.EDU> Subject: DIGIPAC. A couple of years ago I bought the DIGIPAC packet terminal program from Kalt in Alaska. The system works well in most respects. The printer function, however, does not work at all, it only gives me strange error messages. I have tried the system on an XT and on a 386, with my Proprinter. The company does not answer my letters, and as their ads have stopped showing up in QST and HR, I guess they are out of operation. If you have had the same problem, and have the cure for it, please assist me - I would like to continue using DIGIPAC I would also appreciate information on the COM1-COM8 version of DIGIPAC. 73 de Karl Georg Schjetne, LA8GE, Steinhaugen 29, N-7049 Trondheim, NORWAY. <schjetne@vax.runit.unit.uninett> LA8GE @ LA8GE ------------------------------ Date: 9 Apr 89 20:25:15 GMT From: pacbell!pbhyf!dejac@ames.arc.nasa.gov (D. E. Jacobson) Subject: DRSI with no problems? Good Day, I am wondering if anyone out there in packet world has successfully installed the DRSI Packet Adapter on an XT clone without any problems. I installed it on Saturday (4-7) and the AX.25 packet seems to work just fine. I made connections, checked into BBS etc. But I find that neither the TCP or the THS part will key the transmitter. If I use the cal command it keys the transmitter with no problems reguardless of whether its using mark, space or dots. But when I use the Alt C function of the THS or the connect ax0 ... of the net program it will not key the transmitter, even though it appears the software does not know it. The screen keeps telling me connection in progress (THS) but the transmitter is never keyed up. Any suggestions would be welcome. I will probably call the on monday and hope they have some ideas. Thanks for any ideas in advance. Dennis (N6NG) ------------------------------ End of PACKET-RADIO Digest ****************************** 11-Apr-89 01:54:36-MDT,2386;000000000000 Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL> Date: Tue, 11 Apr 89 01:30:17 MDT From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL Subject: PACKET-RADIO Digest V89 #93 To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL PACKET-RADIO Digest Tue, 11 Apr 89 Volume 89 : Issue 93 Today's Topics: HELP, need Genave GTX-10 manual PACKET-RADIO Digest V89 #91 Question on TCP & packet----------------------------------------------------------- ----------- Date: 10 Apr 89 14:53:25 GMT From: deimos.cis.ksu.edu!harris.cis.ksu.edu!mac@rutgers.edu (Myron A. Calhoun) Subject: HELP, need Genave GTX-10 manual In response to my plea for a manual, SEVERAL people have responded by saying they ALSO need a manual or a schematic, but NO ONE has admitted owning or having access to such a rare document! Can ANYONE supply ANY documentation for either the Genave GTX-2 or GTX-10? (I've been told they are essentially equivalent.) I'll reimburse for photocopying and mailing expenses, of course. ===== I have a 9-page document for the Ten Tec Model 242 Remote VFO; does anyone want it?-- Myron A. Calhoun, PhD EE, W0PBV, (913) 532-6350 (work), 539-4448 (home). INTERNET: mac@ksuvax1.cis.ksu.edu BITNET: mac@ksuvax1.bitnet UUCP: ...{rutgers, texbell}!ksuvax1!harry!mac ------------------------------ Date: 10 Apr 89 14:18:00 EDT From: "SWEIGERT, DAVID" <dsweigert@paxrv-nes.arpa> Subject: PACKET-RADIO Digest V89 #91 Zenith lap-top for sale. Someone in our office has a brand new Zenith lap-top for sale. 20 Meg HD. ------------------------------ Date: Mon, 10 Apr 89 19:33:55 EDT From: "Joe Skoler, KC2YU" <SKOHC@CUNYVM.CUNY.EDU> Subject: Question on TCP & packet Can somone please fill me in on what I need to operate TCP/IP on Packet. I have nrnet, a TCP program for the IBM, but I can't seem to access ax0, suppossedly the serial port leading to the TNC. I think I need a settings file. Can I create one myself? Need I have an IP address assigned to me for use on Packet? As you can see I know little about it, but I would very much like to find out. Thanks to all, Joe, KC2YU, skohc@cunyvm ------------------------------ End of PACKET-RADIO Digest ****************************** 12-Apr-89 02:20:55-MDT,4118;000000000000 Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL> Date: Wed, 12 Apr 89 01:30:57 MDT From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL Subject: PACKET-RADIO Digest V89 #94 To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL PACKET-RADIO Digest Wed, 12 Apr 89 Volume 89 : Issue 94 Today's Topics: corrected tiny2 mod Distribution of KA9Q code------------------------------------------------------------- --------- Date: 10 Apr 89 14:12:59 GMT From: vsi1!wyse!mips!prls!philabs!briar.philips.com!rfc@apple.com (Robert Casey;6282;3.57;$0201) Subject: corrected tiny2 mod copied from packet: Subj: TINY-2 MOD (corrected) PAC-COMM FACTORY MOD FOR TINY2 & MICROPOWER TNC This mod is for Units that have lost their ability to de-code packet unless driven hard from the speaker jack with a huge amount of audio. Paccomm has told me they are having problems with some boards and they cannot figure out why, but they do offer this fix. I had one for over a year that worked fine, then all of the sudden it changed and required 1/2 of available volume from a Icom 38A to decode properly. I just purchase another Tiny-2 from the factory, the new units are coming thru with this MOD already done. No, the modem chip is not the culprit, I changed the TCM3105 and it did not help. I'm sure if anyone does figure out the problem, that Paccomm will be obliged. If you are a registered ownwer of one of these units, a call to them will get you the Mod ready to install. For those who want to "roll their own", I offer the following discription of the modification. (Please note, if you have seen a earlier version of this message from me, it is erroneous.) The mod is installed in a NEW 16 pin IC socket that plugs into U-16, the socket for the TCM3105. Once new socket is plugged into the U16 socket on the TNC board, re-insert the TCM3105 into new socket. PARTS NEEDED: 1 16 PIN IC socket 2 10K resistors (brown-black-orange) 1 2222NPN transistor (EGC-123AP) Clip pin 5 on "NEW" socket, leave enuff to solder to, but cut off enuff of pin so it wont make contact when you insert this socket into old one. Solder EMITTER to pin 12 of new socket. Solder 1 resistor from pin 5 to pin 1 Solder BASE to 1 resistor, other end of resistor to pin 2 Solder collector to pin 5 Thats it! Hope this clarify's what Paccomm has done. 73's Bill\N2EZG @ KC2AZ ------------------------------ Date: 9 Apr 89 22:55:28 GMT From: mcvax!ukc!pyrltd!slxsys!g4lzv!keith@uunet.uu.net (Keith Brazington) Subject: Distribution of KA9Q code In article <15144@bellcore.bellcore.com>, karn@ka9q.bellcore.com (Phil Karn) writes: > For some time, I've been getting mail of the form "I want a copy of your > code but I can't FTP from here". Lately these requests have reached a fever > pitch. > 1. If you are at a university, commercial or governmental institution that > 2. If you cannot get on the Internet, find a friend who *is* on the net and > 3. If all else fails, wait until the new releases are announced as being or 4. Mail keith@g4lzv.co.uk and I'll send you the latest bits as I get them, including the G1EMM add on's. This applies to European or UK sites only. I only have UUCP access to the net, so mail is the only way out! > Thanks for your understanding. Thanks for the hard-work! :-) > Phil Karn, KA9Q Keith Brazington G4LZV -- UUCP ..!mcvax!ukc!pyrltd!slxsys!g4lzv!keith | Keith Brazington Smart mail keith@g4lzv.co.uk | 5b Northgate Rochester Kent UK Ampanet [44.131.8.1] and [44.131.8.3] | +44 634 811594 Voice Packet G4LZV @ GB7SEK -- G4LZV USENET BB --| +44 634 401210 Data v22,v22bis ------------------------------ End of PACKET-RADIO Digest ****************************** 13-Apr-89 02:24:18-MDT,2848;000000000000 Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL> Date: Thu, 13 Apr 89 01:31:13 MDT From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL Subject: PACKET-RADIO Digest V89 #95 To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL PACKET-RADIO Digest Thu, 13 Apr 89 Volume 89 : Issue 95 Today's Topics: DRSI with no problems? Equipment for 56 kbps - WHERE?----------------------------------------------------------- ----------- Date: 11 Apr 89 21:12:35 GMT From: mailrus!wasatch!uplherc!wicat!keithm@tut.cis.ohio-state.edu (Keith McQueen) Subject: DRSI with no problems? In article <4988@pbhyf.PacBell.COM> dejac@PacBell.COM (D. E. Jacobson) writes: >Good Day, > >I am wondering if anyone out there in packet world has successfully >installed the DRSI Packet Adapter on an XT clone without any >problems. >Dennis (N6NG) I am running a DRSI dual vhf port board in a true blue IBM PC running the AA4RE PBBS software. It seems to work quite well though admittedly, I do not use it as a normal tnc. I did have causing the BBS to run out of memory and the BBS software did not handle it properly. Let me know if I can help. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | Keith McQueen, N7HMF Organization: Wicat Systems, Inc. | | 1116 Graff Circle Work (801)224-6605x422 | | Orem, Utah 84058 Packet: N7HMF @ NV7V | | Home (801)224-9460 Voice: 147.340 MHz or 449.675 MHz | | =====> My opinions are all mine... <===== |- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ------------------------------ Date: 12 Apr 89 06:15:42 GMT From: mcvax!kth!draken!tut!tolsun!so-luru@uunet.uu.net (Ari Husa) Subject: Equipment for 56 kbps - WHERE? Hello, everyone! I do desperately need the following hardware: 1) PC Packet Adaptor by Digital Radio Systems, Inc. 2) WA4DSY 56 kbps packet modem The problem is, that I don't know hardly anything of them... not the price, not the very nature of the products (ready-to-run, never-to-run, or may-run-after-you-have-assembled-it), and most importantly, where to get these gadgets. Any information would be greatly appreciated! Thank You and 73 de Luru,-- ================================================================= ============= Ari 'Luru' Husa === Packet: oh8nup@oh8ta === E-mail: so-luru@stekt.oulu.fi Mail: Tiedonkaari 6 D 25 SF-90570 OULU FINLAND === Phone: +358 (9)81 561 173 ================================================================= ============= ------------------------------ End of PACKET-RADIO Digest ****************************** 14-Apr-89 02:31:28-MDT,18104;000000000000 Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL> Date: Fri, 14 Apr 89 01:30:40 MDT From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL Subject: PACKET-RADIO Digest V89 #96 To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL PACKET-RADIO Digest Fri, 14 Apr 89 Volume 89 : Issue 96 Today's Topics: FCC's recognition of repeater coordination is a disaster (2 msgs)------------------------------------------------------------ ---------- Date: 13 Apr 89 12:55:19 GMT From: texbell!splut!jay@bellcore.com (Jay "you ignorant splut!" Maynard) Subject: FCC's recognition of repeater coordination is a disaster In article <8904071934.AA29104@decwrl.dec.com> goldstein@delni.dec.com (Fred R. Goldstein dtn226-7388) writes: >Yes, Jay, it's not an easy question! How can coordinators make room for >new services (i.e., packet repeaters) when FM users have already claimed >all of the frequencies? This was, essentially, the question I had asked. As the president of the Texas VHF-FM Society, Texas' frequency coordinator, I'd gotten tired of some of the packeteers complaining about the amount of spectrum allocated to FM repeaters. I asked what we should do about it. The problem, as I see it, is that telling some subset of repeater trustees that they must shut down their repeaters, and others that they must move, to make room for more packet operations, is politically impossible. >The problem is basically that YOU are being asked to decide it, rather >than allowing the "forces of nature" to take their course. Weeeelll...Nice libertarian perspective, but there's one major problem as applied to the real world: the "forces of nature" also lead to repeater wars, which is the problem that frequency coordination was designed to prevent. (description of evolution from HF AM to SSB and 2 meter AM to FM omitted; it sounds about right, though.) >The uniform 600 kHz repeater business took place around '71, creating >the FM bandplan for 146-147. (Side note: my organization was a leader in formulating the bandplan we now use, except for the upright 15 kHz-split idiocy. [not me personally; this was before I became a ham] It was referred to for the longest time as the Texas plan.) >I was the editor of 73 Inc.'s "World Atlas of Repeaters 1976". That was >the first wide-ranging repeater atlas to feature maps. I did a LOT of >work putting it out, checking hundreds of club newsletters, etc. I >couldn't just ask the coordinators who was where; not every area had >one, and not every repeater was coordinated. But there were only a few >places where hams didn't work things out amicably. In the NY area, >co-channel repeater spacing was sometimes as low as 30 miles. Yeah, >they argued, but it wasn't all that different from 20 meters -- you try >to avoid interference and understand that the bands are crowded. Or you >have a repeater war for fun. (Why not? Many of the repeaters were >totally redundant, just there for ego-tripping, so repeater operation >was itself the thrill, not repeate use. And repeater wars are the >Radiosport of repeater ownership.) Wrong. Repeater wars are the single biggest threat to effective use of the VHF spectrum. The few places where hams didn't work out things amicably (notably Southern California) were a black mark on ham radio, and significantly hampered the acceptance of ham radio as a viable emergency communications resource. I obviously have a strong bias toward the coordination process, but the undeniable fact is that we're much better off now than in the bad old days. As we rediscovered in Dallas about three years ago, repeater wars do nobody any good. The difference is that now, the FCC can and will terminate one in short order, if one repeater is coordinated and the other isn't (the commonest case). >Eventually FM repeaters were allowed to claim the 144.5-145.5 band, and >when packet came out, all that was left was the simplex space around >145.0. All of the repeater pairs had been given out (in many areas), >by the time the FCC's coordination procedure was recognized. All of the repeater pairs have been issued in the Houston and Dallas/Fort Worth areas for some time now. The coordination process keeps the repeater bands usable, instead of allowing them to deteriorate into a quagmire of heterodyning carriers. >Now the repeater wars of 1972 weren't all good (or all bad, really; I >enjoyed watching some) but the FCC's recognition of coordination really >stopped evolution dead in its tracks. Coordinators were no longer >"voluntary", making their job tougher. After all, before, if you didn't >like their decision, you could ignore them, and if the "free market" was >with you, the coordination would become nugatory or moot. Now, though, >they're effectively stuck playing Gosplan, allocating resources among >competitive interests, with little or no market mechanism. You may enjoy watching a repeater war, but you're in a tiny minority. The rest of us realize just how bad they are. Instead of an idealistic free market, what would instead result is chaos, with the existing repeaters becoming increasingly unusable as disgruntled users decide to get back at the repeater trustees they dislike by putting up competing repeaters. Frequency coordination evolved out of sheer necessity. The necessity hasn't gone away simply because packet radio has burst upon the scene. >So what's a coordinator to do? Well, there are two approaches. One >(which is rather idealistic) is for coordinators to declare their >decisions "non-binding", legally, so they revert to their 1972-era >standing. They could also declare some coordinations to be more binding >than others, "protecting" only a critical backbone of repeaters, and >"suggesting" frequencies to others on a purely voluntary basis. Reverting to the 1972-era standing would be a step backward, not a step forward. If we didn't need it, we wouldn't have developed it. How can a coordinator determine what constitutes a "critical backbone"? Any such decision reeks of value judgments. Coordinators must avoid value judgments like the plague; they lead to unpleasantnesses like lawsuits and repeater wars. The only valid basis for any coordination decision is one that's completely objective. All else is chaos. >Another is for the coordinators, in their unpleasant GosRepeater role, >to recognize that FM voice users are no longer so preponderant on 2M >(and elsewhere; I just know 2M better) that they deserve as large a >percentage of the band as they did in 1979. New, non-voice allocations >could then be made where voice allocations already exist. Say we were to redefine the 144.5-145.5 band completely as digital. What do we do with the repeaters currently in that band? There's no place in the 146-148 MHz band to put them, in a lot of cases; that's why they are down there. We can't just tell him, "Sorry, but you have to turn it off now." He'd ignore us, and we'd be back in the quagmire. >Which exisiting allocations get booted? Well, in a "free market", the >least-used and most private machines would be the easiest ones to, uh, >"share frequencies with" and "encourage them to move". The 3-user >PL-access machine on Joe Bxzftlp's roof 30 miles outside of town might >be a good frequency to "share". So a coordinator would prioritize >existing allocations and ask the low-priority ones to move. Maybe let >someone offer to buy a new set of crystals. How do we prioritize objectively? Your list below is chock full of value judgments: > 1. Open repeaters with high usage. > 2. Closed repeaters with high usage. > 3. Open repeaters with little usage and unique features. > 4. Closed repeaters with little usage and unique features. > 5. Open repeaters with little usage and no unique features. > 6. Closed repeaters with little usage and no unique features. > 7. Historical allocations no longer actively used. Who decides what is high usage, and how? Who decides what are "unique features", and how? Who decides what is any other desirable characteristic of a repeater that might be taken into account in the coordination process? All of the above are value judgments. People's values differ. This is generally a Good Thing, but it renders any value judgment useless as input to a coordination decision. >Others might give more weight to openness; I tend to accept closed-ness >if there's justification, such as experimentation. Individual >coordinators, of course, would get to make up their own priorities and >apply them to the user base as they see fit. The low-priority >allocations then have to double up on frequencies, or use closer >co-channel or adjacent-channel distances to find new homes. That can >free up a few repeater pairs for packeteers and other future users. Individual coordinators making up their own priorities is exactly the situation we must avoid. A coordinator who says "Your repeater isn't as good as this other one over here" is begging to get sued. As much as allowing that kind of consideration to affect our thinking is a Bad Thing, we're stuck with it in our real world. >It's not an easy situation, but ham radio is stagnant enough without >applying the Force of Law to maintain frequency allocations in a time >warp simply because to change them would force some users to retune >their radios or, heaven forbid, learn to share frequencies. I know from >sad experience that 2M packet is a total mess, and I know from technical >analysis that full duplex repeaters give far more than twice the >throughput of single-frequency digipeaters. But to gain such >efficiency, we need repeater pairs, and they're all full up. Sharing frequencies on the repeater bands is politically unfeasible. Frequency coordination is, at its foundation, based on mutual consent. The trustee comes to the coordinator and, in return for agreeing to cooperate with the coordinator's conditions for coordination, is given a place to operate free from interference. This is more important for a repeater than it is in other amateur operations; effective use of a repeater depends on knowing where it can be found, and two or more repeaters on the same frequency simply make both unusable. >That's why I think the FCC's coordination rules are a disaster. They >can be changed, or the coordinators can recognize the problem and, at >the risk of making a few enemies, do the tough job themselves. The risk is far greater than just making a few enemies - it's the risk of making the entire repeater band unusable. -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can uucp: uunet!nuchat! (eieio)| adequately be explained by stupidity. hoptoad!academ!uhnix1!splut!jay +---------------------------------------{killer,bellcore}!texbell ! | "Less great!" "Tastes filling!" ------------------------------ Date: 13 Apr 89 21:55:19 GMT From: jupiter!karn@bellcore.com (Phil R. Karn) Subject: FCC's recognition of repeater coordination is a disaster Believe it or not, I actually find myself in (partial) agreement with Jay Maynard -- at least to the extent that he says that good coordination is better than no coordination at all. But I have to disagree strongly with his belief that it is impossible to move existing repeaters to make room for new modes and uses of the spectrum. Recently I had exactly the same argument with WA2BAU, former president of TSARC (the New York City area repeater council). It went something like this: KA9Q: "Gary, I think we should work on a 220 MHz contingency plan to reaccomodate the existing users of 220-222 MHz to spots above 222 MHz in case the FCC action in 87-14 becomes final. I've seen the contingency plans of a few other coordinators and they have made provision for some high speed packet channels." WA2BAU: "Sorry, can't do that. All of the channels above 222 are allocated." KA9Q: "Wait a minute. Doesn't it seem only reasonable that the loss of part of a band should be borne proportionately by the various users of the whole band? It seems completely unfair to say 'everybody below 222 loses' and 'life above 222 goes on as if nothing had happened'. The existing bandplan has five 100 KHz high speed channels between 220.5 and 221.0. Proportionately, then, we should end up with three. But I'd be happy to settle for just one." WA2BAU: "Doesn't matter. I can't tell any repeater operators to move or shut down. They'd sue me!" KA9Q: "How do you know *I* won't sue you?" I made this last remark in an exaggerated tone to indicate irony -- I don't seriously expect to sue anybody, even if things get much worse than they are. I have always felt that there are no real winners in a lawsuit, any more than in nuclear warfare, and this holds especially true for suits in amateur radio -- where amateur radio itself is always the loser. But I think the point I was making is completely valid. If coordinators are just going to throw up their hands whenever a problem like this comes up, then I don't see how they are doing their jobs. Proclaiming a fear of lawsuits is a cop-out, pure and simple. A spectrum manager should decide how to allocate spectrum on the basis of maximizing its effective use. There are lots of ways to determine and quantify "effective use", and they are certainly open for discussion and debate. Among the criteria that might be used are: a) the number of people using the allocation (the closed/open issue could be handled here). Larger user groups would gain priority. b) the size of the geographic area over which the allocation is made. Priority would be given to requests for spectrum that are limited to a small region, in order to enable spectrum re-use in other areas. c) the nature of the operation. Priority should be given to operations that are clearly above the norm in furthering the basic objectives of the amateur service. For example, a repeater with a history of public service should obtain priority over a system used exclusively for ragchewing. Applications supporting the development of new technologies should gain priority over "pure hobby" applications such as contesting or DX spotting. Priority might also be given to novel applications that increase the diversity of those available in a given area. d) the efficiency of the modulation and channel access schemes used. For example, SSB should be encouraged over FM. The use of higher efficiency modems in packet radio should be strongly encouraged. As discussed in my Anti-No-Code Myth #3, the proper measure for efficiency is bits/sec/Hz, NOT merely 1/Hz. (Actually, if you take item b into account, the proper units might be bits/sec/Hz/square kilometer. This reduces to units of bits/square Km, although I'm still trying to figure out a physical significance for this form.) The WA4DSY 56Kbps modem is about 10 times as spectrally efficient as the 1200 baud Bell 202, even though the former takes a channel 5 times as wide. The use of full-duplex repeaters for packet radio should be encouraged because the gain in efficiency due to the elimination of hidden terminals and the resulting collisions more than makes up for the extra channels required. Even with our existing, ridiculously inefficient 202 modems, traffic handling via packet is far more efficient than traffic handling by FM voice. I see little reason for handling any traffic by FM voice that could have been handled just as easily by packet. e) the occupancy of the channel. Applications making only light use of their channels should not have priority for exclusive allocations. Clearly there are aspects of each of these points that conflict with others. It's reasonable that there should be plenty of discussion and compromise as to what the proper "weighting factors" should be. But you will note that I have not mentioned the one criteria that, until now, has been the only thing that most repeater councils seem to go on: who was on the air first. There are lots of problems with this philosophy. The FCC apparently agrees with me, as they went so far as to require every applicant for a radio license (including amateur) sign a statement that waives any claim to any particular frequency, whether by prior use or otherwise. (This is from memory, so I may not have the exact wording.) In any event, the meaning is pretty clear. Frequency allocations should be made on the basis of how the spectrum can be most effectively utilized and the basis and purpose of the amateur service best served, and the practice of discriminating against users whose sole misfortune is that they were born in a later year than the present users works against this goal. There's a 2m repeater near here that was probably one of the first ones on the air. Because of the "first come, first served" policy, their allocation is secure; they don't have to do anything to justify keeping it, so they don't bother. Today it is seldom used for anything other than interminable ragchews between the old farts. The one way I would give weight to "prior occupancy" of a frequency is in establishing the existing user's track record in the kinds of criteria I mentioned above. Nevertheless, frequency coordinators have a duty to encourage the most effective use of our spectrum, and there are plenty of situations where existing users might have to be displaced. No one expects a frequency coordinator to be all wise or to predict the future. I only expect him to use his best judgement for the benefit of the amateur service as a whole. And that should be adequate defense for any lawsuit. Phil Karn, KA9Q ------------------------------ End of PACKET-RADIO Digest ****************************** 15-Apr-89 02:38:14-MDT,2837;000000000000 Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL> Date: Sat, 15 Apr 89 01:30:58 MDT From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL Subject: PACKET-RADIO Digest V89 #97 To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL PACKET-RADIO Digest Sat, 15 Apr 89 Volume 89 : Issue 97 Today's Topics: DRSI PC*Packet Adapter---------------------------------------------------------- ------------ Date: Fri, 14 Apr 89 14:48 CDT From: <JKK3283%TAMVENUS.BITNET@icsa.rice.edu> Subject: DRSI PC*Packet Adapter Greetings all. I have a couple of comments to make about the installation and use of the PC*PA with the AA4RE software. My system configuration here is an AT&T 6300. I have had NO PROBLEMS with installation of my system of the PC*PA. As the instruction manual states, the most common problems are with interupts (namely conflicts with IRQ2.) I never had a problem. Mine went straight into the slot and worked fine when I turned it on. (My mouse automatically switched to IQR3 from the original IQR2 setting it had.) The only problem I had with the PC*PA was the audio source from the radio. I was pulling audio from the pin in the mic plug - turns out that my radio (a Kenwood TM-221A) was not suited for this application. I have since changed over to pulling the audio from the external speaker and things have never worked better! No problems have been encountered since I fixed the audio. As far as my experience with the AA4RE BBS software goes, I have had very good successful with it except for 1 thing - I can't figure out why reverse forwarding doesn't work for me? I have set things as the DOCS suggest (classifying BBS's according to B or A in the EU area, but things still don't work for me.) I would appreciate any comments as to the nature of this problem. (I am using the AA4RE BBS as my personal mailbox at this time, since the club I belong to, W5AC (Texas A&M Univ.) is running the local BBS on RLI 10.01. As far as getting a hold of DRSI, I have had no problems. Their customer support has been EXCELLENT for me. Very quick turn-around time and all my questions have been answered. (I took a personal tour of the DRSI facilities in Clearwater, Florida, and was very impressed.) I would appreciate hearing from other PC*PA owners. We seem to be a minority for now - I haven't found many! An exchange of ideas and suggestions/comments/etc... would really be great. Thank you very much for allowing me to express my comments and questions here. Best 73's. John K Kreymer N5LKM @ W5AC (packet) JKK3283 @ TAMVENUS (Texas A&M Univ.) ------------------------------ End of PACKET-RADIO Digest ****************************** 16-Apr-89 01:58:27-MDT,9245;000000000000 Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL> Date: Sun, 16 Apr 89 01:31:00 MDT From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL Subject: PACKET-RADIO Digest V89 #98 To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL PACKET-RADIO Digest Sun, 16 Apr 89 Volume 89 : Issue 98 Today's Topics: FCC's recognition of repeater coordination is a disaster (2 msgs) PACKET-RADIO Digest V89 #96-------------------------------------------------------------- -------- Date: 15 Apr 89 07:23:35 GMT From: nuchat!splut!jay@uunet.uu.net (Jay "you ignorant splut!" Maynard) Subject: FCC's recognition of repeater coordination is a disaster In article <15309@bellcore.bellcore.com> karn@jupiter.bellcore.com (Phil R. Karn) writes: >Believe it or not, I actually find myself in (partial) agreement with >Jay Maynard -- at least to the extent that he says that good >coordination is better than no coordination at all. >gasp!< :-) My turn...thanks, Phil. >But I have to disagree strongly with his belief that it is impossible to >move existing repeaters to make room for new modes and uses of the >spectrum. Recently I had exactly the same argument with WA2BAU, former >president of TSARC (the New York City area repeater council). It went >something like this: (argument about reallocating 220 deleted in the interest of space) Phil, were you counting ours in amongst the ones you've seen? In any event, 220 is a special case: there's a force majeure factor to it that doesn't apply to packet and other specialized modes. The FCC isn't telling us to go to packet. They are telling us to get off of 220-222 (hopefully, not yet finally). I'll give you an example of the most that I feel can be accomplished: Four years ago, we were faced with a difficult decision. The ARRL VRAC, in its finite wisdom, decided that 15 kHz channels east of the Rockies should be in the same direction as the adjacent 30 kHz pairs. This was opposite to our bandplan, which had the 15 kHz pairs inverted. We ran some tests, and showed technically that upright 15 kHz was inferior in the real world. We were unable to influence the VRAC. That left us with a problem, as the adjacent states were all going to upright 15 kHz pairs, which would lock up with our inverted 15 kHz repeaters near the border. After much debate and soul-searching, we decided, rather than degrade the usability of the 2 meter band by adopting the VRAC plan, to maintain the quality of service for the repeater users, by going to the same 20 kHz plan as Washington state. We were able to do this for two reasons: 1) The problem was easy to see, and the solution was demonstrably better than the alternatives; and 2) nobody would have to shut their machine down. There was significant resistance, and there are a few repeaters stubbornly refusing to move. If either of the two factors above did not exist, we would not have succeeded. There are still political ripples through the Society from that decision. >If coordinators >are just going to throw up their hands whenever a problem like this >comes up, then I don't see how they are doing their jobs. Proclaiming a >fear of lawsuits is a cop-out, pure and simple. We are in the process of extricating ourselves from a lawsuit now. It's no fun. The plaintiff has, very successfully, stymied a number of our actions for two years while the suit has dragged on. Lawsuits are something to fear. I agree that we need to do something, but coming up with an answer that is politically feasible is much tougher than simply saying "Bite the bullet: like it or not, you're moving." - or worse: "...we can't move you anywhere; you'll have to shut down." >A spectrum manager should decide how to allocate spectrum on the basis >of maximizing its effective use. There are lots of ways to determine and >quantify "effective use", and they are certainly open for discussion and >debate. Among the criteria that might be used are: None of them are objective, though. Objectivity is an absolute requirement, or else the process will be widely ignored or sabotaged. Your priorities sound reasonable - to me. They might not to someone else, though, and that is the problem: they all involve a value judgment. We cannot get in the business of value judgments. >Even with our existing, ridiculously inefficient 202 modems, traffic >handling via packet is far more efficient than traffic handling by FM >voice. I see little reason for handling any traffic by FM voice that >could have been handled just as easily by packet. How about training for emergency communications? Far more emergency traffic will be handles, at least for the foreseeable future, on voice than will be on packet. I am not saying that packet's not a better way to do it, in a purely technical sense; what I am saying is that it will not get done that way, and the voice operators need to be trained. >Clearly there are aspects of each of these points that conflict with >others. It's reasonable that there should be plenty of discussion and >compromise as to what the proper "weighting factors" should be. But you >will note that I have not mentioned the one criteria that, until now, >has been the only thing that most repeater councils seem to go on: who >was on the air first. Despite the fact that that's often the only completely objective criterion, and the only one that does not involve a value judgment. >The one way I would give weight to "prior occupancy" of a frequency is >in establishing the existing user's track record in the kinds of >criteria I mentioned above. Nevertheless, frequency coordinators have a >duty to encourage the most effective use of our spectrum, and there are >plenty of situations where existing users might have to be displaced. ...and, short of a clear consensus in the community that that will be in the best interests of ham radio (as in the 20 kHz change) or external force requiring the change (as in the 220 MHz grab), the users who we would displace will say, "Hell no! We won't go!" and destroy the whole idea. >No one expects a frequency coordinator to be all wise or to predict the >future. I only expect him to use his best judgement for the benefit of >the amateur service as a whole. And that should be adequate defense for >any lawsuit. Haw. Our lawyer disagrees with you. I tend to trust his opinion on the subject a little more. -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can uucp: uunet!nuchat! (eieio)| adequately be explained by stupidity. hoptoad!academ!uhnix1!splut!jay +---------------------------------------{killer,bellcore}!texbell ! | "Less great!" "Tastes filling!" ------------------------------ Date: 16 Apr 89 01:55:37 GMT From: w3vh!rolfe@uunet.uu.net (Rolfe Tessem) Subject: FCC's recognition of repeater coordination is a disaster In article <15309@bellcore.bellcore.com>, karn@jupiter (Phil R. Karn) writes: > > A spectrum manager should decide how to allocate spectrum on the basis > of maximizing its effective use. There are lots of ways to determine and > quantify "effective use", and they are certainly open for discussion and > debate. > Precisely. The problem, of course, is that our "frequency coordinators" aren't spectrum managers. As we know all too well, they consist primarily of groups of existing voice FM repeater owners. Maybe this part of the country is unusual (I doubt it) but I have *never* heard anything of interest being discussed on a two meter FM repeater. I have heard *one* repeater used quite effectively in severe weather situations, but that's it. How many voice FM repeaters do most areas really need? -- UUCP: uunet!w3vh!rolfe | Rolfe Tessem INTERNET: rolfe@w3vh.uu.net | P.O. Box 793 AMPRNET: rolfe@pc.w3vh.ampr.org [44.44.0.2]| Great Barrington, MA 01230 PACKET RADIO: w3vh@wa2pvv | (413) 528-5966 ------------------------------ Date: Sat, 15 Apr 89 10:44:38 EDT From: Chris Tate <BIW104%URIACC.BITNET@mitvma.mit.edu> Subject: PACKET-RADIO Digest V89 #96 I agree that more packet frequencies are needed even though where I live the problem isn't bad. HOWEVER, how can a person or AR club be expected to shut down their rather large investment because of prior mistakes in bandplans! Everyone knows that they can't be moved. So what is a club or person supposed to do? Pack it in because of packet? The division of the frequency spectrum has and always will be done poorly.. There is nothing we can do. Look at TV and FM broadcast. The FCC got bought and there is no changing *that* now, nor is there ever going to be a channel 1 again. And my most hated fo-pa: CB on 27MHz. How can you make such a mistake and ask for so many problems! I can't see any resolution other than more packet on other bands which need the use anyway. Chris Tate BIW104@URIACC KA1IVW ------------------------------ End of PACKET-RADIO Digest ****************************** 16-Apr-89 11:22:57-MDT,18021;000000000000 Mail-From: KPETERSEN created at 16-Apr-89 11:10:27 Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL> Date: Sun, 16 Apr 89 11:10:26 MDT From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL Subject: PACKET-RADIO Digest V89 #99 To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL PACKET-RADIO Digest Sun, 16 Apr 89 Volume 89 : Issue 99 Today's Topics: gateway 3/31/89---------------------------------------------------------- ------------ Date: 15 Apr 89 20:16:55 GMT From: osu-cis!n8emr!gws@tut.cis.ohio-state.edu (Gary Sanders) Subject: gateway 3/31/89 ============================================================== | Relayed from packet radio via | | N8EMR's Ham BBS, 614-457-4227 (1200/2400/19.2 telebit,8N1) | ============================================================== Gateway: The ARRL Packet Radio Newsletter - March 31, 1989 Stan Horzepa, WA1LOU - Sal Prado, Gateway Circulation - Volume 5, Number 14 NORTHWEST PACKET NETWORKING FORUM The Northwest Amateur Packet Radio Association (NAPRA) will hold the 1st Northwest Packet Networking Forum on Saturday, July 15 in the Seattle area. Its purpose is to discuss ways to improve the network's operation and architecture today, tomorrow and far into the future. The forum discussions will be divided into subjects centered around these three time frames with individuals sharing proposals or concepts. Each time frame will have a moderator whose purpose is to insure everyone has an opportunity to express ideas or ask questions. NAPRA strongly encourages everyone's participation in this two-way dialog. With this in mind, they ask those who desire to present their ideas to submit a summary in order to allow proper scheduling. Also, they would like to hear ideas and problems to be discussed. The only prerequisite for attendance is a working knowledge of packet radio and a desire to improve the network. NAPRA will be releasing further details in the near future, ie, place, time, directions, accommodations, etc and would like to hear from all of those planning to attend. The point of contact in NAPRA is Dennis Goodwin, KB7DZ @ KD7NM. from Tad Cook, KT7H @ KE7OM. PACKET IN THE USSR The January issue of Radio, a monthly magazine published by the Ministry of Communications of the USSR and the military training organization DOSAAF, featured an article about last year's SKITREK expedition written by Leonid Labutin, UA3CR. The following excerpts describe packet radio's role in the expedition. Packet-radio communication was used for the first time in our country (USSR) in the expedition's radio network. It was with great difficulty that we received permission for packet- radio communication from our official organizations. Foreseeing bureaucratic obstacles, we began to prepare the necessary equipment and got acquainted with the equipment in advance. We received assistance from colleagues in Hungary, US and Canada. As a result, we were successful in providing the following six stations with packet- radio equipment: EX0KP, Sredniy Island, operators UA3CR, RA3AU and VO1SA/UA0 4K0DC, SP-28, operators UA2AOC and VE3CDX EX0PM, Dikson Island, operators RW3DR and UA3-170-569 EX3HR, Moscow, expedition staff station, operator UA3HR RA3APR, Moscow, reserve station UA9NS, Omsk, repeater station Commercially made MFJ-1274 and PK-232 units were used as packet-radio controllers. Radio-96PK and Robotron (on Sredniy) computers were used. Packet-radio communications was used to the very end of the expedition and revealed all of its marvelous characteristics - 100% documentation, ability to prepare information in advance, high-speed exchange and so on. Any packet-radio station can serve as a repeater, which is extremely convenient. And no distortions. The central- newspaper correspondents, who came to our snowed-in station, were amazed by our electronic mailboxes. I would like to mention here an initiative of the University of Surrey. Michael Meerman, G0/PA3BHF - with the approval of his "boss," Dr. Martin Sweeting, G3YJO - organized a special mailbox for the expedition. Only network stations could "deposit" letters. All interaction with the electronic mailboxes took place practically without operator intervention. We calculated that during the expedition, the base stations transmitted over 500 kbytes of information. from Dexter Anderson, W4KM BINARY-TO-DATA-TEXT-CONVERSION UTILITY AVAILABLE R95 implements the Radix 95 binary to data text conversion algorithm presented at the 7th ARRL Amateur Radio Computer Networking Conference in 1988. R95 implements R95 encode and decode as well as the R95SPLIT format for split and combine as mentioned in the paper. The advantage to R95 over other conversion schemes is that it generates lower overhead. Radix 95 only generate 18% to 20% overhead on conversion, while using a 6- to 7-bit variable-length encoding scheme. R95 is shareware distributed by Texas Packet Software, which is currently working on the Macintosh version of R95, as well as R95^2 which should present even lower overhead (12, 13, 14 bits). Background Binary files can be difficult to transfer over the current amateur packet-radio network. R95 provides a way to convert data, such as compiled programs, graphic images or any other nonprintable data, into printable ASCII characters and allow their transfer in the Converse Mode. A TNC can be configured in ways to allow the transfer of 8-bit data while in the Converse Mode (8BITCONV ON, AWLEN and XFLOW OFF); alternatively, one can use the Transparent Mode. However, both methods are sometimes frustrating and time-consuming to the user. Having the ability to translate an 8-bit data file into printable ASCII characters offers great benefits. 8-bit to 7-bit conversion is fairly straight-forward. The three steps involved are: 1. Translate a sequence of bits into printable ASCII code, 2. Transmit the data, and 3. Convert the ASCII code back to its original form. The problems facing the transmission of 8-bit data are: 1. How to transmit the eight (or more) binary digits, 2. How to pass certain 7-bit sequences without having the sequence interpreted as a control character, and 3. How to avoid significant increase in file size (overhead). Radix 95 offers a solution to these problems. It uses all printable ASCII characters (ASCII 32-126) to carry meaningful code, thus eliminating the transmission of eight or more bits and the transmission of control characters, while creating less overhead than most common conversion methods. A common practice is to view a file as a collection of bytes of characters. By viewing the input file as a continuous string of bits, it is possible to break the file into segments of fixed or variable lengths. As long as the segments are kept in the proper order during encoding and decoding, the transfer takes place correctly. The R95 utility is a number of bundled tools that makes the conversion task easier. The R95 tools are: R95 encoding, R95 decoding, R95 splitting and R95 combining. In addition, R95 allows the user to specify the input/output paths used and provides a DOS Gateway. R95 creates two basic types of file formats. The first is the R95 format file, which contains encoded data created by the R95 encode function and read by the R95 decode function. The second is the R95SPLIT format, which is used by the R95 split and R95 combine functions. R95 Tools Encode - Reads a binary or text file and converts the file to the R95 format. The original file name is placed in the R95 header with a character count check placed at the end of the tail line. Decode - Reads an R95 format file and converts it back to the original file. Decode will read the first ten lines of the R95 format file to look for the R95 header line. In this way, the user does not have to edit the R95 format file in most circumstances. This allows for the natural addition of lines introduced before the R95 header. Decode will then restore the file and check to see if the character count was correct, in case an error occurred in transmission. Split - Reads an R95 format file and splits it into kbyte sections. Split creates FILENAME.### with ### being incremented for each file. Thus, the user creates file .001, .002, .003 ... Combine - Reads the R95SPLIT format and recombines the files. The split files must have the same file name and be followed with the extension .001, .002, .003... corresponding to the numbering in the split files. Combine will attempt to recombine the files using the numbered extensions. It will also attempt to find the R95SPLIT header in the first ten lines, thus, allowing for extra lines to be present in front of the header. This allows for the natural addition of information added by mailbox systems. Path - Allows the user to change where the files are being read and where the files are being written. ! - The DOS-Gateway provides a shell to command.com. Typing EXIT while in the gateway, returns to R95. BINARY-TO-DATA-TEXT-CONVERSION UTILITY AVAILABLE (Continued) Scenario Let's say John, W9DDD, wants to send a 32-kbyte binary TexNet image called DENTON.BIN to Greg, WD5IVD. Let's see what happens to get that file from John to Greg. 1. Depending on how far the file will travel, John will decide whether to send the file as is, or compress it with an archive program to reduce the file's size. Since John wants to make the transfer as small as possible and create less impact on the network, he chooses to archive the file, creating DENTON.ARC. (ARC results in a 19-kbyte ARC file with approximately 59% compression.) 2. John now runs the R95 utility and selects encode. He enters DENTON.ARC as the the file to be encoded. R95 now creates DENTON.R95 (indicating it is now in R95 format). (R95 encoding results in a 24- kbyte R95 format file with approximately 20% overhead.) 3. John now must determine if he needs to split the file or not. If Greg were a local connect or a mailbox upload area away, he could just send the whole file at once. If the file is to travel over Skipnet, he should keep the file split, sized less than 5 kbyte. Since John will be placing the files on the TexNet Dallas PMS, he will split the file into 7-kbyte segments. John selects DENTON.R95 to be split into 7-kbyte files. R95 now creates DENTON.001, .002, .003 and .004. 4. John then connects to TexNet and uploads the messages to the Dallas PMS. He sends SP WD5IVD because he does not want an unsuspecting person to read the messages by accident. He then enters DENTON.001 OF 004 as the message title, letting Greg know what suffix to give each file as he captures it. John uploads DENTON.001. He repeats the steps above until he has sent all 4 messages. 5. Greg checks the Dallas PMS some time later and sees that he has four R95 files waiting for him. Greg then downloads each message and captures it to GREG.001, GREG.002... (Note that Greg is able to use a different common file name). 6. Greg runs R95 and selects Combine. He enters GREG.001 as the file name with which to begin the R95 combine process. If there is an error in any of the split files, R95 will inform Greg that an error has occurred and in which file. If there is an error in one part, Greg would ask John to upload that one file again. Combine will reintegrate the file name contained in the R95SPLIT header to produce DENTON.R95 in this example. 7. Greg then selects Decode and enters DENTON.R95, which decodes DENTON.BIN (the name was contained in the R95 header). Hopefully, this will occur without errors. Recommendation The important thing to remember is that the packet-radio network is a fairly fragile environment and when you want to transfer R95 files, you should attempt to be as low-impact as possible. That translates into using compression programs (ARC and PKARC) as well as spacing the split files when you post and/or send them. Potential problems occur with items such as STREAMSW, which is sometimes set to a | (vertical line). Such cases of printable characters being interpreted by the TNC as a command could cause R95 uploads to fail. If STREAMSW is set to | (vertical line), when the TNC sees this character, it strips it while also stripping the next character as the stream to switch to, thus losing two characters. The solution is to set STREAMSW to a non-printable character. The TAB character works well for this. Another problem is TNC buffer overflow. Depending on how your computer talks to the TNC, you might feed the data too fast for the TNC to handle, thus losing whole lines of characters. The solution is to slow the information dump to the TNC from the computer or setup correct flow control between the TNC and the computer. Source R95 is available as shareware. For further details contact: Texas Packet Software PO Box 50106 Denton, Texas 76206 That gets you the R95 Utility, R95 Manual, encode, decode, split and combine source code. from Greg Jones, WD5IVD, and the Texas Packet Radio Society Quarterly Report [Ed Note: Sending binary files that don't map to printable ASCII characters is OK above 50 MHz for contacts within the FCC's jurisdiction. One might run afoul of the FCC rules sending unreadable stuff on frequencies below 50 MHz, particularly if in QSO with a foreign station unless the US and that country have agreed to such communications. We are not aware of any such agreements in existence. Neither do we know how sensitive the FCC might be about transmission of this type if it is strictly to facilitate communications. The mystery would be cleared up if any stations are using coding techniques to obscure meaning, however. --W4RI] W0RLI PBBS VERSION 10.0 AVAILABLE W0RLI PBBS Version 10.02 is now available. It contains many changes, therefore, no fast upgrade file is available. The SMTP gateway server is being worked on by Mike Chepponis, K3MC, so if you need that feature use Version 9.07 until further announcement. Send bug reports to VE3GYQ @ VE3GYQ - or - WA6RDH @ WA6RDH. from David Toth, VE3GYQ via CompuServe's HamNet ROSE SWITCH SOURCES The ROSE (RATS Open Systems Environment) X.25 Packet Switch software is available from two other sources besides CompuServe's HamNet (data library "DL9," file name "ROSESW.ARC"), which was mentioned in the previous issue of Gateway. The software may also be downloaded from The RATS BBS at 201-387-8898. Log on as "rats" ("rats" must be entered in lower case) and a menu will appear listing current files followed by a prompt for your name, etc. and then the file name ("rosesw.arc"). The file transfer is available using XMODEM only. Mor information may be obtained by sending SASE to: The Radio Amateur Telecommunications Society 206 North Vivyen St Bergenfield, NJ 07621 If you like the software send an indication of your support! Please include your name, call sign, address, telephone number and home PBBS. from J. Gordon Beattie, Jr, N2DSY CALL FOR PAPERS - RSGB DATA SYMPOSIUM SCHEDULED Anyone who wishes to present a paper at the 2nd Radio Society of Great Britain (RSGB) Data Symposium should contact Mike Dennison, G3XDV, at RSGB headquarters (Lambda House, Cranborne Road, Potters Bar, Hertsfordshire, EN6 3JE, England) as soon as possible. (The symposium will be held concurrently with the AMSAT-UK Space Colloquium at the Harrow School near London on July 28-30.) REGION 1 IARU CONFERENCE The Region 1 IARU conference will be held in Spain in April 1990. Although this conference is one year away, papers for the conference need to be ready within a couple of weeks. Anyone wishing to contribute should write to the Packet Working Group care of the Radio Society of Great Britain (RSGB, see address in preceding paragraph) as soon as possible. The conference will deal with such matters as band planning and international coordination, without which the integrated worldwide data network will remain a pipe dream. from Connect International UNIX/MS-DOS PBBS IN THE WORKS Mark Holbrook, WS7M, (13327 251st SE, Issaquah, WA 98027) is writing a PBBS program to work under both UNIX and MS-DOS. Mark is wondering if some interested folks would like to contribute ideas on what his PBBS should be capable of doing (at this point, he is interested in the SYSOP features more than anything else). GATEWAY CONTRIBUTIONS Submissions for publication in Gateway are welcome. You may submit material via the US mail to: Gateway Stan Horzepa, WA1LOU 75 Kreger Drive Wolcott, CT 06716-2702 or electronically, via CompuServe to user ID 70645,247. Via telephone, your editor can be reached on evenings and weekends at 203- 879-1348 and he can switch a modem on line to receive text at 300, 1200 or 2400 bit/s. The deadline for each issue of Gateway is the Saturday preceding the issue date (which is typically a Friday). REPRODUCTION OF GATEWAY MATERIAL Material may be excerpted from Gateway without prior permission, provided that the original contributor is credited and Gateway is identified as the source. ------------------------------ End of PACKET-RADIO Digest ****************************** 16-Apr-89 11:39:52-MDT,11783;000000000000 Mail-From: KPETERSEN created at 16-Apr-89 11:17:28 Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL> Date: Sun, 16 Apr 89 11:17:27 MDT From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL Subject: PACKET-RADIO Digest V89 #100 To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL PACKET-RADIO Digest Sun, 16 Apr 89 Volume 89 : Issue 100 Today's Topics: G8BPQ Multiport Packet Switch----------------------------------------------------------- ----------- Date: 15 Apr 89 20:07:59 GMT From: osu-cis!n8emr!gws@tut.cis.ohio-state.edu (Gary Sanders) Subject: G8BPQ Multiport Packet Switch THE G8BPQ AX25 PACKET SWITCHING SOFTWARE (TheNode) A Progress Report - by John Wiseman, G8BPQ From: CONNECT INTERNATIONAL, January/February 1989 - Copyright 1989 by Radio Society of Great Britain- Reprinted by Permission It is now just a year since I started writing my PC-based AX25 switching software. An outline of the system appeared in CI a few months ago, but for those who didn't see it, I'll summarise its main features: The system was originally planned to be a high performance network node. At the time, the only way of building multiband nodes was to interlink TNC2 (or compatible) TNCs running NET/ROM software via a multidropped async bus running at 9600 bps. This was expensive in both hardware and software, and was limited in both AX25 channel speed, and interport bandwidth, and ithe method of interlinkingg the TNCs (via a diode matrix) made nodes with more than 4 ports very difficult to implement. Things have changed somewhat over the past year (The introductions of TheNet has eliminated the software cost, a variety of TNC2 clones have been produced, and improved interlinking techniques developed), but there is still nothing capable of running very fast links. Also, with the rapid expansion of the network, the need for each port of a multiport node to have its own callsign, and hence entry into the nodes list, has caused the list to get rather large. (The FAT node complex has 8 entries, and the DV system 4). My software allows a multiport node to run with a single callsign, will support AX25 links up to at least 64Kbps (given suitable comms hardware), and eliminate the bottleneck of the async link between ports. The software also allows the user, or more usefully a BBS System, direct access to the Network. This was originally thought to be of less importance than the improved node performance, but the introduction of the multiport BBS systems, and the rather slow introduction of radios and modems capable of high speed operation (not to mention the licencing problems on the band generally regarded as ideal for high speed working (23cms)), has meant the initial installations have been primarily to support multiuser BBS systems. The software will support up to 16 copies of the chief multiuser BBS systems that run in a multitasking environment (WA7MBL and W0RLI), or up to 16 users on the G8UFQ system. (although the BBS systems themselves may not support so many copies - MBL seems to run into trouble with its BTRIEVE files if more than 5 copies are run). This traffic may be trunked over a single radio link (preferably at 9600 BPS on a dedicated link!) to the nearest network node. All BBS ports have the same callsign, which also appears in the nodes list of neighbouring network nodes, allowing the user to connect directy from the local node. CURRENT STATUS The software has been running at a couple of sites since September, and a "Beta Test" stage commenced in mid-December. About six copies are currently running, and are supporting MBL, RLI, and UFQ BBS Systems. The software seems to behave reasonably well, but a few unexplained crashes have occured, so there is still some way to go before it is fit for general release. Also no-one is currently running it as a major switching Node. BENEFITS TO BBS SYSOPS. The system gives two main benefits to BBS operators, and two to BBS users. It allows a multiuser MBL or RLI system to operate with just one radio, instead of needing a separate TNC and transceiver (and band) for each port. Setting up the forwarding system is greatly simplified, as the networking software does away with the need to define each step in the FWD file. The forwarding system should also be more reliable, and the network will automatically reroute round a failed link. The user benefits from being able to call the BBS directly from his local Node, by the Sysop being able to support more simultaneous users, and by not needing to try several different routes and calllsigns to find a free port. FUTURE PLANS Once the current beta test phase is completed, I have a bit of work to do to make the system more like the existing NetRom/TheNet code (eg - Sorting Nodes list into alphabetical order, and implementing the CQ command). I have found a source for a comms card which will run up to at least 256kbps, so I will produce a driver for that, so that I will be ready when very fast microwave links become available. I am also planning a version which can run from PROM, so that a node can be built using a PC motherboard (now available very cheaply) without disk drives. Rather further in the future is investigations into protocols suitable for building a high speed "trunk overlay" network. The existing NetRom system works pretty well at current link speeds and relatively limited total range (nodes in the South East have no knowledge of those in, say, Scotland), but I don't think it is really up to coping with a nationwide network. I think we may end up with regional NetRom-like systems, interlinked by some other system. Any ideas would be welcome! ====================== Mr G. J. Chester G8UFQ ====================== As we were going to press the news was received of the untimely death of Mr. G. J. Chester, G8UFQ, whose BBS software is mentioned several times in this edition of Connect International. Copied by Hank Greeb, N8XX 02-Apr-89 Final update from Daventry - OR "Who Shot DV" from the series "EASTNODERS" By: John Theodorson G4MTP and Neil Riemer G4JTY - Editors From: CONNECT INTERNATIONAL, January/February 1989 - Copyright 1989 by Radio Society of Great Britain- Reprinted by Permission Well things have gone apace here since we started writing C.I. back in February. When we started the BBS - node links looked like this: AT clone running - +------+------+------+------+ Quadport card (5 serial ports) ! BBS ! BBS ! BBS ! BBS ! EEMS card with 4 Mb memory !Window!Window!Window!Window! 4 TNC''s plus 4 radios ! 1 ! 2 ! 3 ! 4 ! +------+------+------+------+ Software use is WA7MBL ! ! ! ! version 4.31 running under RF Links --> 2m 4m 6m 70cm desQview with four windows ! ! ! ! +------+------+------+------+ Interconnected ! DV2 ! DV4 ! DV6 ! DV7 ! Net/Rom Nodes ! Node ! Node ! Node ! Node ! +------+------+------+------+ Now this was fine and all worked very well but there were may draw backs such as somebody connecting on the 2m port and finding that that port was busin and then in turn trying the various other ports until one was found to be free. Other problems were associated with long convoluted handcrafted 'forward files' to make the necessary connects to those to whom we forwarded and visa versa. Not to mention the obvious investment in four rigs, four TNC's, Quadport Card and EEMS Card. However as you will see from other articles in this copy of C.I. various software/hardware combinations have become available this year from the brilliant talent available here in the UK. This has revolutionized the concept of running a multiport BBS. The current setup is now: AT clone running - +------+------+------+------+------+------+ 640K Memory ! BBS ! BBS ! BBS ! BBS ! BBS ! BBS ! 1 TNC + 1 Radio !Window!Window!Window!Window!Window!Window! 1.3GHz 9600 Link ! 1 ! 2 ! 3 ! 4 ! 5 ! 6 ! +------+------+------+------+------+------+ Software used G4YFB ! ! running under Desqview ! G8BPQ - TheNode - Software ! with 6 Windows +------+------+------+------+------+------+ ! +-----------+--------------+ ! 1.3 GHz Link @ 9600 Baud ! +-----------+--------------+ ! +------+------+------+------+------+ Interconnected ! DV2 ! DV4 ! DV1 ! DV6 ! DV7 ! Net/Rom Nodes ! Node ! Node ! Node ! Node ! Node ! +------+------+------+------+------+ Now instead of the four non-interlinked windows we have six windows all with the same callsign which will be transparently selected by the BPQ software as each user connects or when the BBS goes into forwarding. The BPQ software also allows direct level 4 connects in the forwarding file. The YFB BBS software runs in a 640K (sic.) window so six windows in a standard 640K machine are possible, and of course now only one comport is used. The many other advantages of Steve's BBS software can be seen in his article elsehwere in this publication. The whole set up runs extremely fast and is very reliable. Gone is the confusion of which radio port is free to connect to, and what is it's callsign. Gone are the days of "BUSY FROM GB7NTS-7:. A simple C GB7NTS from the nearest node will result in a connect to any of the available BBS window. James Miller's (G3RUH) 9600 baud modem performs extremely well and results in the traffic from all six windows flowing much faster than it ever did over the four independant RF links at 1200 baud. As a result of the presentation made by Ian G0CND at the recent Sysops meeting and the subsequent work done by Mike G8TIC and John G8BPQ in coordinting the network we now have a situation where all the traffic flows much more efficiently and reliably around the network. As you see the net result is a far less complicated system running very much more efficiently and effectively. May I recommend to anyone else running a multiport BBS that they give serious consideration to the hardware/software set up described above. Copied by Hank Greeb, N8XX 02-Apr-89 -- 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/SWL/SCANNER BBS (1200/2400/PEP) 614-457-4227 ------------------------------ End of PACKET-RADIO Digest ****************************** 17-Apr-89 02:17:00-MDT,7659;000000000000 Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL> Date: Mon, 17 Apr 89 01:30:26 MDT From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL Subject: PACKET-RADIO Digest V89 #101 To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL PACKET-RADIO Digest Mon, 17 Apr 89 Volume 89 : Issue 101 Today's Topics: FCC's recognition of repeater coordination is a disaster--------------------------------------------------------- ------------- Date: Sun, 16 Apr 89 16:13:44 EST From: mgb@tecnet-clemson.arpa Subject: FCC's recognition of repeater coordination is a disaster Original posting: Apr 15 07:23 by: nuchat!splut!jay@uunet.uu.net (Jay "you ignorant splut!" Maynard) >We are in the process of extricating ourselves from a lawsuit now. It's >no fun. The plaintiff has, very successfully, stymied a number of our >actions for two years while the suit has dragged on. Lawsuits are >something to fear. And if someone uses the law to harass and constrict the people that are trying to see the big picture, then we should bow to that pressure and simply make no decisions? Is that what you are saying Jay? >I agree that we need to do something, but coming up with an answer that >is politically feasible is much tougher than simply saying "Bite the >bullet: like it or not, you're moving." - or worse: "...we can't move >you anywhere; you'll have to shut down." True, but the only answer I see you advocating is "do nothing, else we might get sued." Did you ever consider the fallout of a packet radio versus voice repeater war? Doing nothing could eventually lead to that, all the right ingredients are there. >None of them are objective, though. Objectivity is an absolute >requirement, or else the process will be widely ignored or sabotaged. >Your priorities sound reasonable - to me. They might not to someone >else, though, and that is the problem: they all involve a value >judgment. We cannot get in the business of value judgments. To be objective simply means to express the nature of reality as it is apart from personal feelings or objectives. In other words to avoid having a biased opinion. It DOES NOT mean that you can't make decisions. I have heard value judgments from you Jay in two articles now. You are making them by simply responding to the text of others while expressing your opinions. Your recommendations of doing nothing and ignoring packet radio is a value judgment in itself. What you are really saying (I think) is that coordinators can not make objective value judgments without fear of reprisal or of being ignored. So... they can't make decisions in the face of any form of conflict. The status quo must be maintained until a repeater war or a schism is formed between packet radio and voice repeaters. THEN when everything has gone to hell in a handbasket the coordinator can do something? >How about training for emergency communications? Far more emergency >traffic will be handled, at least for the foreseeable future, on voice >than will be on packet. I am not saying that packet's not a better way >to do it, in a purely technical sense; what I am saying is that it will >not get done that way, and the voice operators need to be trained. Far more emergency traffic will be handled on voice? Well I think that will depend very much on the situation involved. If you are talking about VHF and car accidents and short term emergencies, then I agree. But if you are talking about LONG term emergencies like a hurricane or other natural disaster I disagree. When you start talking about large VOLUMES of traffic where ACCURACY is required, packet radio as it is right now IS doing a better job. It will become even more viable.... assuming that its growth isn't overly restricted by limiting development for fear of law suits. Phil Karn writes: >>But you will note that I have not mentioned the one criteria that, until >>now, has been the only thing that most repeater councils seem to go on: >>who was on the air first. And Jay Maynard replies: >Despite the fact that that's often the only completely objective >criterion, and the only one that does not involve a value judgment. You mean it's the only one where you don't have to make a decision and show some leadership....correct? This is really what the issue is Jay. Phil Karn writes: >>No one expects a frequency coordinator to be all wise or to predict the >>future. I only expect him to use his best judgment for the benefit of >>the amateur service as a whole. And that should be adequate defense for >>any lawsuit. Jay Maynard replies: >Haw. Our lawyer disagrees with you. I tend to trust his opinion on the >subject a little more. Jay, I understand that this issue of a lawsuit has you really shook up. It is a scary thought and the mere idea that one amateur could do this to another is worse than any repeater war. I think you might send a letter to various magazines making everyone aware who is doing this. Just tell the world who this jerk is and what is his callsign. Peer pressure is not something to underestimate either.... it might even save you going to court. Not all of the amateurs in this world are worthy of the title and pointing out the miscreants within our fraternity should be high on the list of things to accomplish. But to let it influence our judgment and adversely affect the growth of a whole new mode is not to be espoused or advocated. Do you want the FCC to make all of the judgments for our future? They have proven to not really have our best interests at heart. If not them, then who else? If we are going to do it then there are going to be NUMEROUS objective value judgments being made all the time. To be a leader in anything you have to be willing to stand up and take the flack if and when it comes. Right now you are under the gun and are taking some "incoming". Please don't go down in flames and also please don't ask the rest of us to avoid ever making a tough decision based on the merits and values inherent to it simply because there are (expletive deleted) like the one that is suing your group around. I would like to leave you with a question. What would you do if a coordinated voice repeater owner decided to switch his system over to packet operation? He has a coordinated frequency that everyone is happy with correct? Are you going to tell him that he can run voice on these frequencies but not packet? I can think of a lot of possibilities here! If I want to get packet going on a duplex pair all I have to do is "buy out" a person or group that is already coordinated, or I could form a group and appoint a new coordinator. Boy doesn't that really boggle the mind! Think of the profits that could be made "selling" amateur frequencies to other amateurs! After all, the guy that got on there first with his repeater OWNS that frequency right? No? Well Jay, if he won't get off if you tell him to and then sues you if you try, then I'd say he owns that frequency... lock, stock, and barrel. ----------------------------------------------------------------- ------------ Mark Bitterlich : Morse code gets through when nothing else will. WA3JPY@WB4UOU : But then smoke signals don't even require a radio! mgb@tecnet-clemson.arpa : (Overheard at the Little Big Horn) ----------------------------------------------------------------- ------------- ------------------------------ End of PACKET-RADIO Digest ****************************** 18-Apr-89 02:23:47-MDT,8016;000000000000 Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL> Date: Tue, 18 Apr 89 01:30:33 MDT From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL Subject: PACKET-RADIO Digest V89 #102 To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL PACKET-RADIO Digest Tue, 18 Apr 89 Volume 89 : Issue 102 Today's Topics: AMPRNet (TCP/IP) Address Coordinators Frequency Coordination----------------------------------------------------- ----------------- Date: 17 Apr 89 16:01:01 GMT From: brian@ucsd.edu (Brian Kantor) Subject: AMPRNet (TCP/IP) Address Coordinators Here's a list of the people handing out IP addresses for the AMPRNet. Contact the one for your area to get one or more unique numbers for use when experimenting with ham radio packet TCP/IP. If there's no one for your area, try the closest one listed here, or contact me and I'll make you IT. Brian Kantor WB6CYT UC San Diego brian@ucsd.edu ---44.002 (no coord yet) (open) Calif: Sacramento 44.004 Andy Cromarty N6JLJ 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 Mike Horne KA7AXD Eastern Washington (state) 44.014 unassigned 44.016 Don Jacob WB5EKU Calif: Los Angeles - S F Valley 44.018 Rod Wertz WC6T Calif: San Bernardino 44.020 Bill Flynn AI0C Colorado: Northeast 44.022 John Stannard KL7JL Alaska 44.024 Clifford Neuman N1DMM Washington: Seattle 44.026 Ron Henderson WA7TAS Oregon 44.028 Don Adkins KD5QN Texas: Dallas 44.030 J Gary Bender WS5N New Mexico 44.032 Andy Freeborn N0CCZ 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 Iowa KC0OX Iowa 44.052 Gary Grebus K8LT New Hampshire 44.054 Jon Maguire N1CQE Vermont 44.056 Bob Clements K1BC Boston 44.058 unassigned 44.060 Howard Leadmon WB3FFV Maryland 44.062 Jim Dearras WA4ONG Virginia (not DC) 44.064 Phil Karn KA9Q New Jersey: northern 44.066 unassigned 44.068 Norm Sternberg W2JUP New York: Long Island 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 44.078 (no coord yet) Oklahoma 44.080 John Gayman WA3WBU Pennsylvania: Harrisburg 44.082 Seven Elwood N7GXP Montana 44.084 Bob Ludtke K9MWM Colorado: western 44.086 unassigned 44.088 Norm Sternberg W2JUP Connecticut 44.090 unassigned 44.092 Dan Frank W9NK Wisconsin, upper peninsula Michigan 44.094 Dan Frank W9NK Minnesota 44.096 Brian Lloyd WB6RQN 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 Gary Mitchell WB9TPG Kentucky 44.108 James Dugal N5KNX Louisiana: SW 44.110 unassigned 44.112 Bob Hoffman N3CVL Pennsylvania: Pittsburgh 44.114 unassigned 44.116 Tom Kloos WA7NJK Portland, OR 44.118 Jon Andrews WA2YVL Maine 44.120 unassigned 44.122 unassigned 44.124 David Dodell WB7TPY Arizona 44.126 unassigned # # 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 JR1EDE 44.130 Germany DL4TA 44.131 United Kingdom G3MRX,G6KVK 44.132 Indonesia YB1BG Robby Soebiakto 44.133 Spain (no coord yet) 44.134 Italy I2KFX 44.135 Canada VE3GYQ David Toth 44.136 Australia VK2ZXQ 44.137 Holland PA0GRI 44.138 Israel 4X6OJ 44.139 Finland OH2BJU 44.140 Sweden SM0RGV 44.141 Norway LA4JL Per Eotang 44.142 Switzerland HB9SFD 44.143 Austria (no coord yet) 44.144 Belgium ON7LE 44.145 Denmark OZ1EUI 44.146 Phillipines 44.147 New Zealand 44.148 Ecuador HC5K Ted 44.149 Hong Kong VS6EL 44.150 Yugoslavia YU3FK Iztok Saje 44.151 France 44.152 Venezuela OA4KO/YV5 Luis Suarez 44.153 Argentina LU7ABF Pedro Converso 44.154 Greece SV1IW Manos 44.193 Outer Space-AMSAT W3IWI Tom Clark ------------------------------ Date: Mon, 17 Apr 89 04:20 CDT From: <CJB8753%TAMSIGMA.BITNET@icsa.rice.edu> Subject: Frequency Coordination In PACKET-RADIO Digest V89 #96, Jay Maynard writes: >I obviously have a strong bias toward the coordination process, but the >undeniable fact is that we're much better off now than in the bad old >days. As we rediscovered in Dallas about three years ago, repeater wars >do nobody any good. The difference is that now, the FCC can and will >terminate one in short order, if one repeater is coordinated and the >other isn't (the commonest case). If both repeaters are coordinated, the FCC can not take quick and simple action and you are stuck. Coordination has not completely solved problems of interference. Repeaters have been coordinated and yet constantly interfere with each other! Some coordinators have been using pencil and paper until this year to keep track of what machines are operating where. This is no better than amateurs installing repeaters on a frequency of their choice. I have called a 'frequency coordinator' before and tried to work out an interference problem. He responded by saying something like, "You need to give me information on a particular action you would like to take. How can you expect me to go through these coordinations and help you? Since some of the repeater owners have agreed to coordinate on the condition that the location of their repeater not be disclosed, I can give you no information." So I just change my repeater frequency and see if it causes qrm? Not if I want to keep my license... >All of the repeater pairs have been issued in the Houston and >Dallas/Fort Worth areas for some time now. The coordination process >keeps the repeater bands usable, instead of allowing them to deteriorate >into a quagmire of heterodyning carriers. Well, that's great for Houston and Dallas, but the areas in between suffer. Since a 'zone' is considered completely full, spectrum that could be used on the border of two zones is wasted. >Reverting to the 1972-era standing would be a step backward, not a step >forward. If we didn't need it, we wouldn't have developed it. I agree, but let's improve the system instead of just yacking on our 'qrm-free' 2 meter repeaters. In PACKET-RADIO Digest V89 #98, Phil Karn and Jay Maynard write: >>If coordinators >>are just going to throw up their hands whenever a problem like this >>comes up, then I don't see how they are doing their jobs. Proclaiming a >>fear of lawsuits is a cop-out, pure and simple. >We are in the process of extricating ourselves from a lawsuit now. It's >no fun. The plaintiff has, very successfully, stymied a number of our >actions for two years while the suit has dragged on. Lawsuits are >something to fear. Allowing a regional coordinator to make himself permanently 'unavailable' (no telephone) is a cop-out. Requiring written correspondence to suggest ways to fix repeater qrm is nothing less. How is a person to alleviate interference if regional coordinators contact each other twice each year? Yes, this happened in the Dallas/Ft Worth zone of the Texas VHF/FM Society. Coordination may be better than no coordination, but it certainly could use some work. Charles Burnett AA5AV@W5AC (packet) CJB8753@TAMSIGMA (Bitnet) ------------------------------ End of PACKET-RADIO Digest ****************************** 18-Apr-89 03:03:54-MDT,11526;000000000000 Mail-From: KPETERSEN created at 18-Apr-89 02:55:42 Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL> Date: Tue, 18 Apr 89 02:55:41 MDT From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL Subject: PACKET-RADIO Digest V89 #103 To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL PACKET-RADIO Digest Tue, 18 Apr 89 Volume 89 : Issue 103 Today's Topics: KA-NODE listing for UK--------------------------------------------------------------- ------- Date: Mon, 17 Apr 89 12:45:09 BST From: J.Heaton%prime-a.central-services.umist.ac.uk@NSS.Cs.Ucl.AC.UK Subject: KA-NODE listing for UK LEGEND: Band: 0 - 144.675 Mhz 1 - Microwave 2 - 144 Mhz 3 - 3.5 or 7 Mhz 4 - 70 Mhz 5 - 14/21/28 Mhz 6 - 50 Mhz 7 - 430 Mhz Status: b - PBBS k - PERSONAL REPEATER TOTAL NUMBER OF TERMINALS LISTED: - 131 CALL SYSOP NAME BAND STATUS MUL LOCATION CTY G0ADW G0ADW PETE 0 2 IO81MI WESTON SUPER MARE AVON G0CJG G0CJG DAVID 2 b IO81QK BRISTOL AVON G0DUU G0DUU 0 2 7 b IO81QH NEAR BRISTOL AVON G1WRR G1WRR 2 IO81UJ BATH AVON G4FRO G4FRO GARRY 7 b IO81QL HENLEAZE BRISTOL AVON G4SDR G4SDR 0 2 7 b IO81RK HENGROVE BRISTOL AVON G4WRW G4WRW DAVE 2 b k IO81SM FRAMPTON COTTERELL AVON G4ZUX G4ZUX NICK 0 2 IO81MI WESTON SUPER MARE AVON G6EJF G6EJF 0 2 7 b IO81NK CLEVEDON AVON G8IMB G8IMB MARTIN 2 7 IO81RM STOKE GIFFORD AVON G8WAR G8WAR 0 2 b IO81MI WESTON SUPER MARE AVON G4GND G4GND 2 b IO92VC DUNTON BEDS G4PDF G4PDF 2 b k IO91RV HOUGHTON REGIS BEDS G8LCE G8LCE 0 2 b IO91SU CADDINGTON NR.LUTON BEDS G0HXN G0HXN DAVE 0 2 b k IO91OI CROWTHORNE NR.WOKING BERK G4AUC G4AUC 2 b IO91PJ BRACKNELL BERK G8AYC G8AYC NIGEL 0 2 b IO91HJ NEWBURY BERK G8XDS G8XDS 0 2 7 b IO91PP HAZLEMERE BUCK G1OSM G1OSM BRIAN 2 IO92UF ST.NEOTS CAMB G4XUN G4XUN 0 2 b IO92VN PETERBOROUGH CAMB G1MIL G1MIL PETER 2 b IO83SC CREWE CHES G4IRU G4IRU ROY 2 b IO83VH WILMSLOW CHES G3IFA G3IFA 0 2 b IO92GW ALLESTREE DERBY DERB G4AGE G4AGE 0 2 7 b IO93IH RENISHAW DERB G4KLX G4KLX JON 0 2 IO93FB WIRKSWORTH DERB G4NAD G4NAD RICHARD 2 7 k IO93FD MATLOCK DERB G4XMH G4XMH MICK 2 b k IO92IV LONG EATON DERB G6YAL G6YAL PHIL 1 IO93HC ALFRETON DERB G8XXD G8XXD KEITH 0 2 b k IO93EC MIDDLETON NR.MATLOCK DERB G1DII G1DII MAJOR 2 IO80KQ BEER DEVN G7AGM G7AGM PETER 2 b IO80FR EXETER DEVN G1VHG G1VHG 2 7 b k IO90BS KINSON BOURNEMOUTH DORS G1YHE G1YHE CURLY 2 b IO90BT NEAR BOURNEMOUTH DORS G0CPR G0CPR JOHN 2 b k JO00BS SEAFORD E-S G0FUV G0FUV 0 2 b JO01DA MAYFIELD E-S G0KTS G0KTS JACK 0 2 b k JO00DX HEATHFIELD E-S G1VJW G1VJW 2 b JO00AS NEWHAVEN E-S G4MVN G4MVN TOM 0 2 b k JO00DS EASTBOURNE E-S G7AFZ G7AFZ 2 b k IO90VU HOVE E-S EI7CR EI7CR MIKE 12 b IO53IC MURROUGH CO.GALWAY EIRE G1IBP G1IBP ALLAN 0 2 b JO01FR CHELMSFORD ESSX G1LYV G1LYV DON 0 2 7 b JO01GP WICKFORD BILLERICAY ESSX G4DIW G4DIW COLIN 2 b JO01KW NEAR COLCHESTER ESSX G4ZFL G4ZFL BERNARD 0 2 7 b JO01FS CHELMSFORD ESSX G4ZPE G4ZPE MIKE 0 2 7 b k JO01GP RETTENDON CHELMSFORD ESSX G6FCL G6FCL JIM 0 2 7 b JO01FN VANGE BASILDON ESSX G6NHK G6NHK 2 b JO02DA SAFFRON WALDEN ESSX G8NBR G8NBR JIM 7 b k JO01FN LAINDON BASILDON ESSX G0DCP G0DCP 2 5 b k IO91WM HIGHBURY G-L G1ILW G1ILW EDDIE 2 b IO83VL MANCHESTER G-M G1YYH G1YYH JOHN 2 b IO83SN BOLTON G-M G3WEC G3WEC ALAN 0 2 7 b IO83WJ OFFERTON STOCKPORT G-M G7BKL G7BKL BRIAN 0 2 b IO83RN WESTHOUGHTON G-M G8ZLY G8ZLY 0 2 b IO83WK REDDISH STOCKPORT G-M G3ILO G3ILO STEVE 0 2 7 b k IO81VQ NAILSWORTH GLOS G3RPD G3RPD GRAHAM 2 b IO81XR SAPPERTON GLOS G4HQX G4HQX PETER 0 2 7 b k IO81TQ DURSLEY GLOS G4VXE G4VXE TIM 2 b IO81WV CHELTENHAM GLOS G6SQT G6SQT CLIVE 0 2 7 b k IO81VR STROUD GLOS GM0CQV GM0CQV BRENDAN 2 IO87WC ABERDEEN GRAM GM3BSQ GM3BSQ 2 IO87TB DURRIS NR.ABERDEEN GRAM GW1XUB GW1XUB 2 IO81LP CWMBRAN GWEN G0DAZ G0DAZ COLIN 0 2 7 IO82VL WORCESTER H-W G4PCM G4PCM 2 7 b k IO92BC MIDDLE LITTLETON H-W G0AMO G0AMO 0 2 b k IO91FF CHARLTON NR.ANDOVER HANT G0HLX G0HLX NICK 0 2 b IO91OI YATELEY HANT G0HOQ G0HOQ MIKE 0 2 b IO91OI YATELEY HANT G1JAR G1JAR LLOYD 0 2 4 6 b IO90LT SOUTHSEA HANT G1UWZ G1UWZ PAUL 0 2 b k IO91PF ALDERSHOT HANT G4HCL G4HCL CHRIS 2 b IO90HX CHANDLERS FORD HANT G4TMI G4TMI 0 2 56 b k IO90ER NEW MILTON HANT G4XNA G4XNA KEITH 0 2 b IO90FS LYMINGTON HANT G6AOH G6AOH RICHARD 0 2 b k IO91KI PAMBER HEATH B'STOKE HANT G8GYS G8GYS PETER 0 2 b IO91FE ANNA VALLEY ANDOVER HANT G1BWT G1BWT KEVIN 0 2 k IO91RR BOVINGDON NR.WATFORD HERT G1JKF G1JKF NIGEL 2 b IO91XW BUNTINGFORD HERT G1YFL G1YFL PETER 2 b k IO91VT WELWYN HERT G3MSW G3MSW KEN 0 2 b IO91UT HARPENDON HERT GJ4YAD GJ4YAD PETER 2 b IN89VE ST.BRELADE JERS GJ6BUK GJ6BUK PHIL 0 2 b IN89WF TRINITY JERS G0AUW G0AUW 0 2 b JO01MI WHITSTABLE KENT G0CPV G0CPV STEVE 2 b JO01QI RAMSGATE KENT G0CSF G0CSF 0 2 b JO01DK DARENTH DARTFORD KENT G0DQI G0DQI 2 b JO01QE KINGSDOWN NEAR DEAL KENT G0FAK G0FAK KEN 2 b k JO01QF DEAL KENT G3EMU G3EMU IVAN 2 b k JO01NG CANTERBURY KENT G4YVQ G4YVQ 2 b IO83LS BLACKPOOL LANC G1JBJ G1JBJ 0 2 b IO92PQ OAKHAM LEIC G3STG G3STG GEOFF 2 b k IO92MS NEAR MELTON MOWBRAY LEIC G4OSJ G4OSJ PAUL 0 2 b k IO92PO UPPINGHAM NR.OAKHAM LEIC G6LTR G6LTR JIM 2 b IO92KP LEICESTER LEIC G0FLG G0FLG BARRY 2 b IO93TB RUSKINGTON LINC G4OAR G4OAR NEIL 2 k IO83JI THE WIRRAL MERS G1OQQ G1OQQ HAROLD 2 b IO94FD RIPON N-Y G4BKI G4BKI PAUL 2 b IO92MD TOWCESTER NHAN G4CEY G4CEY JOHN 2 b k IO92TM WARMINGTON NHAN G0BMS G0BMS IAN 2 b JO02ES KINGS LYNN NORF G1LOK G1LOK PAUL 2 b JO02ES KINGS LYNN NORF G3LDI G3LDI ROGER 2 JO02ON E.CARLETON NORWICH NORF G4RQN G4RQN NEIL 2 b JO02ES KINGS LYNN NORF G1EUP G1EUP 0 2 b IO93JA BULWELL NOTT G6CUK G6CUK ANDY 0 2 b IO93JD MANSFIELD NOTT G1BJE G1BJE TONY 0 2 b k IO92IA KINGS SUTTON BANBURY OXON G4OCO G4OCO 0 2 b k IO92HB BANBURY OXON GW0GIH GW0GIH JOHN 0 2 5 b k IO81HW BRECON POWS GW4URC GW4URC IAN 0 2 b IO81JL CARDIFF S-G G0CXP G0CXP KEITH 2 b IO93JI SOUTH ANSTON S-Y G1BRV G1BRV 0 2 b IO93GJ SHEFFIELD S-Y G1OPS G1OPS 0 2 b IO93HM WOMBWELL BARNSLEY S-Y G4TQT G4TQT 0 2 b IO93GL BURNCROSS SHEFFIELD S-Y G0DQW G0DQW CHRIS 2 5 IO82PR SHREWSBURY SHRP G0EBD G0EBD MALCOLM 2 b IO82PQ SHREWSBURY SHRP G1DIL G1DIL ANDY 2 7 b IO82TK HIGHLEY SHRP G3VZG G3VZG RICHARD 7 IO82PQ SHREWSBURY SHRP G3XEF G3XEF MIKE 2 b IO82SQ TELFORD SHRP G1SHJ G1SHJ DAVE 2 b k IO83VB KIDSGROVE STAF G3TJP G3TJP DAVE 2 b IO82VX NEWCASTLE-U-LYME STAF GM1ZQM GM4AUP IAN 0 2 STRD G0JVU G0JVU NEVILLE 2 b JO01QX FELIXSTOWE SUFF G0HWO G0HWO JOHN 2 b k IO91VF REIGATE SURR GW4KAW GW4KAW BRIAN 2 IO81AO SWANSEA W-G GW4UCK GW4UCK 2 IO71XP NEAR SWANSEA W-G G1PMA G1PMA DAVE 2 b IO90RW PULBOROUGH W-S G7AVG G7AVG 2 b IO91XD EAST GRINSTEAD W-S G0GYA G0GYA MICK 0 2 5 b IO93IR CASTLEFORD W-Y G3WNR G3WNR 0 2 5 b k IO93FU LEEDS W-Y G4KDU G4KDU GRAHAM 2 b IO83WR TODMORDEN W-Y G8IC G8IC MIKE 2 45 b IO83WR TODMORDEN W-Y G8NML G8NML 0 2 7 b IO93BS QUEENSBURY BRADFORD W-Y G0DGX G0DGX MALCOLM 2 b k IO92DM COLESHILL WARK G0BEQ G0BEQ ANDY 2 5 b IO91DN SWINDON WILT ------------------------------ End of PACKET-RADIO Digest ****************************** 19-Apr-89 02:27:37-MDT,4256;000000000000 Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL> Date: Wed, 19 Apr 89 01:31:02 MDT From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL Subject: PACKET-RADIO Digest V89 #104 To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL PACKET-RADIO Digest Wed, 19 Apr 89 Volume 89 : Issue 104 Today's Topics: BBS lists by state PACKET-RADIO Digest V89 #96-------------------------------------------------------------- -------- Date: 17 Apr 89 15:03:35 GMT From: oliveb!pyramid!prls!philabs!briar.philips.com!rfc@apple.com (Robert Casey;6282;3.57;$0201) Subject: BBS lists by state copied from packet radio (by wa2ise): Msg# TSP Size Read To @ BBS From 27615 BN 2289 3 SYSOP WA2PVV Subj: BBS Lists By State Hello, Over the past few weeks, I have seen many requests for BBS lists from various stations pass through this system. If you need a list for a specific state, I am willing to send that state out to your "home" BBS as a bulletin which then the sysop can put in a directory or all his users to download. These lists are for the most part up to date and contain NTS, ZIP CODE, as well as BBS information for that state. To request a list just send a message to me using the following format. EXAMPLE: SP WA2PVV @ WA2PVV <ENTER KEY>------- LIST NY @ WA2UMX <ENTER KEY> ^Z or /EX <ENTER KEY> In the above example above a BBS list for New York was requested and it was to be sent to the WA2UMX BBS in Saratoga Springs N.Y. The information contained in the lists is derived from both the K4NGC & W9ZRX databases as well as WP section of the W0RLI BBS software. There is no need to include any text in the request as the header will tell where the list is wanted and what state is being requested. -------------------------------------------------- --------> PLEASE DO NOT REQUEST MORE THAN ONE LIST AT A TIME -------------------------------------------------Note To Sysops: All requests will be answered as bulletins, addressed to "STATES" and will carry the BID "LISTxx" (xx = two letter state designator). The routing will depend on where the list is to be sent. ie. NYNET for New York BBS's. Updates to these lists will be sent as they are compiled. All updates will be sent out SP SYSOP and will carry a normal message number BID. It is suggested, that a separate directory be installed for your users to download these files from. Also, they make excellent forwarding lists if you do not already have a similar setup. 73 Bill ------------------------------ Date: 19 Apr 89 05:44:26 GMT From: n3dmc!johnl@uunet.uu.net (John Limpert) Subject: PACKET-RADIO Digest V89 #96 In article <8904180838.AA24002@ucbvax.Berkeley.EDU> BIW104@URIACC.BITNET (Chris Tate) writes: >HOWEVER, how can a person or AR club be expected to shut down their rather >large investment because of prior mistakes in bandplans! Everyone knows >that they can't be moved. So what is a club or person supposed to do? >Pack it in because of packet? Why can't we move the less active repeaters to a smaller set of frequencies and require the use of PL (CTCSS) decoders on the repeater receivers? The same could be done with control links and other low activity frequency allocations. Many of the new rigs have PL encoders as standard or optional equipment. PL encoders can be added to most older rigs without much effort. Every time I tune thru the 2 meter, 220 and 440 bands I am amazed by the low levels of usage compared to what has been 'allocated', and I am located in a major metropolitan area. As far as I am concerned, repeater owners (and anyone else) do not have unrestricted rights to a frequency that they aren't using in an efficient manner. Many of the local repeaters could be put on a single frequency pair with PL and the frequency pair would still be underutilized. -- John A. Limpert UUCP: johnl@n3dmc.UUCP, johnl@n3dmc.UU.NET, uunet!n3dmc!johnl ------------------------------ End of PACKET-RADIO Digest ****************************** 20-Apr-89 01:57:52-MDT,9612;000000000000 Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL> Date: Thu, 20 Apr 89 01:30:58 MDT From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL Subject: PACKET-RADIO Digest V89 #105 To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL PACKET-RADIO Digest Thu, 20 Apr 89 Volume 89 : Issue 105 Today's Topics: DIGIPAC. FCC's recognition of repeater coordination is a disaster Private Repeaters rec.ham-radio.packet--------------------------------------------- ------------------------- Date: 19 Apr 89 09:23 GMT From: Karl Georg Schjetne <schjetne%vax.runit.unit.uninett%NORUNIX.BITNET@CUNYVM.CUNY.EDU> Subject: DIGIPAC. A couple of years ago I bought the DIGIPAC packet terminal program from Kalt in Alaska. The system works well in most respects. The printer function, however, does not work at all, it only gives me strange error messages. I have tried the system on an XT and on a 386, with my Proprinter. The company does not answer my letters, and as their ads have stopped showing up in QST and HR, I guess they are out of operation. If you have had the same problem, and have the cure for it, please assist me - I would like to continue using DIGIPAC I would also appreciate information on the COM1-COM8 version of DIGIPAC. 73 de Karl Georg Schjetne, LA8GE, Steinhaugen 29, N-7049 Trondheim, NORWAY. <schjetne@vax.runit.unit.uninett> LA8GE @ LA8GE ------------------------------ Date: 14 Apr 89 19:19:16 GMT From: schlep.dec.com!jfcl.dec.com!frg@decvax.dec.com (Fred R. Goldstein) Subject: FCC's recognition of repeater coordination is a disaster I'm not going to >-in Jay's reply since I don't want to clutter up net.bandwidth. Summary so far: Fred> Repeater coordination enforcement locks up the bands in their mid-1970's state, preventing digital and other users from gaining access to frequencies. Suggestions include allowing a return to the days of unregulated repeaters (even if a few wars occur) and having coordinators adopt priorities, such as "high usage" and "special feature", making others double-up as the case need be. Jay> Coordinators are accepted because they don't make judgements. There's no one value judgement, so coordinators simply leave everyone intact. The alternative leads to repeater wars, which would make the bands unusable. (I hope I got your side right in 3 1/2 lines, Jay!) Now, I fully appreciate Jay's quandary. Being a judge is no fun either, since you're going to make somebody unhappy. But the status quo has the specific effect of making exactly ONE detail worth more than all others put together: LONGEVITY. He who has been here the longest, has rights over all the others. Now that concept has a lot of precedent in American law. Arizona water rights, for example, are based on date-of-claim. So a lettuce ranch in the desert that got water rights in 1868 gets absolute priority over a city that bought 1878 water rights. If the water runs low (and it does), then a certain cutoff date is used, and all newer claims are rejected. Phoenix and Scottsdale have grown by buying up old ranches for their water rights! Here, we have repeater rights. If a hundred packeteers want a repeater pair, they could of course get some voice repeater (existing use) to be turned over to them, right? (I sure hope the system doesn't say "VOICE ONLY FOREVER"!) Now, what's going to get some existing allocation-holder to give up his repeater pair? Somebody may have a little machine on his garage, used by 3 guys, two of whom don't live there anymore. But he now owns a RESOURCE, a repeater pair. So the packeteers can BUY him out, right? Just like Arizona and the water rights. Of course, if this FCC policy makes "voluntary" coordination into a saleable resource, then people aren't going to shut off repeaters UNTIL somebody antes up! Otherwise they'd be throwing away money. Broadcast licenses are auctioned off (brokered, actually) like this; a station may be a financial disaster, but it doesn't "go dark" and return its license; it sells out. Only if there are just too darn many stations in a market will one go dark. (BTW, I hear this is about to happen to the CBS affiliate in New Hampsire... aside) Repeater wars didn't cause a lot of grief where I lived (NY area then New England). There were some nasty ones, when two BIG repeaters claimed a single frequency, but small-repeater fights were just noise. I posit that while a few pairs might be made temporarily unusable due to "deregulation" (making coordination voluntary again), the overall amount of useful communication taking place on the band as a whole will be increased. Innovation will pay off more than some collisions will cost. I don't want coordinators to order anyone offf the air. Repeaters can share frequencies. Voice machines can use PL, anti-PL, bursts, directional antennas, etc.; those are quite common in the NY area where co-channel spacing can be 30 miles or so for small repeaters. Digital machnes have CSMA techniques. You have to take TWO low priority machines and give them ONE frequency, not just knock an exisitng user off the air. Or you can let the marketplace do it, just as the SSB/AM conflict led to an eventually orderly transition. fred k1io ------------------------------ Date: 19 Apr 89 13:10:54 GMT From: brian@ucsd.edu (Brian Kantor) Subject: Private Repeaters John Limpert asks why not move many of the private repeaters to the same channel and use separate PL (subaudible tone squelch) to isolate them from each other. The question shows a basic lack of understanding. The purpose of a private repeater is usually NOT to allow each person to be a repeater baron with his own machine - it is to provide a secluded channel where the USERS of the repeater don't have to listen to the pitter-patter of tiny minds that is so pervasive on the public repeaters. To isolate the users requires that EVERY repeater USER have PL in his receiver, which is simply not very practical in today's FM world. A dozen or so years ago when a large portion of the FM radios on the air were commercial FM surplus (Motorola, GE, RCA, etc), this was a practical thing since ALL commercial radios made could easily be equipped with PL decode - 99% were, since that's the way they were used in commercial service. But few of today's rice-rockets have PL decode capability - in most, the PL encode is an option. And many of the available PL decoders require too much or too long a tone - they're simply not well designed. Yes, a community of repeater users separated by PL tones can be done: it's common practice in commercial service. But most hams are too cheap to buy a radio with good PL decode capability (so few are made) and even fewer are technically competent and willing to install it aftermarket. Additionally, at least around here in SoCal, most public repeaters have damn near 100% duty cycle. The only way to talk to someone on a repeater is to "break" - to interrupt another conversation in progress. My involvement with 2M (and up!) FM stretches back to 1970 (before the ARRL invented it [ahem]) and it had always been the practice to keep conversations concise enough that there was little congestion - and it was consequently the case that you only broke in if it was very urgent. Today's repeaters are mostly populated by logarrheic old farts and breaking in (or mailing them a letter bomb) is the only way to get a word in edgewise. - Brian, WB6CYT ------------------------------ Date: 20 Apr 89 03:35:46 GMT From: pikes!udenva!awinterb@boulder.colorado.edu (Mr. Poot) Subject: rec.ham-radio.packet Problem: A friend is starting up a resort in southern Mexico. The telephone service between there and Denver is unreliable. He needs reliable communication for business and emergencies. "Reliable" is defined as 80% or greater chance of establishing a communications link at any given time with intelligible quality. Type of Business Traffic: The content of these communications will be reservations for guests, and ordering of mechanical equipment for recreational gear. On the average there is expected to be 1 hour of communication per day in voice mode, shorter if in a typewritten mode is used that allows one to type the message ahead of time. Mode of Communication Desired: Voice or data (e.g., error detection and re-send). HF, or VHF/UHF satellite relay. A system whereby messages could be left in Denver would be acceptable. Questions: (1) Would the business nature of this communications preclude the use of amateur radio? (2) If commercial radio must be used, what books are availble to help him find what's needed (e.g., type of licenses, equipment to use, etc.)? Please reply to me, and I'll forward your responses to him. Your help is greatly appreciated. Art Winterbauer ...!ncar!udenva!awinterb or according to rumor awinterb@eos.du.edu ------------------------------ End of PACKET-RADIO Digest ****************************** 21-Apr-89 02:40:53-MDT,16407;000000000000 Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL> Date: Fri, 21 Apr 89 01:30:38 MDT From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL Subject: PACKET-RADIO Digest V89 #106 To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL PACKET-RADIO Digest Fri, 21 Apr 89 Volume 89 : Issue 106 Today's Topics: GATEWAY 14-Apr-89 P---------------------------------------------------------------- ------ Date: 21 Apr 89 00:40:15 GMT From: osu-cis!n8emr!gws@tut.cis.ohio-state.edu (Gary Sanders) Subject: GATEWAY 14-Apr-89 P ============================================================== | Relayed from packet radio via | | N8EMR's Ham BBS, 614-457-4227 (1200/2400/19.2 telebit,8N1) | ============================================================== Gateway: The ARRL Packet Radio Newsletter - April 14, 1989 - Part 1 of 4 Stan Horzepa, WA1LOU, Editor - Volume 5, Number 15 PACKET RADIO PLANNED FOR SHUTTLE FLIGHT An Amateur Radio station is scheduled to fly aboard the space shuttle in March 1990. Approval for the inclusion of the Space Shuttle Amateur Radio Experiment (SAREX) on the secondary payload list of flight STS 35 has been received from NASA headquarters. Ron Parise, WA4SIR, a payload specialist for the ASTRO 1 payload to be carried on that flight, will operate the station in the orbiting shuttle. Representatives of ARRL and SAREX, co-sponsors, The Radio Amateur Satellite Corporation (AMSAT) stated that they learned of the approval at a meeting with NASA officials held on March 14 at the Johnson Space Center in Houston. WA4SIR plans to communicate with Amateur Radio operators worldwide using voice and video communications, as well as packet radio. The orbit of the shuttle will permit amateurs located between approximately 46 degrees North and 46 degrees South latitude to communicate directly with the spacecraft. The SAREX transmissions from space will be such that a standard scanner radio will be able to receive them. The approval for SAREX operation is contingent on the Johnson Space Center's final approval of the SAREX hardware and operations plan and on priorities concerning the secondary payloads for the STS 35 flight. PACKET-RADIO CONFERENCE AT TRENTON COMPUTER FESTIVAL An all-day packet-radio conference will be held at the 14th annual Trenton (New Jersey) Computer Festival on Saturday, April 22, 1989, from approximately 10 AM to 4 PM in Nursing Building, Rooms 108/111. The conference will include discussions concerning packet radio, in general, as well as discussions on specific topics, such as TCP/IP. In addition to the packet-radio conference, a forum on "Computers in Amateur Radio" will be presented Sunday at 11:45 AM in Recreation Center E. The Trenton Computer Festival is a two-day event (April 22-23) held on the campus of Trenton State College. For more information, write to TCF '89, Trenton State College, Hillwood Lakes, CN4700, Trenton, NJ 08650-4700 or call 201-549-7538. DAYTON HAMVENTION PACKET-RADIO EVENTS The Dayton HamVention is scheduled for April 28-30 and there is going to be a number of packet-radio events for those in attendance to enjoy. FORUM: On Friday, a packet-radio forum will be conducted with Bob Neben, K9BL, as moderator. A wide variety of topics are planned for discussion. KA9Q TO BE HONORED: On Saturday evening, Phil Karn, KA9Q, "the father of packet-radio TCP/IP," will receive the Special Achievement Award at the annual Dayton Amateur Radio Association (DARA) banquet. The award is sponsored by the DARA (which also sponsors the HamVention) in recognition of individuals who have made significant contributions to the Amateur Radio Service. TAPR BOOTH: Throughout the HamVention, TAPR (Tucson Amateur Packet Radio) will be manning a booth to display the latest in packet-radio developments including a kit that upgrades the TNC 1 to a TNC 2 (see Gateway, Volume 5, Number 10). Joining TAPR at its booth will be the Texas Packet Radio Society (TPRS), which will have a limited number of TexNet kits available. TexNet NCP boards, documentation and parts (excluding RAM and three DB-type connectors) will be on sale for $200 [users will have to either burn their own firmware or buy a high and low speed clock recovery EPROM for the 1200-and 9600-bit/s modems. EPROMs will be available for $10 (the firmware images may be downloaded from CompuServe's HamNet). Modem kits for 9600 and 1200 bit/s will also be available.] In addition, an operational TexNet node will be on display and TexNet and TPRS information and publications will be available. from Greg Jones, WD5IVD DIRECTORY SERVICE PROPOSAL For the last several years packet-radio system software developers and users in the Amateur Radio Service have been experimenting with simple directory servers. These usually provide call book and/or "home PBBS" data through local transactions or a remote mail interface. These systems include WD6CMU's "WP," the W0RLI server and the WA4ONG call- book servers. The user base has expanded and with it the interests and associated information needs. Many activities would be supported if a directory server contained information on network addresses, frequencies, electronic mail addresses in forms other than what is currently used by packet-radio BBSs and possibly even organizational data. Organizational data might allow mail to be directed to "ARRL Hudson Division Director" or "ARRL Northern New Jersey Section Manager". The objective of this discussion is to facilitate interoperation between directory systems which support the advanced capabilities required by this evolving environment. In order to determine what specific steps need to be taken to produce these systems, some basic questions need to be addressed. The first deals with directory data elements. The directory data elements may vary from system to system, but some common specification is required including: 1. The format of individual data elements. 2. A minimal subset of data elements that must be selected and supported on all systems. 3. The use of aliases for some data elements must be permitted and defined. 4. Relationship(s) of the data elements must be defined. 5. A mechanism to control access to a data element and its value is needed. The second question deals with functional requirements of the systems. Each item may be broken up into several items and then either fully or partially supported. 1. There are operations which may be used by users and/or systems. These operations may be invoked with parameters arranged as a filter. Filter constructs such as "equal to xxx" or "greater/less than xxx" are provided. Several of these constructs can be used to qualify an operation. * Basic operations should include: Read - one or more attributes of a particular entry. Compare - one or more attributes of a particular entry. List - of entries subordinate to the entry selected. Search - of the directory based on selected filter attributes. Abandon - a previously invoked request of the directory. * Advanced operations should include: Add - an entry to the directory. Remove - an entry from the directory. Modify Entry - attributes and/or attribute values. Modify Name - of an entry in the directory. * Results of these operations can come in one of four ways: Complete Results - in which case the request is fully satisfied. Partial Results - in which case the request is satisfied without an indication of possible further action. Referred Results - in which case the request is satisfied with an indication of possible further action. Errors - in which case something was wrong with the semantics of the request. The operations may be concatenated together to produce a specific request. An example would be a wild-card search of all PBBSs in New Jersey with an indication that the resultant response include call signs, network addresses and a list of supported distribution lists. This would use the "Search" and "Read" operations. 2. Proposed user semantics should be defined solely for the purposes of understanding specific requests of the directory. We should not try to impose a set of semantics on a particular developer or user community. 3. Remote or local use for each of the functions should be defined. 4. Automatic referral of requests to another system(s) supporting data elements requested, but not available on the receiving system. 5. Some mechanism is needed for transport of remote requests - any of the standard mail formats perhaps? 6. For remote use of advanced operations (at least), we will need a method for authenticating the user and/or message. Summary Now let us get practical for a moment. First, the systems you have may already do some of these functions. Second, the system outlined above is complex to implement and probably unrealistic to expect in the short term. I am asking that we work toward building interoperable systems by doing a bit of up-front, collective high- level design. This will provide developers with a common "blueprint" for directory system implementation. From this blueprint, we will be able to identify additional functions and data elements. DIRECTORY SERVICE PROPOSAL (Continued from previous page) Appendix A This section outlines a proposed set of directory elements which might be supported by a directory system. This directory system would provide support for the following services: 1. Standard packet-radio BBS mail routing ("WP"-type). 2. Domain-based mail routing for X.400 and Internet systems. 3. Network routing for OSI systems based on the Network Service Access Point Identifier (NSAP-ID). 4. Network routing for DoD Internet systems. 5. NET/ROM or other network node. 6. Organizational Role Alias for ARRL Officials so that mail can be directed to a Director, Section Manager, etc. 7. Organizational Role Alias for officials of other organizations. 8. Organizational entries to support referral of inquiries to organizational directory databases. 9. Postal Address look-up. There will be directory entries for people, organizations, devices and applications. In order to get the crew thinking about possible elements, I have created a sample set of data elements for a directory entry of a "Person" that are outlined below: ENTRY ::= Person POSSIBLE SUPERIORS{ Top Country Organization } MUST CONTAIN{ Common Name (Amateur Call Sign) Begin Time DEFAULT (Time of Entry) End Time DEFAULT NULL } MAY CONTAIN{ Amateur Radio Specific Attributes CONTAINS{ Surname Given Name Nickname Message Handling Attribute Set CONTAINS{ Home PBBS X.400 Address Internet Address (SMTP) } OSI Domain NSAP-ID Internet Domain Internet Address Node Name Organizational Role CONTAINS{ Organization Name Organizational Unit Title } } Locale Attribute Set CONTAINS{ Street Address Locality Name State/Province Name } Postal Address Set CONTAINS{ Physical Delivery Office Name Postal Address Post Office Box Street Address Postal Code } Telecommunications Address Set CONTAINS{ Telephone Number Facsimile Telephone Number X.121 Address } } from J. Gordon Beattie, Jr., N2DSY The Radio Amateur Telecommunications Society OPINION: DIGITS, PACKET, CODE-FREE LICENSES AND HERESY As a proponent for the expansion and growth of packet radio from the beginning (1983), I was suddenly struck by a rightful thought during an animated discussion on code-free licensing. We were talking about the need for more amateurs and the thoughts a few years ago of a digital codeless license. Having just had a SYSOPs meeting where participants wanted more frequencies on 6 meters, 2 meters, 220 and 440, I suddenly realized that digital communications can grow without bound and the growth is not dependent on the number of amateurs, but simply follows Parkinson's law. No matter what bandwidth is available for digital communications, it will be filled! For voice communications, this is not the case. Two people talking to each other using 3 kHz of bandwidth can say only so much. Unless one of them decides to read the encyclopedia, eventually they have to eat, sleep and take a rest. Two Digit-Twidgets (DTs) with their PCs, however, can use a 45-baud channel to carry on a similar discussion keyboard-to-keyboard, 1200 baud to send lengthy messages or 9600 baud to routinely send files. When we give them 56,000-bit/s, they will swap disks on the air and with a T1 carrier, they will exchange updated world wide call books daily. These two guys will fill the available bandwidth and never get tired! All they need to do is glance at the PC occasionally to see how it is doing. As a result, these two DTs have allowed no room for the needed growth in the amateur fraternity. For the first time, I can see a need to establish clear boundaries for digital communications or we may see the end of Amateur Radio as we know it. Our use of 1200 baud in a 20-kHz channel is deplorable, but unless someone limits us somehow, we will not have the incentive to more efficiently use the spectrum. DTs will simply move to another frequency. In our area, the local coordinating group has graciously set aside 15 frequencies on 2 meters for packet radio. With this combined potential of over 300,000 bit/s, we still see packet-radio activity on simplex FM voice frequencies. Furthermore, a number of voice operators can make sense out of a net with multiple listeners gaining valuable information, while one person is talking. Packet radio, conversely, is usually one-to-one. Sure, the monitor mode allows you to see much of what goes by and each person monitoring later logs on to the PBBS to read the same message in order to get a clean copy. As a result, voice nets have the potential to pass N units of traffic using N units of information, whereas packet-radio traffic uses N x N units of information to pass the same traffic. As we ponder these matters and how we attract more individuals into the amateur ranks, we must determine the required bandwidth to support the community of users in the human-readable form (ie, voice) and protect spectrum for that purpose. I know this is heresy and a great step backwards, but we must determine how far digital communications should be allowed to go before we seriously degrade our ability to use voice communications and other modes. Allowing 10% for packet radio is probably too small, but 50% is probably too large. What is the right mix of digital versus other modes on our precious spectrum real estate? by Bob Bruninga, WB4APR GATEWAY CONTRIBUTIONS Submissions for publication in Gateway are welcome. You may submit material via the US mail to: Gateway Stan Horzepa, WA1LOU 75 Kreger Drive Wolcott, CT 06716-2702 or electronically, via CompuServe to user ID 70645,247. Via telephone, your editor can be reached on evenings and weekends at 203- 879-1348 and he can switch a modem on line to receive text at 300, 1200 or 2400 bit/s. The deadline for each issue of Gateway is the Saturday preceding the issue date (which is typically a Friday). REPRODUCTION OF GATEWAY MATERIAL Material may be excerpted from Gateway without prior permission, provided that the original contributor is credited and Gateway is identified as the source. ------------------------------ End of PACKET-RADIO Digest ****************************** 23-Apr-89 02:38:11-MDT,949;000000000000 Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL> Date: Sun, 23 Apr 89 01:30:25 MDT From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL Subject: PACKET-RADIO Digest V89 #107 To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL PACKET-RADIO Digest Sun, 23 Apr 89 Volume 89 : Issue 107 Today's Topics: SMTP server for W0RLI?----------------------------------------------------------- ----------- Date: 23 Apr 89 02:22:00 GMT From: silver!barkeyp@iuvax.cs.indiana.edu Subject: SMTP server for W0RLI? Does anyone know if the source code for the SMTP server written for the W0RLI BBS program version 10.xx is available anywhere for anonymous FTP? Thanks. -- Pat Barkey WA8YVR @ K9IU packet barkeyp@silver.bacs.indiana.edu internet ------------------------------ End of PACKET-RADIO Digest ****************************** 23-Apr-89 11:58:34-MDT,19775;000000000000 Mail-From: KPETERSEN created at 23-Apr-89 11:46:19 Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL> Date: Sun, 23 Apr 89 11:46:18 MDT From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL Subject: PACKET-RADIO Digest V89 #108 To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL PACKET-RADIO Digest Sun, 23 Apr 89 Volume 89 : Issue 108 Today's Topics: FCC's recognition of repeater coordination is a disaster Frequency Coordination PACKET-RADIO Digest V89 #96-------------------------------------------------------------- -------- Date: 23 Apr 89 03:24:27 GMT From: pitstop!texsun!texbell!uhnix1!moray!splut!jay@sun.com (Jay "you ignorant splut!" Maynard) Subject: FCC's recognition of repeater coordination is a disaster In article <8904162113.AA21308@tecnet-clemson.arpa> mgb@TECNET-CLEMSON.ARPA writes: >Original posting: Apr 15 07:23 by: >nuchat!splut!jay@uunet.uu.net (Jay "you ignorant splut!" Maynard) >>Lawsuits are something to fear. >And if someone uses the law to harass and constrict the people that are >trying to see the big picture, then we should bow to that pressure and >simply make no decisions? Is that what you are saying Jay? #include <complaint-about-overly-litigious-society> I'm not saying that we should make no decisions. I am saying that we must realistically look at what is the likely outcome of the decisions, and it's dumb to make a decision which will 1) be roundly ignored, and 2) provoke lawsuits which seek to reverse it. >True, but the only answer I see you advocating is "do nothing, else we >might get sued." Did you ever consider the fallout of a packet radio >versus voice repeater war? Doing nothing could eventually lead to that, >all the right ingredients are there. So far, all I've heard is "Cut down on the voice repeaters. Move some of them to the same frequencies as others, regardless of how much interference will result; tell others to get off the air." I claim that such an approach will not work, and will result in the complete breakdown of the frequency coordination process. >To be objective simply means to express the nature of reality as it is >apart from personal feelings or objectives. In other words to avoid >having a biased opinion. It DOES NOT mean that you can't make decisions. >I have heard value judgments from you Jay in two articles now. You are >making them by simply responding to the text of others while expressing >your opinions. Your recommendations of doing nothing and ignoring packet >radio is a value judgment in itself. The problem is that the arguments I've seen and the proposed priorities here for allocation of frequencies all involve personal feelings and objectives - they all assume that one kind of repeater is "better" than another. We cannot include such a thing in the coordination process. I would love to be able to say, "OK, packet: here's 146-147. Go for it." The simple truth is that is politically impossible. So far, though, that - or something like it - is the only suggestion I have heard. IT WILL NOT WORK. >What you are really saying (I think) is that coordinators can not make >objective value judgments without fear of reprisal or of being ignored. >So... they can't make decisions in the face of any form of conflict. >The status quo must be maintained until a repeater war or a schism is >formed between packet radio and voice repeaters. THEN when everything >has gone to hell in a handbasket the coordinator can do something? The first statement is exactly correct. A coordinator cannot make a value judgment. ("Objective value judgment" is oxymoronic.) They can make decisions in the face of a conflict, but those decisions must be based on purely objective factors. We're trying to give packet more frequencies. We're trying to do so even in the face of accusations that packeteers aren't using what they have properly. (No, I do not make such an accusation.) The problem is that packet types want us to bypass the frequency coordination process for their "obviously state-of-the-art" use. Sorry, but that, too, is a value judgment. >Far more emergency traffic will be handled on voice? Well I think that >will depend very much on the situation involved. If you are talking about >VHF and car accidents and short term emergencies, then I agree. But if >you are talking about LONG term emergencies like a hurricane or other >natural disaster I disagree. When you start talking about large VOLUMES >of traffic where ACCURACY is required, packet radio as it is right now >IS doing a better job. It will become even more viable.... assuming that >its growth isn't overly restricted by limiting development for fear of >law suits. Do you not honestly believe that someone who has invested over $2000 in a repeater will just voluntarily shut it down and stick it in a corner without a fight? I don't. A lawsuit is a natural act for someone in that position. Emergency traffic via packet is only now beginning to be used in the average emergency. I don't argue that packet is a Good Thing in an emergency. Still, the average ham who goes into an emergency doesn't have a battery-powered computer and a battery-powered TNC to hook into his already battery-powered HT. Guess which will get more use? >Phil Karn writes: >>>But you will note that I have not mentioned the one criteria that, until >>>now, has been the only thing that most repeater councils seem to go on: >>>who was on the air first. >And Jay Maynard replies: >>Despite the fact that that's often the only completely objective >>criterion, and the only one that does not involve a value judgment. >You mean it's the only one where you don't have to make a decision and >show some leadership....correct? This is really what the issue is Jay. Is it leadership to take action which will result in the leader's being destroyed and the subject action ignored? I don't think so. A good leader knows when to take an action. Now is not the time. I said what I meant above: it is the only criterion which is completely objective and requires no value judgments. >Jay, I understand that this issue of a lawsuit has you really shook up. >It is a scary thought and the mere idea that one amateur could do this >to another is worse than any repeater war. I think you might send a letter >to various magazines making everyone aware who is doing this. Just tell >the world who this jerk is and what is his callsign. Peer pressure is not >something to underestimate either.... it might even save you going to >court. Not all of the amateurs in this world are worthy of the title and >pointing out the miscreants within our fraternity should be high on the >list of things to accomplish. Actually, several magazines, as well as the Westlink and W5YI newsletters/broadcasts, did report the filing of the suit. We hope they will report its dismissal (which we were advised of last week), as well. The plaintiff in the suit was Dave Pease, N5DA, of Sunnyvale, TX. >But to let it influence our judgment and adversely affect the growth >of a whole new mode is not to be espoused or advocated. Do you want the >FCC to make all of the judgments for our future? They have proven to >not really have our best interests at heart. If not them, then who else? >If we are going to do it then there are going to be NUMEROUS objective >value judgments being made all the time. To be a leader in anything you >have to be willing to stand up and take the flack if and when it comes. >Right now you are under the gun and are taking some "incoming". Please >don't go down in flames and also please don't ask the rest of us to >avoid ever making a tough decision based on the merits and values inherent >to it simply because there are (expletive deleted) like the one >that is suing your group around. Taking flak (like the message from AA5AV, which I'll respond to in a moment) is expected, and part of the job. Taking unilateral action which we know in advance will result only in the destruction of the goals that the Society has worked for for 25 years - without solving the problem in the first place - is not only not expected, but downright stupid. We CANNOT tell previously coordinated repeaters to get off the air. We can tell them that they are no longer coordinated, but only if they violate the terms of their coordination. We have no enforcement power. We only have some level of influence in the amateur community, and that will last only so long as we do not attempt to overtly thwart the wishes of the community at large. >I would like to leave you with a question. What would you do if a coordinated >voice repeater owner decided to switch his system over to packet operation? >He has a coordinated frequency that everyone is happy with correct? Are you >going to tell him that he can run voice on these frequencies but not packet? >I can think of a lot of possibilities here! If I want to get packet going on >a duplex pair all I have to do is "buy out" a person or group that is already >coordinated, or I could form a group and appoint a new coordinator. Boy >doesn't that really boggle the mind! Think of the profits that could be >made "selling" amateur frequencies to other amateurs! After all, the guy >that got on there first with his repeater OWNS that frequency right? >No? Well Jay, if he won't get off if you tell him to and then sues you if >you try, then I'd say he owns that frequency... lock, stock, and barrel. I'd suggest you direct that question to Herb Crosby, WD5EFC, who runs a packet repeater here in Houston (WD5EFC/R, 146.10/70) - a coordinated repeater, with the blessings of the Society. The difference? He went through the coordination process, instead of trying to destroy it. Any person who wants to put up a repeater - be it voice, packet, RTTY, fax, or anything else allowed by the rules - is welcome to do so. If they desire coordinated status, all they have to do is follow the coordination procedures and adhere to the coordinaton standards that have been adopted by the Society. Those procedures do not allow transfer of a coordination from one person to another. (This has one exception: if the coordination is held by a bonafide ham club, the club may change its trustee at will. The club may not transfer the coordination to a person, however.) If you buy an operating repeater, and the former trustee does not wish to continue to serve (or cannot, for some reason), then the frequency goes back to the available pool and is reassigned. The new owner, of course, can apply for a coordination, and will be recoordinated if nobody who has applied for the coordination before him wants or can use the frequency. This was adopted precisely to preclude selling of frequencies. We can't force him off the air if he chooses to operate uncoordinated, but the person to whom the frequency is recoordinated can go to the FCC and complain about the interference, and they may take appropriate action. If they ask, we will tell them who is coordinated. That last situation would have support from the amateur community in general; they're the ones who wanted the policy. (The standards and procedures for frequency coordination have been adopted by the membership as a whole.) A wholesale reworking of the band plan without such support will only result in loss of any coordination at all. -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can uucp: uunet!nuchat! (eieio)| adequately be explained by stupidity. hoptoad!academ!uhnix1!splut!jay +---------------------------------------{killer,bellcore}!texbell ! | "Less great!" "Tastes filling!" ------------------------------ Date: 23 Apr 89 03:51:18 GMT From: pitstop!texsun!texbell!uhnix1!moray!splut!jay@sun.com (Jay "you ignorant splut!" Maynard) Subject: Frequency Coordination In article <8904180842.AA24182@ucbvax.Berkeley.EDU> CJB8753@TAMSIGMA.BITNET writes: >In PACKET-RADIO Digest V89 #96, Jay Maynard writes: >>As we rediscovered in Dallas about three years ago, repeater wars >>do nobody any good. The difference is that now, the FCC can and will >>terminate one in short order, if one repeater is coordinated and the >>other isn't (the commonest case). >If both repeaters are coordinated, the FCC can not take quick and simple >action and you are stuck. Coordination has not completely solved problems >of interference. Repeaters have been coordinated and yet constantly >interfere with each other! We're not perfect. In addition, there will be cases where two repeaters are co-channeled in accordance with the coordination standards, but still occasionally interfere with each other. This is inevitable due to the vagaries of propagation. The specific case you're complaining about has been happening for over 10 years. The only way to guarantee that interference will not occur is to issue a clear-channel coordination, and there are no such channels available , on ANY pair. All frequencies on 2 meters in Texas have at least two repeaters on them. >Some coordinators have been using pencil and >paper until this year to keep track of what machines are operating where. What would you suggest they have used before the advent of personal computers? As it turns out, though, all of the Texas coordinators are now using a computer program developed by Lance Rumfield, WD5KCX, for the Society's use to take care of coordination data storage and retrieval. >This is no better than amateurs installing repeaters on a frequency of their >choice. I have called a 'frequency coordinator' before and tried to work >out an interference problem. He responded by saying something like, >"You need to give me information on a particular action you would like to >take. How can you expect me to go through these coordinations and >help you? Since some of the repeater owners have agreed to coordinate >on the condition that the location of their repeater not be disclosed, I >can give you no information." Well, what did you want him to do? The repeater you're complaining about is over 100 miles away from yours. The standard for co-channel repeaters is 85 miles. All information about a coordination, except for the trustee's call, frequency, and general location, is given to the coordinator in confidence, and will not be released to the public. >So I just change my repeater frequency and see if it causes qrm? Not if >I want to keep my license... Did you try asking your zone coordinator for another frequency? >>All of the repeater pairs have been issued in the Houston and >>Dallas/Fort Worth areas for some time now. >Well, that's great for Houston and Dallas, but the areas in between suffer. >Since a 'zone' is considered completely full, spectrum that could be used >on the border of two zones is wasted. No, the zone is not considered completely full. Only the metropolitan areas I mentioned above are fully occupied. Outside of the metropolitan area, frequencies are available. No spectrum is wasted. Indeed, co-channeling is necessary to insure full use of the spectrum, yet that will inevitably cause some occasional interference as the band opens up. >Allowing a regional coordinator to make himself permanently 'unavailable' >(no telephone) is a cop-out. Requiring written correspondence to suggest >ways to fix repeater qrm is nothing less. How is a person to alleviate >interference if regional coordinators contact each other twice each year? >Yes, this happened in the Dallas/Ft Worth zone of the Texas VHF/FM Society. We recommend that ALL communication with coordinators be in writihg. This is for a simple reason: telephone conversations leave no records, while written communications do. This is not a cop-out, but rather a measure to protect everyone from someone saying one thing and doing something else. Regional coordinators contact each other regularly, as well as the state coordinator. If you have a problem with a coordination, and can get no relief from the zone coordinators involved, then I suggest you contact the state coordinator: Merle Taylor, WB5EPI 605 South Walnut Creek Mansfield, TX 76063 If you still have a problem after trying to work it out with Merle, then you may bring the matter before the Board of Directors of the Society. The next Board meeting will be at the ARRL National Convention, June 2-4 in Arlington. It'll probably be Saturday afternoon, but that's not firmed up yet. If you wish to bring it before the Board, drop me a note (email will do) and I'll see that you're placed on the agenda. >Coordination may be better than no coordination, but it certainly could >use some work. I'll be the first to say that we're not perfect. Instead of simply complaining, though, why not be part of the solution? -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can uucp: uunet!nuchat! (eieio)| adequately be explained by stupidity. hoptoad!academ!uhnix1!splut!jay +---------------------------------------{killer,bellcore}!texbell ! | "Less great!" "Tastes filling!" ------------------------------ Date: 19 Apr 89 20:22:21 GMT From: schlep.dec.com!jfcl.dec.com!frg@decvax.dec.com (Fred R. Goldstein) Subject: PACKET-RADIO Digest V89 #96 In article <8904180838.AA24002@ucbvax.Berkeley.EDU> BIW104@URIACC.BITNET (Chris Tate) writes: >...HOWEVER, how can a person or AR club be expected to shut down their rather >large investment because of prior mistakes in bandplans! Everyone knows >that they can't be moved. So what is a club or person supposed to do? >Pack it in because of packet? The Amateur Service isn't based on "allocated channels"; no ham owns a channel. Check the rules. Coordination is supposed to minimize conflict, not grant ownership of channels. So when there's conflict, repeaters can double up. COmmercial ones do it all the time -- LOTS of users share each commercial channel in the major markets! They use PL to prevent conflict, or other such techniques. Hams can use them too. Or they can use closer spacing. Ham repeaters started out on 60 kHz spacing, went to 30 kHz "splits", then to 15 kHz "split-splits". That's as close as FM can get, but then there's geographic spacing. How many miles between repeaters? Some conflicts may occur but if a service area (needed, not provided) is small, why not share? >The division of the frequency spectrum has and always will be done poorly.. >There is nothing we can do. Look at TV and FM broadcast. The FCC got bought >and there is no changing *that* now, nor is there ever going to be a channel 1 >again. And my most hated fo-pa: CB on 27MHz. How can you make such a >mistake and ask for so many problems! The point is that it shuldn't be done at all. For years, hams figured out where to transmit. Unless it was malicious interference, it was okay -- we SHARE the bands with each other. Try to find a "clear" frequency on 20 meters! No way Jose. But somehow, repeaterniks think that they're entitled to stay put forever. Nobody should be forced off the air. No repeater should be closed down. But they shuld be given warning that they should move to a shared frequency by suchandsuch date, 'cause somebody else will be moving onto their frequency! ------------------------------ End of PACKET-RADIO Digest ****************************** 24-Apr-89 02:25:43-MDT,11201;000000000000 Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL> Date: Mon, 24 Apr 89 01:30:37 MDT From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL Subject: PACKET-RADIO Digest V89 #109 To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL PACKET-RADIO Digest Mon, 24 Apr 89 Volume 89 : Issue 109 Today's Topics: 890421.0 Release of KA9Q TCP/IP Package FCC's recognition of repeater coordination is a disaster (2 msgs) KISS in Heath Pocket Packet PACKET-RADIO Digest V89 #96-------------------------------------------------------------- -------- Date: 22 Apr 89 19:03:19 GMT From: hpfcdc!hpldola!hp-lsd!col!bdale@hplabs.hp.com (Bdale Garbee) Subject: 890421.0 Release of KA9Q TCP/IP Package I just dropped off master copies of the 4 360k disks comprising the 890421.0 release of the KA9Q Internet Package with Andy Freeborn, N0CCZ. Andy and friends will be making many copies of the bits to distribute at the TAPR booth in the new building at the Dayton Hamvention next weekend. After I've had a chance to sleep a wee bit, I'll push the bits over to one or more Internet sites, etc., and post more specific details about the release. Just wanted to let everyone know "It's Done." Watch this space for more details in a day or two. 73 - Bdale, N3EUA ------------------------------ Date: 23 Apr 89 15:30:57 GMT From: nuchat!splut!jay@uunet.uu.net (Jay Maynard) Subject: FCC's recognition of repeater coordination is a disaster In article <481@jfcl.dec.com> frg@jfcl.nac.dec.com.UUCP (Fred R. Goldstein) writes: >Fred> Repeater coordination enforcement locks up the bands in their >mid-1970's state, preventing digital and other users from gaining >access to frequencies. Suggestions include allowing a return to >the days of unregulated repeaters (even if a few wars occur) and >having coordinators adopt priorities, such as "high usage" and >"special feature", making others double-up as the case need be. >Jay> Coordinators are accepted because they don't make judgements. >There's no one value judgement, so coordinators simply leave everyone >intact. The alternative leads to repeater wars, which would make >the bands unusable. >(I hope I got your side right in 3 1/2 lines, Jay!) Well, sort of. Coordinators are accepted because they don't say that any repeater is better than any other. As long as we make no value judgments, we are accepted. Prioorities inherently involve value judgments, and everyone's values differ. >Now, I fully appreciate Jay's quandary. Being a judge is no fun >either, since you're going to make somebody unhappy. But the status >quo has the specific effect of making exactly ONE detail worth >more than all others put together: LONGEVITY. He who has been here >the longest, has rights over all the others. Not exactly. It's a first-come-first-served system, but once a repeater is coordinated, it has no privileges or status over any other repeater. It's a binary system. >Here, we have repeater rights. If a hundred packeteers want a >repeater pair, they could of course get some voice repeater (existing >use) to be turned over to them, right? (I sure hope the system >doesn't say "VOICE ONLY FOREVER"!) Now, what's going to get some >existing allocation-holder to give up his repeater pair? Somebody >may have a little machine on his garage, used by 3 guys, two of >whom don't live there anymore. But he now owns a RESOURCE, a >repeater pair. So the packeteers can BUY him out, right? Just like >Arizona and the water rights. No, the packeteers cannot buy him out. In Texas, the coordination rules do not allow buying or selling of a coordination. An individual cannot transfer a frequency except to a bonafide ham club, and a club cannot transfer a frequency at all. If a trustee relinquishes a coordination, the pair goes back into the unassigned pool and may be reassigned. No, the system doesn't say "voice only"; ask Herb Crosby, trustee of WD5EFC/R, a packet-primary repeater here in Houston. He can be reached at splut!linkit!herb. >Repeater wars didn't cause a lot of grief where I lived (NY area >then New England). There were some nasty ones, when two BIG >repeaters claimed a single frequency, but small-repeater fights >were just noise. I posit that while a few pairs might be made >temporarily unusable due to "deregulation" (making coordination >voluntary again), the overall amount of useful communication taking >place on the band as a whole will be increased. Innovation will >pay off more than some collisions will cost. Repeater wars were disastrous in Southern California, and, to a lesser extent, in Texas. I will go a long, long way to avoid officially sanctioning them. Pairs will become unusable, and we aill have much more conflict within the amateur ranks because of repeater wars. Do you really want that? No benefit is enough to put up with repeater wars. >I don't want coordinators to order anyone offf the air. Repeaters >can share frequencies. Voice machines can use PL, anti-PL, bursts, >directional antennas, etc.; those are quite common in the NY area >where co-channel spacing can be 30 miles or so for small repeaters. >Digital machnes have CSMA techniques. You have to take TWO low >priority machines and give them ONE frequency, not just knock an >exisitng user off the air. Or you can let the marketplace do it, >just as the SSB/AM conflict led to an eventually orderly transition. Good luck. In practice, co-channeling repeaters purposely where they will interfere with each other will do nothing more than start, officially, a repeater war. That is no more practical than simply ordering them off the air. Besides, there's that word "priority" again. We can't establish priorities. Your plan is not politically possible. The marketplace may do it, but it will do it within the bounds of frequency coordination. -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can uucp: uunet!nuchat! (eieio)| adequately be explained by stupidity. hoptoad!academ!uhnix1!splut!jay +---------------------------------------{killer,bellcore}!texbell ! | "Less great!" "Tastes filling!" ------------------------------ Date: 23 Apr 89 23:27:03 GMT From: n3dmc!johnl@uunet.uu.net (John Limpert) Subject: FCC's recognition of repeater coordination is a disaster In article <2601@splut.UUCP> jay@splut.UUCP (Jay "you ignorant splut!" Maynard) writes: >So far, all I've heard is "Cut down on the voice repeaters. Move some of >them to the same frequencies as others, regardless of how much >interference will result; tell others to get off the air." I claim that >such an approach will not work, and will result in the complete >breakdown of the frequency coordination process. What would be wrong with encouraging the reuse of frequencies by repeaters and control links? Brian Kantor gave a number of reasons why private repeaters exist on their own exclusive frequency pairs. I can understand people wanting a secluded channel away from the noise and inanity of many public repeaters. I disagree with his assertion that PL is impractical in the amateur service as it exists today. PL encode/decode capability would allow repeaters to share frequencies with smaller geographic spacing and less interference than today. This would make more efficient use of the spectrum. I don't want to tell people to get off the air, I just want them to make more effective use of current technology so that others can fit into the limited spectrum of the amateur bands. The poor quality or lack of PL in some transceivers is not an adequate reason to dismiss the concept IMHO. Amateur radio equipment manufacturers will supply the equipment if they perceive a market. Joe the appliance operator can have a local tech or ham store retrofit his radio. Voice repeaters are not the only problem, the packet frequencies are not efficiently used either. Sometimes I see the local BBS systems wasting huge amounts of bandwidth/time with poor modems, radios and link protocols. It's irritating to see 50 packets transmitted for a message that is only 10 packets in length, esp. when most of the retransmissions are caused by lack of flow control in the protocols. By the way, do you have any numbers on the percentage of frequencies allocated to various usages? I have never seen any info from any of the frequency coordinating bodies. -- John A. Limpert UUCP: johnl@n3dmc.UUCP, johnl@n3dmc.UU.NET, uunet!n3dmc!johnl ------------------------------ Date: Sun, 23 Apr 89 10:56:45 PDT From: Doug Faunt N6TQS 415-688-8269 <faunt@cisco.com> Subject: KISS in Heath Pocket Packet Has anyone done this? I beleive it should be doable, but haven't looked into it deeply yet. ------------------------------ Date: 23 Apr 89 15:37:58 GMT From: nuchat!splut!jay@uunet.uu.net (Jay Maynard) Subject: PACKET-RADIO Digest V89 #96 In article <640@n3dmc.UU.NET> johnl@n3dmc.UUCP (John Limpert) writes: >Why can't we move the less active repeaters to a smaller set of >frequencies and require the use of PL (CTCSS) decoders on the repeater >receivers? The same could be done with control links and other low >activity frequency allocations. Many of the new rigs have PL encoders >as standard or optional equipment. PL encoders can be added to most >older rigs without much effort. Every time I tune thru the 2 meter, 220 >and 440 bands I am amazed by the low levels of usage compared to what >has been 'allocated', and I am located in a major metropolitan area. As >far as I am concerned, repeater owners (and anyone else) do not have >unrestricted rights to a frequency that they aren't using in an >efficient manner. Many of the local repeaters could be put on a single >frequency pair with PL and the frequency pair would still be >underutilized. No repeater will be active all the time. Repeater activity is a time-dependent thing, peaking at a few times during the day. Putting multiple repeaters on one frequency is nothing more than an officially sanctioned repeater war. Your idea looks workable, but it ignores the users of the repeater, who must also have PL decoders so they don't get swamped with traffic from the other repeaters. Finally, how do you define "low use", or "less active", or "inefficient", or "underutilized"? In a way that a frequency coordinator can use to determine who gets stuck into a war? Reliably? Undisputably? That is exactly the kind of value judgment that a coordinator cannot make. -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can uucp: uunet!nuchat! (eieio)| adequately be explained by stupidity. hoptoad!academ!uhnix1!splut!jay +---------------------------------------{killer,bellcore}!texbell ! | "Less great!" "Tastes filling!" ------------------------------ End of PACKET-RADIO Digest ****************************** 25-Apr-89 02:42:18-MDT,21000;000000000000 Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL> Date: Tue, 25 Apr 89 01:30:41 MDT From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL Subject: PACKET-RADIO Digest V89 #110 To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL PACKET-RADIO Digest Tue, 25 Apr 89 Volume 89 : Issue 110 Today's Topics: ANS: FCC's recognition of repeater coordination is a disaster Computer Networking Conference FCC's recognition of repeater coordination is a disaster (3 msgs) looking for 3c503 driver for kqa9------------------------------------------------------------- --------- Date: Tue, 25 Apr 89 00:52:33 EST From: mgb@tecnet-clemson.arpa Subject: ANS: FCC's recognition of repeater coordination is a disaster In the attached message Jay counterpoints all of my arguments most effectively. I am sincerely glad that 99% of the geographical United States does not share the problems that he has, and for the sake of sanity I will be sure to stay away from the areas in this country that have to deal with these issues :-) However one last point. No matter what the problem, it is probably best left to the local people and their local representatives to battle it out. While Jay has not found any alternatives that he considers viable, I sure have by reading other peoples comments and ideas and I thank them for their time in expressing them. M&$H?}l5 While their alternatives might not work for him, his reasons for why they won't do not apply to the whole country. Good luck Jay... better you than me. Mark Bitterlich mgb@tecnet-clemson.arpa >The following is the message that was responded to. > >To: tecnet@tecnet-clemson.arpa >From: pitstop!texsun!texbell!uhnix1!moray!splut!jay@sun.com (Jay "you ignorant splut!" Maynard) >Posted: Apr 23 03:24 >Cc: >Subject: FCC's recognition of repeater coordination is a disaster > >In article <8904162113.AA21308@tecnet-clemson.arpa> mgb@TECNET-CLEMSON.ARPA writes: >>Original posting: Apr 15 07:23 by: >>nuchat!splut!jay@uunet.uu.net (Jay "you ignorant splut!" Maynard) >>>Lawsuits are something to fear. >>And if someone uses the law to harass and constrict the people that are >>trying to see the big picture, then we should bow to that pressure and >>simply make no decisions? Is that what you are saying Jay? > >#include <complaint-about-overly-litigious-society> >I'm not saying that we should make no decisions. I am saying that we >must realistically look at what is the likely outcome of the decisions, >and it's dumb to make a decision which will 1) be roundly ignored, and >2) provoke lawsuits which seek to reverse it. > >>True, but the only answer I see you advocating is "do nothing, else we >>might get sued." Did you ever consider the fallout of a packet radio >>versus voice repeater war? Doing nothing could eventually lead to that, >>all the right ingredients are there. > >So far, all I've heard is "Cut down on the voice repeaters. Move some of >them to the same frequencies as others, regardless of how much >interference will result; tell others to get off the air." I claim that >such an approach will not work, and will result in the complete >breakdown of the frequency coordination process. > >>To be objective simply means to express the nature of reality as it is >>apart from personal feelings or objectives. In other words to avoid >>having a biased opinion. It DOES NOT mean that you can't make decisions. >>I have heard value judgments from you Jay in two articles now. You are >>making them by simply responding to the text of others while expressing >>your opinions. Your recommendations of doing nothing and ignoring packet >>radio is a value judgment in itself. > >The problem is that the arguments I've seen and the proposed priorities >here for allocation of frequencies all involve personal feelings and >objectives - they all assume that one kind of repeater is "better" than >another. We cannot include such a thing in the coordination process. >I would love to be able to say, "OK, packet: here's 146-147. Go for it." >The simple truth is that is politically impossible. >So far, though, that - or something like it - is the only suggestion I >have heard. IT WILL NOT WORK. > >>What you are really saying (I think) is that coordinators can not make >>objective value judgments without fear of reprisal or of being ignored. >>So... they can't make decisions in the face of any form of conflict. >>The status quo must be maintained until a repeater war or a schism is >>formed between packet radio and voice repeaters. THEN when everything >>has gone to hell in a handbasket the coordinator can do something? > >The first statement is exactly correct. A coordinator cannot make a >value judgment. ("Objective value judgment" is oxymoronic.) They can >make decisions in the face of a conflict, but those decisions must be >based on purely objective factors. >We're trying to give packet more frequencies. We're trying to do so even >in the face of accusations that packeteers aren't using what they have >properly. (No, I do not make such an accusation.) The problem is that >packet types want us to bypass the frequency coordination process for >their "obviously state-of-the-art" use. Sorry, but that, too, is a value >judgment. > >>Far more emergency traffic will be handled on voice? Well I think that >>will depend very much on the situation involved. If you are talking about >>VHF and car accidents and short term emergencies, then I agree. But if >>you are talking about LONG term emergencies like a hurricane or other >>natural disaster I disagree. When you start talking about large VOLUMES >>of traffic where ACCURACY is required, packet radio as it is right now >>IS doing a better job. It will become even more viable.... assuming that >>its growth isn't overly restricted by limiting development for fear of >>law suits. > >Do you not honestly believe that someone who has invested over $2000 in >a repeater will just voluntarily shut it down and stick it in a corner >without a fight? I don't. A lawsuit is a natural act for someone in that >position. > >Emergency traffic via packet is only now beginning to be used in the >average emergency. I don't argue that packet is a Good Thing in an >emergency. Still, the average ham who goes into an emergency doesn't >have a battery-powered computer and a battery-powered TNC to hook into >his already battery-powered HT. Guess which will get more use? > >>Phil Karn writes: >>>>But you will note that I have not mentioned the one criteria that, until >>>>now, has been the only thing that most repeater councils seem to go on: >>>>who was on the air first. >>And Jay Maynard replies: >>>Despite the fact that that's often the only completely objective >>>criterion, and the only one that does not involve a value judgment. >>You mean it's the only one where you don't have to make a decision and >>show some leadership....correct? This is really what the issue is Jay. > >Is it leadership to take action which will result in the leader's being >destroyed and the subject action ignored? I don't think so. A good >leader knows when to take an action. Now is not the time. >I said what I meant above: it is the only criterion which is completely >objective and requires no value judgments. > >>Jay, I understand that this issue of a lawsuit has you really shook up. >>It is a scary thought and the mere idea that one amateur could do this >>to another is worse than any repeater war. I think you might send a letter >>to various magazines making everyone aware who is doing this. Just tell >>the world who this jerk is and what is his callsign. Peer pressure is not >>something to underestimate either.... it might even save you going to >>court. Not all of the amateurs in this world are worthy of the title and >>pointing out the miscreants within our fraternity should be high on the >>list of things to accomplish. > >Actually, several magazines, as well as the Westlink and W5YI >newsletters/broadcasts, did report the filing of the suit. We hope they >will report its dismissal (which we were advised of last week), as well. >The plaintiff in the suit was Dave Pease, N5DA, of Sunnyvale, TX. > >>But to let it influence our judgment and adversely affect the growth >>of a whole new mode is not to be espoused or advocated. Do you want the >>FCC to make all of the judgments for our future? They have proven to >>not really have our best interests at heart. If not them, then who else? >>If we are going to do it then there are going to be NUMEROUS objective >>value judgments being made all the time. To be a leader in anything you >>have to be willing to stand up and take the flack if and when it comes. >>Right now you are under the gun and are taking some "incoming". Please >>don't go down in flames and also please don't ask the rest of us to >>avoid ever making a tough decision based on the merits and values inherent >>to it simply because there are (expletive deleted) like the one >>that is suing your group around. > >Taking flak (like the message from AA5AV, which I'll respond to in a >moment) is expected, and part of the job. Taking unilateral action which >we know in advance will result only in the destruction of the goals that >the Society has worked for for 25 years - without solving the problem in >the first place - is not only not expected, but downright stupid. >We CANNOT tell previously coordinated repeaters to get off the air. We >can tell them that they are no longer coordinated, but only if they >violate the terms of their coordination. We have no enforcement power. >We only have some level of influence in the amateur community, and that >will last only so long as we do not attempt to overtly thwart the wishes >of the community at large. > >>I would like to leave you with a question. What would you do if a coordinated >>voice repeater owner decided to switch his system over to packet operation? >>He has a coordinated frequency that everyone is happy with correct? Are you >>going to tell him that he can run voice on these frequencies but not packet? >>I can think of a lot of possibilities here! If I want to get packet going on >>a duplex pair all I have to do is "buy out" a person or group that is already >>coordinated, or I could form a group and appoint a new coordinator. Boy >>doesn't that really boggle the mind! Think of the profits that could be >>made "selling" amateur frequencies to other amateurs! After all, the guy >>that got on there first with his repeater OWNS that frequency right? >>No? Well Jay, if he won't get off if you tell him to and then sues you if >>you try, then I'd say he owns that frequency... lock, stock, and barrel. > >I'd suggest you direct that question to Herb Crosby, WD5EFC, who runs a >packet repeater here in Houston (WD5EFC/R, 146.10/70) - a coordinated >repeater, with the blessings of the Society. The difference? He went >through the coordination process, instead of trying to destroy it. Any >person who wants to put up a repeater - be it voice, packet, RTTY, fax, >or anything else allowed by the rules - is welcome to do so. If they >desire coordinated status, all they have to do is follow the >coordination procedures and adhere to the coordinaton standards that >have been adopted by the Society. > >Those procedures do not allow transfer of a coordination from one person >to another. (This has one exception: if the coordination is held by a >bonafide ham club, the club may change its trustee at will. The club may >not transfer the coordination to a person, however.) If you buy an >operating repeater, and the former trustee does not wish to continue to >serve (or cannot, for some reason), then the frequency goes back to the >available pool and is reassigned. The new owner, of course, can apply >for a coordination, and will be recoordinated if nobody who has applied >for the coordination before him wants or can use the frequency. This was >adopted precisely to preclude selling of frequencies. We can't force him >off the air if he chooses to operate uncoordinated, but the person to >whom the frequency is recoordinated can go to the FCC and complain about >the interference, and they may take appropriate action. If they ask, we >will tell them who is coordinated. > >That last situation would have support from the amateur community in >general; they're the ones who wanted the policy. (The standards and >procedures for frequency coordination have been adopted by the >membership as a whole.) A wholesale reworking of the band plan without >such support will only result in loss of any coordination at all. > >-- >Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can >uucp: uunet!nuchat! (eieio)| adequately be explained by stupidity. > hoptoad!academ!uhnix1!splut!jay +--------------------------------------->{killer,bellcore}!texbel l! | "Less great!" "Tastes filling!" > ------------------------------ Date: 24 Apr 89 14:50:07 GMT From: cs.utexas.edu!milano!bigtex!helps!bongo!julian@tut.cis.ohio-state .edu (julian macassey) Subject: Computer Networking Conference I have been able to find out that on Saturday October 7 the 8th annual ARRL Amateur Radio Computer Networking Conference (what a mouthful) will be held in Colorado Springs. So: Who is hosting it? Where exactly is it? Any hotel lists, prices? Could someone who is "au fait" please post the exciting details or tell us where we can find them. Yours-- Julian Macassey, n6are julian@bongo ucla-an!denwa!bongo!julian n6are@wb6ymh (Packet Radio) n6are.ampr.org [44.16.0.81] voice (213) 653-4495 ------------------------------ Date: 24 Apr 89 19:36:23 GMT From: cs.utexas.edu!oakhill!dover!waters@tut.cis.ohio-state.edu (Mike Waters) Subject: FCC's recognition of repeater coordination is a disaster In article <2605@splut.UUCP> jay@splut.UUCP (Jay "you ignorant splut!" Maynard) writes: >Well, sort of. >Coordinators are accepted because they don't say that any repeater is >better than any other. As long as we make no value judgments, we are >accepted. Prioorities inherently involve value judgments, and everyone's >values differ. I agree with you Jay that the coordinator had better not be the one to set the priorities, but I think some priority schem is going to come along anyway. The real problem for the coordinator is not only to stay neutral but to be SEEN to be neutral! THAT IS TOUGH TO DO! The problem is compounded by two other items (a) the coordinator is a volunteer - not full time and (b) the coordinator is the "most expert" person around on the subject and so cannot simply remain silent. >Repeater wars were disastrous in Southern California, and, to a lesser >extent, in Texas. I will go a long, long way to avoid officially >sanctioning them. Pairs will become unusable, and we aill have much more >conflict within the amateur ranks because of repeater wars. Do you >really want that? No benefit is enough to put up with repeater wars. I am with you 100% here Jay, a bunch of "repeater wars" seems like the fastest way I can imagine to get the FCC to "coordinate" commercial users on that frequency. In the preparations for the WARC a few years ago, ham radio lost quite a bit of credibility (i.e. frequencies) because a delegate played a tape of a typical 20M pileup from their country to the other delegates. Including all the jamming, profanity, "get lost turkeys" etc. etc.. According to the ARRL WARC coordinator (speaking at a YCCC meeting BTW) this was one of the biggest "PR" problems they faced. "Why should we give up frequencies for THIS?" they were asked. >Your plan is not politically possible. Remember that this IS a "political" problem! There are ways that have been developed to solve such problems, slow and painful as they are, but there are also ways to disrupt the process. We as hams lose if we do let it degenerate into a "war" of any sort. -- *Mike Waters AA4MW/7 waters@dover.sps.mot.com OR waters@cad.Berkley.EDU*- if it GLISTENS, gobble it!! ------------------------------ Date: 25 Apr 89 01:01:45 GMT From: jupiter!karn@bellcore.com (Phil R. Karn) Subject: FCC's recognition of repeater coordination is a disaster >Coordinators are accepted because they don't say that any repeater is >better than any other. As long as we make no value judgments, we are >accepted. Prioorities inherently involve value judgments, and everyone's >values differ. But Jay, you ARE making an implicit value judgement! "First-come, first served, and nothing else matters" is just as much a value judgement as "FM over SSB" or "voice over packet". You keep claiming that there are no other objective criteria by which you can assign priorities to competing requests for spectrum. But if you look back at the article I posted the other week, you will see that almost every potential criterion on my list has a clearly objective, quantitative measurement associated with it. For example, it ought to be obvious to all but the most obtuse frequency coordinator that SSB takes about 5-6x less bandwidth than NBFM, and that packet is quantitatively far more efficient in moving formal message traffic than reading it by FM voice. These comparisons involve hard numbers. They are not subjective value judgements. What is admittedly difficult to resolve, however, are the relative WEIGHTS that should be applied to each of the various objective criteria when you're arbitrating a dispute between dissimilar groups. For example, how much weight should be given to a large RTTY group that is competing with a smaller packet group for a given amount of spectrum, considering that packet is much more efficient in its use of spectrum? This is something that has to be worked out through open discussion, with each group having its say. The ultimate goal must be to meet the raison d'etre of the Amateur Service as much as possible. Sticking your head in the sand and clinging to the first-come-first-served rule come hell or high water simply isn't going to produce an amateur service that is capable of holding on to its frequencies. Phil ------------------------------ Date: Tue, 25 Apr 89 00:32:18 EST From: mgb@tecnet-clemson.arpa Subject: FCC's recognition of repeater coordination is a disaster Just another short comment on the points that Jay Maynard has been making here. 1. Everything is "politically impossible". 2. "No benefit is enough to put up with repeater wars". 3. "We can't establish priorities". Flame on: In short no one can do anything... give it up guys... voice repeaters own the spectrum... there is no solution... Jay, you've convinced me... you have no solution. In fact I am THROUGHLY convinced that you will NEVER find a solution. The packet people aren't even allowed to BUY a frequency! You've got all the bases covered. There is no possibility for change, etc., etc. You have now shot down the suggestions from every single person on this but have offered NONE of your own as an alternative. As you can see it is starting to get to me a little bit. Sorry. Flame off: I have another idea. I am sure it will sound stupid and there will probably be something wrong with it, but it may get around the coordinators and the FCC. Who says that we have to use 600 khz offsets for duplex packet work? The coordinators don't control SIMPLEX frequencies. Is there a law somewhere that would prevent someone from using say, 145.09 and 147.555 for a duplex packet split? It would be cumbersome to the user and would require using a radio that supports non-standard offsets.... but it would obviously work and would require less hardware to accomplish than a 600 khz split repeater. I am not advocating this for everyone, but for areas that are already chock-ablock full with voice repeaters already it offers an alternative. Or are all the simplex freqs designated to certain users? I expect to get flamed on this, but in the process maybe we can hear more alternatives and not the "you can't get there from here" messages. Mark Bitterlich mgb@tecnet-clemson.arpa ------------------------------ Date: 24 Apr 89 22:00:11 GMT From: oliveb!intelca!mipos3!cadev4!rod@ames.arc.nasa.gov (Rod Rebello) Subject: looking for 3c503 driver for kqa9 I need a 3c503 ethernet card driver for the KQA9 TCP/IP package. I would really appreciate any assistance in obtaining one. Thanks Rod ------------------------------ End of PACKET-RADIO Digest ****************************** 26-Apr-89 02:24:40-MDT,4929;000000000000 Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL> Date: Wed, 26 Apr 89 01:30:38 MDT From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL Subject: PACKET-RADIO Digest V89 #111 To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL PACKET-RADIO Digest Wed, 26 Apr 89 Volume 89 : Issue 111 Today's Topics: FCC's recognition of repeater coordination is a disaster Wanted - Manual for Tektronix Terminal--------------------------------------------------------- ------------- Date: 24 Apr 89 15:56:08 GMT From: schlep.dec.com!jfcl.dec.com!frg@decvax.dec.com (Fred R. Goldstein) Subject: FCC's recognition of repeater coordination is a disaster In article <2605@splut.UUCP> jay@splut.UUCP (Jay "you ignorant splut!" Maynard) writes: >In article <481@jfcl.dec.com> frg@jfcl.nac.dec.com.UUCP (Fred R. Goldstein) writes: >Not exactly. It's a first-come-first-served system, but once a repeater >is coordinated, it has no privileges or status over any other repeater. >It's a binary system. >Repeater wars were disastrous in Southern California, and, to a lesser >extent, in Texas. I will go a long, long way to avoid officially >sanctioning them. Pairs will become unusable, and we aill have much more >conflict within the amateur ranks because of repeater wars. Do you >really want that? No benefit is enough to put up with repeater wars. > Repeater wars were disastrous to those who didn't expect them, or who didn't know how to cope with them. Malicious interference was part of some such wars, and should not be condoned. That's different from the "wars" that go on constantly on the DC bands, where QRM is simply expected. >>I don't want coordinators to order anyone offf the air. Repeaters >>can share frequencies. Voice machines can use PL, anti-PL, bursts, >>directional antennas, etc.; those are quite common in the NY area >>where co-channel spacing can be 30 miles or so for small repeaters. >>Digital machnes have CSMA techniques. You have to take TWO low >>priority machines and give them ONE frequency, not just knock an >>exisitng user off the air. Or you can let the marketplace do it, >>just as the SSB/AM conflict led to an eventually orderly transition. > >Good luck. In practice, co-channeling repeaters purposely where they >will interfere with each other will do nothing more than start, >officially, a repeater war. That is no more practical than simply >ordering them off the air. >Besides, there's that word "priority" again. We can't establish >priorities. >Your plan is not politically possible. Co-channeling repeaters where they are warned that they have some overlapping coverage is not the same as putting two open repeaters five miles apart on the same pair. Commercial users have gone to PL, anti-PL, etc.; these techniques work, especially when the primary coverage areas differ but secondary areas overlap. Even a binary priority is a priority. Guy On The Air has priority over Guy Not On The Air. I see it as quite politically possible to change this, though the Guys On THe Air (once every month) won't like it. >The marketplace may do it, but it will do it within the bounds of >frequency coordination. If I were to go to my local coordinator and say I wanted a packet repeater-pair, and he followed your rules (I don't know whose he follows, so this is a hypo), then he'll say, "fine, get on the waiting list." I'll no doubt have my channel by April 1, 2007. That's not a marketplace issue -- lots of semi-idle repeaters still take up frequencies. Again this may stem from experiences -- mine in NYC differ from yours in TX. (It's more peaceful in NE where I live now.) A few repeater overlaps were annoying, but owners worked things out in various ways. So long as everyone knew that they had no God-given right to total exclusivity, and didn't cause MALICIOUS interference, things worked. I have heard some obnoxious californians who obviously needed more uh pursuasion. Still, coordinators have more options than to simply make waiting lines and leave all intact allocations totally free of sharing. fred ------------------------------ Date: 25 Apr 89 14:16:33 GMT From: rti!cml@mcnc.org (Carl Lewis) Subject: Wanted - Manual for Tektronix Terminal A friend of mine has acquired a Tektronix 4008 storage terminal for nearly nothing at a local university surplus store. Unfortunately, nothing is about what it is worth without the operating instructions, which they could not provide, nor could their electronics shop. If you are able to help, please contact him, Howard, directly at: 919-543-2972 days. If email is more convenient, please contact me, Carl, via usenet at: mcnc!rti!cml ------------------------------ End of PACKET-RADIO Digest ****************************** 26-Apr-89 15:39:39-MDT,9219;000000000000 Mail-From: KPETERSEN created at 26-Apr-89 15:16:32 Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL> Date: Wed, 26 Apr 89 15:16:31 MDT From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL Subject: PACKET-RADIO Digest V89 #112 To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL PACKET-RADIO Digest Wed, 26 Apr 89 Volume 89 : Issue 112 Today's Topics: 9600BPS/3KHz-G1NTX----------------------------------------------- ----------------------- Date: 26 Apr 89 04:37:20 GMT From: osu-cis!n8emr!gws@tut.cis.ohio-state.edu (Gary Sanders) Subject: 9600BPS/3KHz-G1NTX ============================================================== | Relayed from packet radio via | | N8EMR's Ham BBS, 614-457-4227 (1200/2400/19.2 telebit,8N1) | ============================================================== Fast Packet Systems By: Simon Taylor G1NTX From CONNECT INTERNATIONAL - April, 1989. Copyright 1989 by Radio Society of Great Britain. Reprinted by permission For some time now I have been interested in the discussions going on regarding fast packet and data links using RF modems, specifically 9600 bits per second (bps) modems. There seem to be two schools of thought: 1) To use modems connected directly into transceiver IF strips and modulate the carrier directly with data. 2) To connect the data modem via the audio connections of the rig, and operate in a similar way to the technique use on 3KHz bandwidth telephone lines. A colleague of mind (G8DXZ) and myself have proved that this technique works up to 9600bps and we plan to try 14,400bps modems soon. The purpose of this article is to disscuss the latter technique and (hopefully) stimulate some interest and maybe even some more experiments with these modems. THE PRINCIPLES Telephone modems, because of the transmission medium must operate within a 3KHz bandwidth. The frequency response of the telephone line is normally quoted as being between 400Hz and 3400Hz. Most people are familiar with normal frequency shift keying (FSK) using two different tones as used in existing packet radio, but to go must faster than 1200bps within a 3KHz bandwidth requires some further thought. The first principle used is Phase shift keying (PSK) which uses one audio tone (the carrier) with phase changes introduced into this carrier which can be detected at the receiver. The advantage here is that one phase change can theoretically be introduced every cycle of the carrier and if four types of phase changes are used, then two bits can be encoded per sampling time. Secondly, amplitude changes can be added so giving more combinations and more bits encoded per sample time. At this stage, we should introduce another iece of jargon - the Baud. Baud defines the sampling time, i.e. the rate of Phase and Amplitude changes, so for example if four bits are encoded during every baude, and the 'Baud rate" is 1200, then the effective bit rate will be 4800 bps. Given below is a table showing some half-duplex modulation techniques and their data rates. Technique Bit Baud Bits per Phase Amplitude Carrier rate rate Baud Changes Changes Frequency V.29 9600 2400 4 8 1 1700 V.29 7200 2400 3 8 0 1700 V.29 4800 2400 2 4 0 1700 V.27 4800 1600 3 8 0 1800 V.27 2400 1600 2 4 0 1800 Another aspect of these modems is that of 'training'. When data are sent, they are scrambled to made sure that all of the data points are sent even with no data being sent. This makes most efficient use of the transmitted spectrum. The receiving modem will synchronise to the transmitting modem, keeping track of the phase changes as transmission goes on. This traning does take some time however, and will cause time overheads if the channel is turned around frequently. The main reason for training using these patterns is to determine the phase and amplitude restrictions of the path, and to set up an equaliser that is used to give a flat response during data transmission. The modems we have tried also employ 'adaptive equalisation' which will adjust equaliser values during data transmission for small changes in the quality of the received signal. The time taken to train may make transmission using this faster data mode an overhead rather than an advantage if only small packets of data are sent. V.29 for example, needs 270 milliseconds to train before any data are sent, which is equivalennt to about 40 characters of information at 1200 bits per second. Therefore, we should send at least this amount of data and preferably more to take advantage of the higher data rate after training. Below are some packet sizes and the times to transmit using existing 1200 bps packet versus V.29 at 9600bps. Packet Time @ Time @ Size (chars) 1200bps V.29/9600bps 20 0.133 0.286 50 0.333 0.311 100 0.666 0.353 200 1.333 0.436 500 3.333 0.686 1000 6.666 1.103 2000 13.333 1.936 Times given is seconds. From the table it can be seen that the larger the packet, the greater the advantage. It may be that this mode of transmission is not suitable for use with the existing AX.25 standard, but some sort of alternative protocol could be used (or developed) which will not transmit until it has a certain amount of data to send. Further discussion about protocols is beyond the scope of this article, I shall leave it to the national packet network... Remember that these modems are designed to operate within the 3KHz availaable on telephone lines and a larger audio bandwidth is normally used on VHF/UHF FM, so the quality on a good path is usually found to be better than that obtained via our national telephone system. THE PRACTICE There are a number of modem devices which can be used for the audio modulation part of a fast RF modem. Connection to a rig can be simply via Audio in, Audio ouut and PTT and these modem should be simple to connect to existing TNC's such as the G0BSX-2 or similar, but I have not tried this yet. So far I have tried communications using an IBM-PC directly controlling the modem and PTT without any rigid packet structure as such, but this has proved that the principle at least works on VHF and UHF FM. All of the modems I have tried have been similar in that they require CPU control via a bus which is 8080 compatible and have simple audio in and out connections. All that has been needed is a D>C> blocking capacitor between the modem output and the microphone input (some rigs may also need some reduction of the signal), and a capacitor from the earphone output of a typical rig. A relay should then be driven to control the PTT. Suitable modems I have tried include: The R96MD, this is a V.29 and V.27 modem primarily intended for FAX machines, but makes an ideal half-duplex data modem. This device is supplied on a small pCB with two rows of pins allowing it to be assembled like a large DIP device. It will opeate from 9600bps down to 2400bps, as well as at V.21 at 300bps FSK. DTMF is also provided which may be of use to some amateurs. This modem, because of it's application in FAX products benefits from a reduced cost due to it's use in massive volumes. The R96MFX and R96EFX, these are CMOS single-chip modems with similar features too the R96MD. The R96EFX is especially interesting because it has a V.27 short train feature, training in 50 milliseconds instead of the 270 milliseconds standard, and HDLC packetising and error detection built-in, so avoiding the need for external HDLC controllers. We soon plan to try toe R144HD which is a V.33 modem which operates at 14,400bps. Again the modem is designed to operate in a 3KHz telephone bandwidth, so VHF/UHF operation should not be a problem. If you would like data sheets or data books on these modems, then I can be contacted QTHR. Sending out information will not prove a problem. Also you can leave messages for me at GB3UP (G1NTS @ GB3UP.GBR.EU) Reference reading: "Quality of Received Data for Signal Processor Based Modems" application note (Rockwell 1987 Modem data book), this data book also includes data sheets on all of the modems discussed. "Rockwell Interface Guide", This gives detailed information as to the connection, use and monitoring techniques used forr these modems, (but is a cost item.) Simon Taylor G1NTX - 21st March 1989 ------------------------------ End of PACKET-RADIO Digest ****************************** 27-Apr-89 02:16:23-MDT,9069;000000000000 Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL> Date: Thu, 27 Apr 89 01:30:33 MDT From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL Subject: PACKET-RADIO Digest V89 #113 To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL PACKET-RADIO Digest Thu, 27 Apr 89 Volume 89 : Issue 113 Today's Topics: FCC's recognition of repeater coordination is a disaster KISS in Heath Pocket Packet New Mac release of KA9Q code wanted: TEXNET info------------------------------------------------------------- --------- Date: Thu, 27 Apr 89 01:22 CDT From: <CJB8753%TAMSIGMA.BITNET@CUNYVM.CUNY.EDU> Subject: FCC's recognition of repeater coordination is a disaster In PACKET-RADIO Digest V89 #108, Jay Maynard writes: >We're not perfect. In addition, there will be cases where two repeaters >are co-channeled in accordance with the coordination standards, but >still occasionally interfere with each other. This is inevitable due to >the vagaries of propagation. The specific case you're complaining about >has been happening for over 10 years. Good grief. Then maybe this is the year for action by the coordinator(s)? >>Some coordinators have been using pencil and >>paper until this year to keep track of what machines are operating where. >What would you suggest they have used before the advent of personal >computers? This is 1989. I have owned a personal computer for a decade now which can do what a coordinator needs. In an age of increased need for spectrum, it does not pay to sit around 10 years before attempting to make maximum usage of a band. >>This is no better than amateurs installing repeaters on a frequency of their >>choice. I have called a 'frequency coordinator' before and tried to work >>out an interference problem. He responded by saying something like, >>"You need to give me information on a particular action you would like to >>take. How can you expect me to go through these coordinations and >>help you? Since some of the repeater owners have agreed to coordinate >>on the condition that the location of their repeater not be disclosed, I >>can give you no information." >Well, what did you want him to do? The repeater you're complaining about >is over 100 miles away from yours. The standard for co-channel repeaters >is 85 miles. Since you know about this particular problem, let's get the facts straight. The standard for co-channel repeaters is 85 miles. The two repeaters in conflict are 67 miles apart. Without unusual propagation, one can sit at the base of the local repeater and hear the distant machine. A person sitting at the base of the distant machine can not monitor the local repeater. Since local users never key the distant machine, an obvious solution would be to decrease the ERP of the distant repeater. This is only one of many solutions, however. What did I expect the coordinator to do? First, check his coordination data to see what kind of signal levels are probable at various locations. If something doesn't match, it is very likely that one of the two trustee's has made a change in his station without getting the neccessary coordination (this happened and greatly aggravated the situation). If no obvious clerical or illegalities (under coordination rules) are involved, I would hope for an alternate solution. Since the coordinator has all of the data for all of the repeaters, he is the only person in the position of making a reasonable guess as to what might work. >Did you try asking your zone coordinator for another frequency? Yes. We found 3 possible frequencies that could be used. One of them looks very good. The problem now is navigating through the rest of the red tape to make a change. Since the repeater is on the border of two zones, the second coordinator must be contacted (no telephone until they got a new coordinator). If he agrees to the change, he must then contact the local zone coordinator. This would be done at one of the two bi-annual Texas VHF/FM Society meetings. If no further problems were found, the change could be made. There are multiple people involved, and politics will play a role in the decision no matter what the official policy may be. If the local zone coordinator is a close friend, he may pick up the phone and call the other coordinator the same day I talk to him. If not, he may tell me a year later that there are conflicts in the other zone. This particular case is one to note. Although the local repeater was on-the-air first and coordinated first (which is the single rule you mention), the coordinator has not revoked the coordination of the distant repeater operator even though one-way interference is a problem. This is a fine example of "no action is the action taken." The distant repeater operator might possibly change frequencies, but contacting three zone coordinators and then waiting for them to convene simply isn't worth his time and effort when he is not personally experiencing any interference. I personally do not want for the distant repeater owner to become 'uncoordinated,' because I believe there are technical solutions to the problem. It's really unfortunate the system doesn't work a little smoother. Thanks, Jay, for your offer of bringing the matter before the board. I really don't want to see that happen because the bickering will have gone way too far for something like a 2 meter repeater. Charles Burnett, AA5AV AA5AV @ W5AC (packet) CJB8753@TAMSIGMA (Bitnet) ------------------------------ Date: Wed, 26 Apr 89 11:43:35 PDT From: Doug Faunt N6TQS 415-688-8269 <faunt@cisco.com> Subject: KISS in Heath Pocket Packet I've not gotten any responses to my earlier inquiry, and I've proceeded with investigation. I dumped the EPROM, a 27C256, from the unit, and discovered a fair amount of blank space. The area from 60F0 to 6FFF is all 0's, and the space from 7020 to 7FFF is all F's. This looks like enough space to add the complete KISS code. There are what look like "Howie" code copyright notices in the dump, as well as all the TNC2 messages, and a little BBS system. It appears to be version 1.1.4, and as soon as I can get a copy of that code for my TNC-2's, I'll compare them to see how different it looks. There is 32K of ram, as well. The CPU is a Toshiba TMPZ84C015AF-6, which means a 6MHz Z80 MPU with counter/timer/serial IO, and who knows what else, that is a standard commercial product, with complete information available about the unit. The data book is on its way, I'm told. Can someone give me pointers on a development environment for Z80 code? I have DEC-20's, Sun's and XT/AT's available, but no Z80 machine. Any responses to this message are welcomed. Thanx. ------------------------------ Date: 27 Apr 89 05:26:15 GMT From: ka9q.bellcore.com!n6bis@bellcore.com (Patty Winter) Subject: New Mac release of KA9Q code In honor of Dayton, a new Macintosh version of Phil Karn's TCP/IP code is being released. Pencils ready? Its official name is 871225.33a4 Macintosh version 1.0. (There wasn't time for the Mac team to port the new version recently released for the PC, but they'll have it ready soon.) Copies will be available at the TAPR booth at Dayton. Since TAPR doesn't have facilities to dupe Macintosh disks, they aren't handling distribution of this version on a regular basis; we're just providing them with some disks for Dayton. If you aren't coming to Dayton, please send either a Mac disk with a self-addressed stamped disk mailer, or $5 (to cover the cost of a disk and mailer) to: Doug Thom N6OYU 1405 Graywood Dr. San Jose, CA 95129 Technical questions can be addressed to Doug (thom@apple.com), or to Mike Chepponis K3MC (k3mc@apple.com). In case you haven't heard, this version has separate windows for log, trace, and commands/sessions. It also runs nicely under MultiFinder, so it's easy to keep both NET and BM up and running and switch between them. Enjoy! Patty ================================================================= =========== Patty Winter N6BIS n6bis@ka9q.bellcore.com ================================================================= =========== ------------------------------ Date: Wed, 26 Apr 89 11:08:12 MEZ From: C0033003%DBSTU1.BITNET@CUNYVM.CUNY.EDU Subject: wanted: TEXNET info hello pr.world \n is there someone out in networld who could enlighten me about some details of the TEXNET stuff? Any info would be appreciated. Please e-mail direkt to c0033003 @ dbstu1.bitnet tnx in advance. 73s de Detlef ( dk4eg @ dk0mav ) t . pass ------------------------------ End of PACKET-RADIO Digest ****************************** 27-Apr-89 14:47:57-MDT,13816;000000000000 Mail-From: KPETERSEN created at 27-Apr-89 14:33:50 Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL> Date: Thu, 27 Apr 89 14:33:49 MDT From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL Subject: PACKET-RADIO Digest V89 #114 To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL PACKET-RADIO Digest Thu, 27 Apr 89 Volume 89 : Issue 114 Today's Topics: FCC's recognition of repeater coordination is a disaster (5 msgs)------------------------------------------------------------ ---------- Date: 26 Apr 89 14:56:58 GMT From: vsi1!wyse!mips!prls!philabs!briar.philips.com!rfc@apple.com (Robert Casey;6282;3.57;$0201) Subject: FCC's recognition of repeater coordination is a disaster A possible solution to the problem of getting a repeater pair for packet use may be a time division schedule. Let the repeater be available for voice use during rush-hour and other popular times, and do packet message forwarding, etc during the dead of night (2AM-4AM), and maybe during low use times when most of the voice users are at thier jobs. Allow breaks in the packet time so emergency voice traffic can get through. I imagine that some low use repeater users (like those semi-private machines) may like having thier machine be put to some use late at night when everyone's in bed, so they can have more reason to keep the frequency pair for thier semi-private voice use during the day. Just an idea.... 73 de WA2ISE ------------------------------ Date: 27 Apr 89 12:24:57 GMT From: nuchat!splut!jay@uunet.uu.net (Jay "you ignorant splut!" Maynard) Subject: FCC's recognition of repeater coordination is a disaster In article <1130@dover.sps.mot.com> waters@dover.UUCP (Mike Waters) writes: >I agree with you Jay that the coordinator had better not be the one to set >the priorities, but I think some priority schem is going to come along >anyway. If not us, who? >The real problem for the coordinator is not only to stay neutral but to be >SEEN to be neutral! THAT IS TOUGH TO DO! It's downright impossible if we get into assigning priorities to various uses of the spectrum. >The problem is compounded by two other items (a) the coordinator is a >volunteer - not full time and (b) the coordinator is the "most expert" person >around on the subject and so cannot simply remain silent. Which is why I've been speaking out here...It's all well and good to say "Let's promote packet! Get the low-use repeaters to double up!", but from where I sit, there ate impossibilities involved. >Remember that this IS a "political" problem! There are ways that have been >developed to solve such problems, slow and painful as they are, but there are >also ways to disrupt the process. We as hams lose if we do let it degenerate >into a "war" of any sort. Absolutely. The job is political. The "solutions" I've seen so far ignore political realities in favor of technical fun. I'm not anti-techie, despite some comments I've seen, but the ham population is larger than that, and a significant number of people don't care about anything but hearing a kerchunk when they let off the mike. -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can uucp: uunet!nuchat! (eieio)| adequately be explained by stupidity. hoptoad!academ!uhnix1!splut!jay +---------------------------------------{killer,bellcore}!texbell ! | "Less great!" "Tastes filling!" ------------------------------ Date: 27 Apr 89 12:49:56 GMT From: nuchat!splut!jay@uunet.uu.net (Jay "you ignorant splut!" Maynard) Subject: FCC's recognition of repeater coordination is a disaster In article <642@n3dmc.UU.NET> johnl@n3dmc.UUCP (John Limpert) writes: >What would be wrong with encouraging the reuse of frequencies by >repeaters and control links? Brian Kantor gave a number of reasons why >private repeaters exist on their own exclusive frequency pairs. I can >understand people wanting a secluded channel away from the noise and >inanity of many public repeaters. I disagree with his assertion that PL >is impractical in the amateur service as it exists today. [...] The problem is that we can't effectively require such a thing. We've tried to require technical upgrades before, and the net result has been a revolt within the ranks. People would much rather complain than spend money. While an increasing number of rigs have PL encoders installed, either by retrofit or from the factory, only a tiny number have PL decode capability. Requiring anything like that will simply result in the current leadership of the coordinating body getting tossed out and replaced with others who don't presume to spend other people's money. >By the way, do you have any numbers on the percentage of frequencies >allocated to various usages? I have never seen any info from any of the >frequency coordinating bodies. Outside of frequencies reserved to specific uses by the band plan, that info isn't really available. I can tell you that 144.91 to 145.09, in 20 kHz steps, is reserved for packet, and that 145.5 to 146.0 is reserved for satellite, but we don't track things like the 146.10/70 packet repeater here in Houston. -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can uucp: uunet!nuchat! (eieio)| adequately be explained by stupidity. hoptoad!academ!uhnix1!splut!jay +---------------------------------------{killer,bellcore}!texbell ! | "Less great!" "Tastes filling!" ------------------------------ Date: 27 Apr 89 13:00:50 GMT From: nuchat!splut!jay@uunet.uu.net (Jay "you ignorant splut!" Maynard) Subject: FCC's recognition of repeater coordination is a disaster In article <8904250532.AA11283@tecnet-clemson.arpa> mgb@TECNET-CLEMSON.ARPA writes: >1. Everything is "politically impossible". Not everything, just the idea of forcing people to move or turn off their repeaters. >2. "No benefit is enough to put up with repeater wars". An accurate summation. So far, only Fred Goldstein has disagreed with it. >3. "We can't establish priorities". Exactly right. >In short no one can do anything... give it up guys... voice repeaters own the >spectrum... there is no solution... No, voice repeaters don't own the spectrum. Whoever has gotten there first has the ability to use that frequency - for whatever choice they desire, including packet - but they don't own it. >Jay, you've convinced me... you have no solution. In fact I am THROUGHLY >convinced that you will NEVER find a solution. The packet people aren't >even allowed to BUY a frequency! You've got all the bases covered. There is >no possibility for change, etc., etc. You have now shot down the suggestions >from every single person on this but have offered NONE of your own as an >alternative. As you can see it is starting to get to me a little bit. Sorry. As I said at the beginning of this discussion, I don't claim to have a solution. I was responding to complaints that coordinators won't give packet more frequencies. It's not that simple. I admit that I don't have the answers. What I do have is experience in the coordination arena. So far, none of the proposed solutions I've seen can work. That doesn't mean that there isn't one that will. >Who says that we have to use 600 khz offsets for duplex packet work? The >coordinators don't control SIMPLEX frequencies. Is there a law somewhere >that would prevent someone from using say, 145.09 and 147.555 for a duplex >packet split? No, there isn't. Such a repeater would not have coordinated status, but as long as it doesn't cause interference, there would be no reason for that to make a difference. You might get some (possibly severe) grief from some folks using 147.555 for FM simplex work, as the band plan specifies, though... >I am not advocating this for everyone, but for areas that are already chock-a>block full with voice repeaters already it offers an alternative. Or are all >the simplex freqs designated to certain users? No, the simplex frequencies are not allocated at all except to say that they are for simplex use. There may be an existing group using a specific frequency, and you might get in a fight with some CD group somewhere, but that kind of issue doesn't really fall within a frequency coordinator's purview. >I expect to get flamed on this, but in the process maybe we can hear more >alternatives and not the "you can't get there from here" messages. No flames here. The only time, and the only reason, that I may say "you can't get there from here" is that experience has shown that you can't. -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can uucp: uunet!nuchat! (eieio)| adequately be explained by stupidity. hoptoad!academ!uhnix1!splut!jay +---------------------------------------{killer,bellcore}!texbell ! | "Less great!" "Tastes filling!" ------------------------------ Date: 27 Apr 89 12:17:40 GMT From: nuchat!splut!jay@uunet.uu.net (Jay "you ignorant splut!" Maynard) Subject: FCC's recognition of repeater coordination is a disaster In article <15581@bellcore.bellcore.com> karn@jupiter.bellcore.com (Phil R. Karn) writes: (in response to me:) >>Coordinators are accepted because they don't say that any repeater is >>better than any other. As long as we make no value judgments, we are >>accepted. Prioorities inherently involve value judgments, and everyone's >>values differ. >But Jay, you ARE making an implicit value judgement! "First-come, first >served, and nothing else matters" is just as much a value judgement as >"FM over SSB" or "voice over packet". Nope...first-come, first-served is nothing more than objective, and a realization of the simple fact that it's next to impossible to move or shut down a repeater without the consent of the trustee. Given that, it's only common sense to implement rules that will be respected and work. We aren't saying "FM over SSB" or "voice over packet". If you want to put up an SSB repeater, or a duplex packet repeater, fine. Go for it. All we ask is that you follow the rules. (I won't get into the myriad problems associated with SSB repeaters... but experience shows that, at least as currently implemented in the two-way world, they leave a LOT to be desired.) >You keep claiming that there are no other objective criteria by which >you can assign priorities to competing requests for spectrum. But if you >look back at the article I posted the other week, you will see that >almost every potential criterion on my list has a clearly objective, >quantitative measurement associated with it. For example, it ought to be >obvious to all but the most obtuse frequency coordinator that SSB takes >about 5-6x less bandwidth than NBFM, and that packet is quantitatively >far more efficient in moving formal message traffic than reading it by >FM voice. These comparisons involve hard numbers. They are not >subjective value judgements. The hard numbers are there, but that they should be involved in coordination decisions is where we differ: the consideration that one repeater is better than another, and therefore should be given priority in coordination, is a value judgment. >What is admittedly difficult to resolve, however, are the relative >WEIGHTS that should be applied to each of the various objective criteria >when you're arbitrating a dispute between dissimilar groups. For >example, how much weight should be given to a large RTTY group that is >competing with a smaller packet group for a given amount of spectrum, >considering that packet is much more efficient in its use of spectrum? That's not just difficult to resolve, it's flat impossible. You'll never get the respective groups (no matter what the criterion) to agree that the choice you make is the right one if that choice goes against them. They will always argue the decision, and will eventually flout it. >This is something that has to be worked out through open discussion, >with each group having its say. The ultimate goal must be to meet the >raison d'etre of the Amateur Service as much as possible. Sticking your >head in the sand and clinging to the first-come-first-served rule come >hell or high water simply isn't going to produce an amateur service that >is capable of holding on to its frequencies. This kind of thing won't get worked out in open discussion; it'll get endlessly argued in open discussion, with no option being generally acceptable. If a solution is imposed, there will always be a disgruntled faction, and the accumulated weight of unhappiness will eventually bring the system down, producing the repeater wars that Fred Goldstein wants. He's the only one I've ever talked to that does, though. The great advantage of the first-come-first-served rule is that it's fair, equitable, and working. Speaking of holding on to frequencies, why can't these new users populate the other frequency bands? We're going to lose the higher bands if we don't use them, and if people put as much effort into populating 902-928 as they did in fighting the coordination system, we'd never be in danger of losing it. -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can uucp: uunet!nuchat! (eieio)| adequately be explained by stupidity. hoptoad!academ!uhnix1!splut!jay +---------------------------------------{killer,bellcore}!texbell ! | "Less great!" "Tastes filling!" ------------------------------ End of PACKET-RADIO Digest ****************************** 28-Apr-89 02:16:23-MDT,5456;000000000000 Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL> Date: Fri, 28 Apr 89 01:30:29 MDT From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL Subject: PACKET-RADIO Digest V89 #115 To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL PACKET-RADIO Digest Fri, 28 Apr 89 Volume 89 : Issue 115 Today's Topics: FCC's recognition of repeater coordination is a disaster Next release of PC packet drivers soon.------------------------------------------------------------ ---------- Date: 27 Apr 89 13:40:33 GMT From: texbell!uhnix1!moray!splut!jay@bellcore.com (Jay "you ignorant splut!" Maynard) Subject: FCC's recognition of repeater coordination is a disaster In article <485@jfcl.dec.com> frg@jfcl.nac.dec.com.UUCP (Fred R. Goldstein) writes: >Repeater wars were disastrous to those who didn't expect them, or >who didn't know how to cope with them. Malicious interference was >part of some such wars, and should not be condoned. That's different >from the "wars" that go on constantly on the DC bands, where QRM is >simply expected. Malicious interference was part of ALL such wars that I've ever heard of, as well as a lot of other, even less savory things. Do you really want that? I don't. As Mike Waters has said, that kind of thing is even more damaging. >Co-channeling repeaters where they are warned that they have some >overlapping coverage is not the same as putting two open repeaters >five miles apart on the same pair. Commercial users have gone >to PL, anti-PL, etc.; these techniques work, especially when the >primary coverage areas differ but secondary areas overlap. These techniques may work in the commercial world, but there is no covenant there. There is one in the amateur coordination field. We can't unilaterally overturn that covenant. >Even a binary priority is a priority. Guy On The Air has priority over >Guy Not On The Air. I see it as quite politically possible to change >this, though the Guys On THe Air (once every month) won't like it. If we were to try this, we'd be thrown out and a group that doesn't want to change it would be installed in our places. After all, we're violating our gentleman's agreement. >If I were to go to my local coordinator and say I wanted a packet >repeater-pair, and he followed your rules (I don't know whose he >follows, so this is a hypo), then he'll say, "fine, get on the >waiting list." I'll no doubt have my channel by April 1, 2007. >That's not a marketplace issue -- lots of semi-idle repeaters still >take up frequencies. No, you'll have your channel sooner than that. Besides, there's always 1.2, 900, ... The semi-idle repeaters have made an agreement: they put up (to a certain extent) with us telling then where they should operate, and within what technical parameters, and we protect them. We can't unilaterally change that, and that's exactly what you're calling for. >Again this may stem from experiences -- mine in NYC differ from yours >in TX. (It's more peaceful in NE where I live now.) A few repeater >overlaps were annoying, but owners worked things out in various ways. >So long as everyone knew that they had no God-given right to total >exclusivity, and didn't cause MALICIOUS interference, things worked. >I have heard some obnoxious californians who obviously needed more >uh pursuasion. During the 20 kHz discussions, this was a common thread: "They use upright 15 kHz channels in the Northeast, why can't we here?" People who had operated there, and who had moved here, were unanimous: repeaters there were much less usable than they are here. Lots of interference, and lots of arguments, and lots of adjacent-channel problems. The users and trustees of Texas repeaters decided they didn't want that. >Still, coordinators have more options than to simply make waiting >lines and leave all intact allocations totally free of sharing. Technically, you're correct. Politically, it's impossible to implement. -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can uucp: uunet!nuchat! (eieio)| adequately be explained by stupidity. hoptoad!academ!uhnix1!splut!jay +---------------------------------------{killer,bellcore}!texbell ! | "Less great!" "Tastes filling!" ------------------------------ Date: 27 Apr 89 21:46:14 GMT From: sun.soe.clarkson.edu!nelson@tcgould.tn.cornell.edu (Russ Nelson) Subject: Next release of PC packet drivers soon. Anyone who has any contributions, bugs or suggestions for the IBM-PC packet driver collection should send them to me. I'm going to put out a new release of the packet drivers soon. This release will include globally unique handles[1], user documentation[2], Kelly McDonald's Novell packet driver support, and Karl Auerbach's PCIP packet driver support. The last two will be distributed separately because not everyone will want them. [1] Required for Phil Karn's TCP/IP package to support multiple packet drivers. [2] People seem unwilling to read the source when they can't grok the parameters. I don't understand why... :-)-- --russ (nelson@clutx [.bitnet | .clarkson.edu]) S&Ls get bailouts and that's okay, but poor people get welfare and that's not. ------------------------------ End of PACKET-RADIO Digest ****************************** 29-Apr-89 02:34:24-MDT,15550;000000000000 Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL> Date: Sat, 29 Apr 89 01:30:56 MDT From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL Subject: PACKET-RADIO Digest V89 #116 To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL PACKET-RADIO Digest Sat, 29 Apr 89 Volume 89 : Issue 116 Today's Topics: FCC's recognition of repeater coordination is a disaster (3 msgs) FCC's recognition of repeater coordinators is a disaster Node Map-------------------------------------------------------------- -------- Date: 28 Apr 89 14:26:59 GMT From: sun-barr!male!pitstop!texsun!convex!iex!athens.iex.com!bert@ames. arc.nasa.gov (Bert Campbell) Subject: FCC's recognition of repeater coordination is a disaster In article <2609@splut.UUCP> jay@splut.UUCP (Jay "you ignorant splut!" Maynard) writes: >In article <15581@bellcore.bellcore.com> karn@jupiter.bellcore.com (Phil R. Karn) writes: >(in response to me:) >>>Coordinators are accepted because they don't say that any repeater is >>>better than any other. As long as we make no value judgments, we are >>>accepted. Prioorities inherently involve value judgments, and everyone's >>>values differ. >>But Jay, you ARE making an implicit value judgement! "First-come, first >>served, and nothing else matters" is just as much a value judgement as >>"FM over SSB" or "voice over packet". > >Nope...first-come, first-served is nothing more than objective, and a >realization of the simple fact that it's next to impossible to move or >shut down a repeater without the consent of the trustee. Given that, >it's only common sense to implement rules that will be respected and >work. The question is "accepted by who" and "define working". I contend that the "no value judgement" agrument is at best a shirking of responsibility on the part of the coordination organization, and at worst just a red herring to maintain the status quo. The idea that no consensus can be reached regarding what is fair is preposterous. Of course everyone can't have his/her way, but most amateurs I've dealt with are a fairnessminded lot who will operate within the rules if they are percieved fairly grounded. I really doubt if the majority of amateurs believe that the current system of "get a channel now, it's yours forever" is realistic or fair. The band plan itself is a huge exercise in value judgement. This much space for packet, this much for satellite, this much for reteaters, etc. Are we supposed to believe that the band plan(s) can never be changed because that would involve a "value judgement"? Do the frequency coordination organizations have any input on the "official" band plan? What are they going to do when space for voice repeaters or other "modes" is reduced to make way for new patterns of activity? I always try to follow band plan guidelines, and find that most amateurs do also. The code no-code issue is an exercise in value judgement. Some people believe that folks that refuse to learn code would add no value to the amateur community. I didn't get Mr Maynard's response to my last posting about repeater inequities, (news problems in TX) but did see a portion of it in someones reponse to his response (whew)... As usual the point is missed, turning the machine off would be fine. Bert Campbell N5KGT {uunet,convex}!iex!bert ------------------------------ Date: 27 Apr 89 18:49:28 GMT From: schlep.dec.com!jfcl.dec.com!frg@decvax.dec.com (Fred R. Goldstein) Subject: FCC's recognition of repeater coordination is a disaster In article <8904250532.AA11283@tecnet-clemson.arpa> mgb@TECNET-CLEMSON.ARPA writes: >Flame off: > >I have another idea. I am sure it will sound stupid and there will probably >be something wrong with it, but it may get around the coordinators and the >FCC. > >Who says that we have to use 600 khz offsets for duplex packet work? The >coordinators don't control SIMPLEX frequencies. Is there a law somewhere >that would prevent someone from using say, 145.09 and 147.555 for a duplex >packet split? It would be cumbersome to the user and would require using a >radio that supports non-standard offsets.... but it would obviously work and >would require less hardware to accomplish than a 600 khz split repeater. >I am not advocating this for everyone, but for areas that are already chock-a>block full with voice repeaters already it offers an alternative. Or are all >the simplex freqs designated to certain users? >Mark Bitterlich A couple of problems arise. It is probably okay for a ROUTER (ip gateway, store-and-forward digi, etc.) to do that, since it is not repeating the signal in real time. It then needn't use the Repeater frquencies at all (the ones you mention are within the repeater bands though). But the need is more for true repeaters, since the AX.25 and related "CSMA" channel-sharing methods are more Aloha than CSMA, and are thus terribly inefficient. Just an analog repeater for packet would do wonders. That would need a repeater pair. So using odd-ball frequencies wouldn't be different from using odd-ball splits for FM: It would get simplex users mad! And it's tough to implement since many radios have fixed splits. No, a repeater is a repeater, and should follow standard splits as much as possible. BTW in some places 1 MHz is still used for some frequencies (146.43 in NJ, I think). fred k1io ------------------------------ Date: 28 Apr 89 18:27:16 GMT From: schlep.dec.com!jfcl.dec.com!frg@decvax.dec.com (Fred R. Goldstein) Subject: FCC's recognition of repeater coordination is a disaster In article <2614@splut.UUCP> jay@splut.UUCP (Jay "you ignorant splut!" Maynard) writes: >In article <8904250532.AA11283@tecnet-clemson.arpa> mgb@TECNET-CLEMSON.ARPA writes: >>2. "No benefit is enough to put up with repeater wars". > >An accurate summation. So far, only Fred Goldstein has disagreed with >it. And not an accurate summation of my position, either. Believe it or not, I do spend a fair amount of operating time on the DC bands, even using manual radiotelegraphy (straight key and cans). A quiet night on 20M is far more prone to QRM than any "repeater war" except for intentionally malicious ones. Repeater frequency conflicts (pre-Gosrepeater) occur in two modes. One is the all-out "repeater war", when one group intentionally tries to clobber another one. This is quite rare, and typically falls under the rubric "malicious interference". Thus it is not prevented by coordination; previous rules prevented it, and coordination is a secondary issue. I don't think this is a good way to use the spectrum either, unless the two groups involved are willing to do it as, say, a test of interference-reduction technology. And that's not the norm! But the second kind of "repeater war" is the incidental conflict, when two repeaters overlap in coverage the way DC band users hear each other without killing the QSO. If I'm chatting with a CX8 in Spanish, then it might be disconcerting if some WB4 clobbers him, even if the QRM wouldn't kill a QSO in my first language. But I don't cry about it; "them's the breaks". And on VHF FM, we have incidental conflict when a mobile (or even a sloppy base, who should know better) triggers two machines at once. Local users usually "capture" but time-outs occur. We have incidental conflict when squelches break from the wrong repeater, but that's trivial annoyance and if you don't have tone squelch, then please don't complain to me that you don't have absolute quiet on "your frequency"! Absent Gosrepeater (the current plan), we'd still have voluntary coordinators, who'd suggest the least-interference route. We'd play with antenna patterns, PL and anti-PL, etc., to minimize conflict. We'd act like HAMS. Even like low-band hams, most of whom try to minimize QRM even if the band has 8 times as many users as "quiet" bands would have (i.e., average of 8 stations per 3 kHz -- just a random number). On occasion, there'd be "repeater wars", when people got upset about the failure of these measures to keep things from interfering, or when an existing user got peeved about a new one making things tougher. But what was 20M like in 1929? Probably less crowded than now. And probably a lot of today's hams were there then, judging by the age stats! > >No, voice repeaters don't own the spectrum. Whoever has gotten there >first has the ability to use that frequency - for whatever choice they >desire, including packet - but they don't own it. Just think how easily one of these OOT's could have worked 300 countries if he could have had the exclusive right to call CQ on 3 kHz of 20M! >I admit that I don't have the answers. What I do have is experience in >the coordination arena. So far, none of the proposed solutions I've seen >can work. That doesn't mean that there isn't one that will. > Of course you can't ahve "the answers". Because the problem has no easy solution. Having the FCC grant you the imprimatur to treat ham bands like commercial frequencies doesn't make things better, it just changes the problem. I prefer the old problems and solutions. fred k1io ------------------------------ Date: Fri, 28 Apr 89 15:15:24 EST From: mgb@tecnet-clemson.arpa Subject: FCC's recognition of repeater coordinators is a disaster Concerning this issue, I think that what we are really seeing here is a split occurring among the amateur ranks on what amateur radio is really all about. Jay Maynard has made his points on how he feels recoordination of any repeater is basically impossible for a number of reasons. He has replied to my criticism of "You can't get there from here" with an answer that basically says "That's right"! His answers and epitomes tended to aggravate me with terms such as "politically impossible" and "value judgments" and his basic emphasis on "he who gets here first gets the goodies and if YOU want some, move to another band". It has taken awhile but I believe I finally see the real issue here. It is NOT how to get duplex packet frequencies coordinated, I think the idea of using nonstandard splits and living with a little grief from simplex users is feasible to PARTIALLY solve that question. No... the real issue here is support for technical advancement within amateur radio versus "maintain the status quo". It seems that EVERYONE is for technical advancement as long as it doesn't cause ME any inconvenience! This is the basic line that is always drawn between "users" and "developers". You can even see it within packet radio as people side with TCP/IP or NETROM or TEXNET, etc. Or as a negative reaction to upgrading networks where users might have to reequip to a certain extent! I think it all boils down to a basic resistance to change within our group and I am referring to ALL of amateur radio. The new player into this equation is the "Frequency Coordinator" which is where this whole string of messages started in the first place! Picture what might have happened if all the frequencies on 20 meters were "coordinated" to nets back when we all were using AM. Along comes a few guys with single sideband asking for some frequencies to use for test and experimentation. They quote increased spectrum efficiency and so forth but the Frequency Coordinator will NOT make value judgments and instead tells them to take their SSB to some other band! Isn't that really what is happening now with this discussion on packet and 2 meters? Sure there are nit-picking differences but the basic concept is the same. In this regard the "FCC's Recognition of Frequency Coordinators IS A DISASTER"!!!!!!!! Darn tooting it is!! Because we are losing the ability to battle it out as a group and instead now have to place the problem in the lap of a SMALL group of people such as those with the beliefs of Jay Maynard. I personally react STRONGLY to advocates of "whoever was here first get the goodies"! Why? Because it eliminates anything new... it always will. Not just packet but just about ANYTHING! The only exception being things that everyone sees as beneficial right at the start... and how many things over the years have you EVER seen that meet that definition? It all boils down to what you believe in. Should amateur radio be renowned for it's innovation and technical advancement or for effective utilization of known technology? Not everyone can be a Phil Karn software genius or design and build a AMSAT, but I like to think that the vast majority of us SUPPORT those that DO advance our hobby through technical achievement. If it means that a sacrifice sometimes be made... SO BE IT! But it seems that this is not the case anymore. We have legal suits being instigated against fellow hams, and we see that there is some really EMPHATIC resistance being made to change. Two meter voice repeaters have become almost SACRED to a certain faction among us. This makes me a little sick to my stomach! It is starting to look like 2 meters is following the route of CB radio. It has established it's structure so firmly that certain members among our ranks say that there is just no way to change it! And maybe this is true to a certain extent. This means that we are basically saying that what we have is better than anything that might come along in the future. The "users" are telling the "developers" to PLEASE GO SOMEWHERE ELSE to play with your new toys, we like what we have and want no part of anything else. Jay is representing the "keep it as it is" concept and we are pushing the "let's develop new things no matter what" concept. I doubt that we will ever see eye to eye on this, the differences in beliefs are so fundamental as to never be resolved. But please put me down on record as one who ALWAYS supports development. You don't DEVELOP a status quo, it develops itself... the only thing you can do is to MANAGE it and that just bores me to tears! Frequency Coordinators make me nervous. Their reason for being was to allow growth with less conflict, but now they allow zero growth to avoid conflict. We have always had conflict and we have always risen above it in the long run, but when the FCC basically gave REGULATORY powers to groups that started life as people that were initially only ADVISORARY in nature, they opened Pandora's box. Now the ADVISORS are afraid to REGULATE and the users refuse to be ADVISED! I can see where "repeater wars" might be better in the LONG RUN than what we are faced with now! Jay Maynard says that there is nothing that could be worse than repeater wars, I say there is one thing that is worse.... stagnation. Mark Bitterlich WA3JPY@WB4UOU mgb@tecnet-clemson.arpa ------------------------------ Date: 28 Apr 89 04:49:32 GMT From: ps2x+@andrew.cmu.edu (Peter John Skelly) Subject: Node Map I'm looking for a near to current Node map of both the east coast and west coase (plus any worm holes currently operating). If anyone could help, it would be appreciated. '73 DE Peter Skelly ps2x@andrew.cmu.edu KB7GUD (W3VC-Carnegie Tech Amateur Radio Club) ------------------------------ End of PACKET-RADIO Digest ****************************** 30-Apr-89 02:36:18-MDT,15681;000000000000 Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL> Date: Sun, 30 Apr 89 01:30:36 MDT From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL Subject: PACKET-RADIO Digest V89 #117 To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL PACKET-RADIO Digest Sun, 30 Apr 89 Volume 89 : Issue 117 Today's Topics: Bad C-BBS V6.0 for AMIGA to Dayton Computer Networking Conference FB Icom Service :-) FCC's recognition of repeater coordination is a disaster FCC's recognition of repeater coordinators is a disaster--------------------------------------------------------- ------------- Date: 29 Apr 89 03:07:08 GMT From: att!alberta!dvinci!hardie@ucbvax.Berkeley.EDU (Peter Hardie ) Subject: Bad C-BBS V6.0 for AMIGA to Dayton Sorry folks. I sent a copy of my amiga version of CBBS V6.0 to DAyton with a friend. A few hours after he left I found an insidious bug in it. Yuk. There is no workaround for it and it can crash the amiga in very mysterious ways. If you have a copy that has V6.0 in the window title then it is bad. Give up until you get a later version. Sorry agn. Pete VE5VA ------------------------------ Date: 28 Apr 89 15:37:50 GMT From: hp-ses!hpcea!hpnmdla!glenne@hplabs.hp.com (Glenn Elmore) Subject: Computer Networking Conference > I have been able to find out that on Saturday October 7 the 8th annual >ARRL Amateur Radio Computer Networking Conference (what a mouthful) will be ^ ^ ^---- and will this be the year we dump this word as part of the title? It may take computers to do it but we should be looking forward to something even more comprehensive. What about voice mail, picture mail and other applications which can shield the user from seeing computer involvement? I think we need eventually need this if we are to have mass appeal. (Or don't we want mass appeal?) Glenn Elmore -N6GN- N6GN @ K3MC glenn@n6gn.norcal.ampr.org glenne@hpnmd.hp.com ------------------------------ Date: 29 Apr 89 13:36:27 GMT From: cs.utexas.edu!ut-emx!lad-shrike!kriss@tut.cis.ohio-state.edu (R M Kriss) Subject: FB Icom Service :-) Msg # 11856 Type:B Stat:N To: ALL @VHF From: KD5VU Date: 29-Apr/1256 Subject: FB ICOM Service :-) From: KD5VU@KB5PM Hams are quick to flame companies for bad experiences. This posting is the reciprocal. Icom's service organization in Irving, Texas did a super job for me. I purchased a new Icom 228H 2 meter FM rig a few weeks ago. The radio worked super with one exception. The specification says its a 45 watt rig and mine at best was only 35 watts. Since I paid for a 45 watt rig, I carried it back to the Dealer (Austin Amateur Radio Supply). They verified the problem and shipped the rig back to Icom in Irving, Texas for warranty repair. The radio was shipped UPS from Austin to Irving, Texas late Tuesday, April 25, 1989. The radio was received on Wednesday afternoon, repaired on Thursday and shipped on Friday, April 28th. A "one day" warranty repair! I called on Thursday and the Icom representatives were very nice and advised they confirmed the problem, retuned the final and they output is now 45+ watts. Got-ya on JA land QA! Like the beer ad on TV says IT DOESNUT GET ANY BETTER THAN THIS! This experience is confirmation of one reason I purchased an Icom radio rather than one of the less expensive radios on the market. When I am in the market for another rig, you can bet I will look to Icom first. 73 de Dick Kriss Austin, Texas ------------------------------ Date: 30 Apr 89 00:34:57 GMT From: texbell!splut!jay@bellcore.com (Jay "you ignorant splut!" Maynard) Subject: FCC's recognition of repeater coordination is a disaster In article <8904270721.AA27028@ucbvax.Berkeley.EDU> CJB8753@TAMSIGMA.BITNET writes: >In PACKET-RADIO Digest V89 #108, Jay Maynard writes: >>The specific case you're complaining about >>has been happening for over 10 years. >Good grief. Then maybe this is the year for action by the coordinator(s)? Maybe it's that the folks at W5AC had decided to live with the situation. We had received no complaints until your email to me last year. I have no problem with your decision to no longer live with the problem, but don't flame us for the fact that your group hadn't decided to complain until recently. >>>Some coordinators have been using pencil and >>>paper until this year to keep track of what machines are operating where. >>What would you suggest they have used before the advent of personal >>computers? >This is 1989. I have owned a personal computer for a decade now which >can do what a coordinator needs. In an age of increased need for >spectrum, it does not pay to sit around 10 years before attempting to make >maximum usage of a band. There's no logical connection between coordinators' record-keeping methods and usage of a band. I, too, have owned a personal computer for a long period of time (my first system, which I still have, is 11 years old), but it's unreasonable to expect a coordinator to be a PC pioneer. Only in the past three years or so have reasonably powerful PCs been available at a price that puts it within reach of the average person who has little interest in PCs in and of themselves. One of our coordinators has been working on the program our coordinators will use for about that long. (He has an honest job.) >Since you know about this particular problem, let's get the facts straight. >The standard for co-channel repeaters is 85 miles. The two repeaters in >conflict are 67 miles apart. Without unusual propagation, one can sit at >the base of the local repeater and hear the distant machine. A person >sitting at the base of the distant machine can not monitor the local repeater. >Since local users never key the distant machine, an obvious solution would >be to decrease the ERP of the distant repeater. This is only one of >many solutions, however. What did I expect the coordinator to do? First, >check his coordination data to see what kind of signal levels are probable >at various locations. If something doesn't match, it is very likely that >one of the two trustee's has made a change in his station without getting >the neccessary coordination (this happened and greatly aggravated the >situation). If no obvious clerical or illegalities (under coordination rules) >are involved, I would hope for an alternate solution. Since the coordinator >has all of the data for all of the repeaters, he is the only person in the >position of making a reasonable guess as to what might work. You are correct that the repeaters are 67 miles apart; I was misinformed. The actions you mention are reasonable. Is that what you asked the coordinator to do? How busy is the other machine? Can you squelch it out? I would expect that you could, given the distance involved. Finally, can you show that the other repeater changed its output power? >>Did you try asking your zone coordinator for another frequency? >Yes. We found 3 possible frequencies that could be used. One of >them looks very good. The problem now is navigating through the rest >of the red tape to make a change. Recoordinating a repeater should be a fairly simple process. The red tape involved is no more intricate than a new coordination. >Since the repeater is on the border >of two zones, the second coordinator must be contacted (no telephone >until they got a new coordinator). If he agrees to the change, he must >then contact the local zone coordinator. This would be done at one of the two >bi-annual Texas VHF/FM Society meetings. The zone coordinators communicate frequently with each other, despite your insinuation. That a coordinator wishes to do business by mail with trustees does not mean that other coordinators can't/don't talk to him more frequently on the phone. The difference is that communications with trustees need to be tracked and saved, and communications between coordinators do not. >There are multiple people involved, >and politics will play a role in the decision no matter what the official >policy may be. If the local zone coordinator is a close friend, he may >pick up the phone and call the other coordinator the same day I talk to >him. If not, he may tell me a year later that there are conflicts in >the other zone. If this really happens, then the state coordinator or the Board needs to hear about it. I will tolerate no political considerations in the frequency coordination process, and the coordinators understand this. If the coordinator is not moving fast enough for you, then you can either pester him regularly, contact the state coordinator, or contact me or the Board. >This particular case is one to note. Although the local repeater was >on-the-air first and coordinated first (which is the single rule you >mention), the coordinator has not revoked the coordination of the >distant repeater operator even though one-way interference is a problem. >This is a fine example of "no action is the action taken." The distant >repeater operator might possibly change frequencies, but contacting >three zone coordinators and then waiting for them to convene simply >isn't worth his time and effort when he is not personally experiencing >any interference. This complaint shows a lack of understanding of the coordination process. The coordination was issued. Nobody complained. The A&M radio club (according to one of its members at the time) decided to live with the problem. Now, over 10 years later, someone else complains. Is a change of heart on the part of one of the parties sufficient reason to de-coordinate the other? I also must point out, again, that coordinators don't wait for meetings; they communicate regularly and frequently. >I personally do not want for the distant repeater owner to become >'uncoordinated,' because I believe there are technical solutions to >the problem. It's really unfortunate the system doesn't work >a little smoother. De-coordination is the only real threat we can use to convince a repeater trustee to change his operations. There are technical solutions available, but the problem is not technical - it's political. >Thanks, Jay, for your offer of bringing the matter before the board. >I really don't want to see that happen because the bickering will >have gone way too far for something like a 2 meter repeater. If you are really that dissatisfied with the coordinators' actions, then you have the right under the Society's bylaws to bring the matter before the Board. That is one of our primary functions. If you have a problem, and the coordinators don't solve it, then you have two choices: either live with it or let the Board know about it, and get help that way. -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can uucp: uunet!nuchat! (eieio)| adequately be explained by stupidity. hoptoad!academ!uhnix1!splut!jay +---------------------------------------{killer,bellcore}!texbell ! | "Less great!" "Tastes filling!" ------------------------------ Date: Sat, 29 Apr 89 23:32:44 EST From: mgb@tecnet-clemson.arpa Subject: FCC's recognition of repeater coordinators is a disaster In article <8904250532.AA11283@tecnet-clemson.arpa> mgb@TECNET-CLEMSON.ARPA writes: > >Who says that we have to use 600 khz offsets for duplex packet work? The >coordinators don't control SIMPLEX frequencies. Is there a law somewhere >that would prevent someone from using say, 145.09 and 147.555 for a duplex >packet split? It would be cumbersome to the user and would require using a >radio that supports non-standard offsets.... but it would obviously work and >would require less hardware to accomplish than a 600 khz split repeater. >I am not advocating this for everyone, but for areas that are already chock-a>block full with voice repeaters already it offers an alternative. Or are all >the simplex freqs designated to certain users? >Mark Bitterlich schlep.dec.com!jfcl.dec.com!frg@decvax.dec.com (Fred R. Goldstein) replies: >>A couple of problems arise. It is probably okay for a ROUTER (ip >>gateway, store-and-forward digi, etc.) to do that, since it is not >>repeating the signal in real time. It then needn't use the Repeater >>frequencies at all (the ones you mention are within the repeater bands >>though). But the need is more for true repeaters, since the AX.25 >>and related "CSMA" channel-sharing methods are more Aloha than CSMA, >>and are thus terribly inefficient. Just an analog repeater for packet >>would do wonders. That would need a repeater pair. >>So using odd-ball frequencies wouldn't be different from using odd-ball >>splits for FM: It would get simplex users mad! And it's tough to >>implement since many radios have fixed splits. No, a repeater is a >>repeater, and should follow standard splits as much as possible. >>BTW in some places 1 MHz is still used for some frequencies (146.43 >>in NJ, I think). >> fred k1io Fred, I agree with you on most of the things you have said in previous messages but you have lost me on this one! I seriously don't understand what the problem is. The thoughts that I have are as follows: 1. If you going to end up making some people irate anyway, is there a way to affect LESS people and cause LESS of a financial setback? If you end up trying to move an established repeater, then you are in for a battle. Not necessarily impossible mind you (I don't agree with Jay Maynard :-) but a battle none the less. If you cause a problem to simplex users they only need to change to another simplex freq., (a flip of the dial) not redo a whole repeater. 2. Most radios today DO support non standard splits. The ones that don't are the exception to the rule. You name me one that doesn't (and I know there are a few) and I'll name you 10 that do. :-) And if you really just HAVE to use one that doesn't support it (such as an ICOM IC-2AT) then you can easily modify it to where it does. Am I out to lunch here? 3. Using a wide split with non standard freqs. would require less isolation in the form of cavities and antenna separation... thus cheaper. I always meant for the idea to be used for full duplex digipeaters (nodes) not as a store and forward system. 4. I am going to jibe you a little here.... "A repeater is a repeater and should follow standard splits". Who says so? I would rather break away from the conventions of voice systems rather than follow them. It's like using 200 Hz shift on HF packet... 600 would work better, so why not use it? After all, guys that are talking on simplex could easily find some unused repeater to use instead, and think how happy they would be! (That's a joke, no flames, no flames :-) Lastly and as an adjunct, have you read about the proposed idea of using DAMA (Demand Assigned Multiple Access) instead of CSMA on packet radio? The idea seems to have merit and solves the problems of hidden transmitters in a much more elegant fashion than a duplex digi... although I agree that duplex systems are pretty slick. Mark Bitterlich WA3JPY@WB4UOU-1 mgb@tecnet-clemson.arpa ------------------------------ End of PACKET-RADIO Digest ******************************