---------------------------------------------------------------------------- TAPR -- Packet Status Register -- Electronic Edition TAPR News Service PSR #55, Summer, 1994 ---------------------------------------------------------------------------- Packet Status Register Issue Number 55, Summer 1994 Published by Tucson Amateur Packet Radio Corporation Contents: President's Corner DSP-93 Project and Sale AN-93, a low-cost HF modem BBS-SIG Report Automatic Control for HF Digital Communications Message Forwarding in Amateur Service Cellular used for Emergency Communications Non-Tech Topics Primer on Network Reliability Review of ICOM's IC-820H Broadcast Protocol using Negative Acknowledgement TAPR Technical Support Group TAPR Technical Support Policy Update on RUDAK-U Project Network Enhancements in the CT/NJ/NY Region ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Copyright 1994, Tucson Amateur Packet Radio Corporation TAPR gives permission to all clubs and organizations to reprint any of the information contained in this electronic issue of the PSR. Please attach the following tag with any materials used from this issue: Reprinted from: TAPR News Service, PSR #55, Summer, 1994 Please attach the following to the end of all articles and information used: TAPR membership costs only $15/year (U.S. members)! Visa/MC accepted. Call (817) 383-0000 and join TAPR today! ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Tucson Amateur Packet Radio Corp Director/President: Greg Jones, WD5IVD Director/Vice President: Keith Justice, KF7TP Director/Secretary: Gary Hauge, N4CHV Director/Treasurer: Jim Neely, WA5LHS Director/PSR Editor: Bob Hansen, N2GDE Director: Ron Bates, AG7H Director: Jack Davis, WA4EJR Director: John Koster, W9DDD Director: Mel Whitten, K0PFX For more information regarding the Tucson Amateur Packet Radio Corp write to: TAPR, 8987-309 E Tanque Verde Rd #337, Tucson, Az, 85749-2544 or call (817) 383-000 or fax (817)-566-2544. ***************************************************************************** President's Corner It's been yet another busy quarter with projects, the FCC notices and rulings coming out, organizational issues, and lots of planning. I will hit briefly on some of the organizational issues and then cover the more troubling things -- regulatory issues. The regulatory issues at work could eventually undermine how we enjoy our hobby. So, let's start with the more pleasant things. DSP-93 The DSP-93 project is about to wrap up and start into the production phase. As you can see from the announcement, kit sales are under way. For the price, this unit looks like it will do a lot of things and bring to a close over seven years of various work and effort by both AMSAT and TAPR. This project would not be finishing up if it were not for the great effort put forth by Bob Stricklin, N5BRG. Bob has committed uncounted hours to the project since early 1993. The beta-test group is off doing some hard work and it looks like they are working out all the kinks in what future builders will encounter. Without their efforts, the eventual kit would be much more difficult to construct and get operational. To avoid congestion at the TAPR office, the ordering will take place in batches, and we will take only as many orders for kits that have been allocated in the current batch. If you get in late in the order process, the worst that will happen is that your kit won't be available until the next batch. Also -- since the office has two phone lines, more people will be able to get in and leave orders on the voice system, without actually having to talk to someone about their order. Don't forget, you can FAX your order in as well. I am looking forward to seeing great interest in the DSP-93 and the start of an open architecture design that will allow the DSP-93 to meet untold Amateur needs in the future without having to wait months or years for DSP code development from within closed groups. I believe the wait has been worth it. AN-93 In the May QEX, Johan Forrer, KC7WW, published an HF digital modem design. We approached Johan about doing his design as a kit, and since his design was turn-key and only needed to be kitted in a cost effective manner, the TAPR board decided to do 100 kits to see if there was as much interest as we think there is for this kit. We hope this becomes a long term kit for TAPR, since it opens up HF digital communications for considerably less than what a multi-mode controller costs. We will also be working with Johan in the future on some of his other digital projects. We hope Johan becomes an active designer within TAPR. SIGs The Special Interest Groups are having varying degrees of success. The NET-SIG is generating a lot of discussion, and with time, should produce some interesting monographs. Dave Wolf, Chair of the BBS-SIG, is looking for someone to take over the group. Dave is very busy with work and wants to find someone that will be able to devote more time than he can. I would think that from the 3500+ BBS sysops in the US, a BBS-SIG will eventually be very active. Dave needs help right now from someone to oversee the Internet SIG mailing list and start working on discussion to get closure on various issues. Dave can be contacted through the TAPR office, if you don't have his address or phone. The FCC Regulatory Committee has been busy working on several regulatory issues, but there have been a few sidetracks the past month, with various folks' work schedules and commitments having slowed things down. We are working on establishing an HF Digital SIG to discuss HF digital matters. More information on that as it develops. Advertising Just to prepare you ahead of time, the next issue of the PSR, Winter #56, will contain advertising. This is a result of a decision made at the 1994 TAPR Board of Directors meeting. With the help of Maingate Resources we are proceeding to implement the Board's decision. The main reason for implementing this is to make the PSR a self-supporting publication, and thus allow TAPR to utilize that portion of the members' yearly dues in other areas. We hope that the various advertisers will bring needed products to the membership. If an advertiser is interested in advertising in the PSR, they should contact Maingate Resources, (817) 295-6222. Also, if you use an advertiser seen in the PSR, be sure to mention that you saw their ad in PSR. Be sure to see this said again next issue (grin). Regulatory Issues Now to the more troubling trends in Amateur radio. There has been a lot of FCC happenings since the last issue. Several are reprinted in this issue. These issues deal with: Allocation of Spectrum Below 5 GHz transferred from Federal Government Use, Authorization of Automatic Control for HF Digital Communications in Amateur Service Proposed, and Commission Amends Rules Concerning Message Forwarding Systems in the Amateur Service. Each of these affects the future of how we operate Digital Communications. Let's hit the most important in terms of long-term impact. In February, the NTIA (National Telecommunications and Information Administration) posted a notice, entitled Preliminary Spectrum Reallocation Report, which was prepared pursuant to Title VI of the Omnibus Budget Reconciliation Act of 1993. In that Act, Congress mandated that the U.S. Government reallocate to the private sector 200 MHz of spectrum below 5 GHz, 100 MHz of it below 3 GHz. Since Amateur Radio's use of the microwave bands is on a secondary basis to Government applications, mostly military, this proceeding will have a significant impact on our future access to these frequencies. From this, the FCC issued ET Docket No. 94-32, Allocation of Spectrum Below 5Ghz transferred from Federal Government Use. The spectrum identified for reallocation by the Department of Commerce is the 50 Megahertz at the bands 2390-2400 Mhz, 2402-2417 MHz, and 4660-4685 Mhz. Comment date was June 15th with reply comments by June 30th. We haven't seen all the comments and replies as of this writing. The goal of this 'sale' or 'redistribution' of frequencies is to ensure spectrum for new services and the enhancement of existing services. Some independent analysis estimates that the FCC will raise several billion dollars in the sale of the first half of these frequencies now and probably double the amount when the rest of the frequencies are auctioned off in the upcoming years. This is the first of the great rush on frequencies which represent the future of many of our digital and other Amateur modes. There is not much hope to save it, since we are now competing with companies and groups that have several million to drop on small portions of the bands being 'redistributed,' that we have taken for granted these last few decades. AMSAT has done well in getting the FCC to acknowledge the importance of satellite sub-bands, but we have a lot of work to do in order to try to ensure some future on these higher bands for any of our Amateur modes. The scenario which scares me is that we will be unable to be assigned as primary on any of the bands, so that within 5-10 years the commercial operators in larger metropolitan areas will request that all Amateurs vacate those portions of the bands, since we will be secondary and thus interfering with their primary allocations. This would be the loss of almost all of our frequencies where some rather unique development is taking place. I believe that the only long-term plan that will save any of the higher bands being 'redistributed' is to ask the FCC for Amateur preserves. Think of them as national parks for public recreation. Not just for digital communications but for all modes. We don't really need all of the frequencies that are being 'redistributed,' but we sure need more than zero MHz. This is almost certain in the future if we continue as secondary allocations. We somehow have to be assigned small primary allocations on each of the bands, so that we can continue the development of technology that has already produced: MicroSats, packet radio, and much more. All of these advances in the radio art have been directly transferable to commercial technology and have generated many new markets. Many have said that Amateur radio should fold up and go home, since many of the things that make Amateur radio unique can be attained by cellular, PCS, and other such technologies. Amateur radio is currently and has been in a paradigm shift for the last several years. We will either find a new definition of Amateur radio and a niche where it will continue to grow and prosper or it will eventually become something else -- which is possibly not having Amateur radio at all. A good example of this was the recent agreement between McCaw Cellular Communications Inc., AT&T and the American National Red Cross. I am including the press release in this issue in case you have not read it. This is the future. More like this to come. Amateur radio will no longer be able to continue to provide services that are better offered by this type of technology. We can no longer try to validate our presence on frequencies based on methods of operations developed in the first half of the century. Before the 1950s, the Amateur community was made up mostly of experimenters. Since then the trend has been away from experimentation towards more operational type activities. Much of this has to do with the enhancement of technology and the opening of Amateur radio as a viable commercial market. As the Amateur radio market expanded, more folks needed to be reached, so more and more 'consumers' were brought into the Amateur hobby. This continued the deterioration of the number of experimenters within the hobby. Now, will a manufacturer make a radio for these higher bands in order to grow a market for Amateurs when they can hold off on equipment development for several years and then sell the same equipment to commercial buyers for two or three times what Amateurs would pay -- easy answer 'No.' One possibility is that we will lose our higher bands because Amateurs no longer experiment with technology in large enough groups to provide the critical mass necessary to create a market. The 2-meter band in the 70's and 80's is a good example of this -- Amateurs experimenting and making a market that is now significant. We have no burgeoning systems on 23cm or other like bands, since the technology is rather hard to deal with and very few are doing it. Why do something hard, when you can buy inexpensive equipment ready to go for 2-meter or 70cm? With few radios being available for these higher frequencies, no Amateurs are on them to make us viable to keep these now highly sought after and expensive resources. The future is indeed bleak. It might be UHF and above now, but the pressure will be on all of our frequencies eventually. We are using 'BILLIONS' of dollars of spectrum for recreation, and the warships are about to sail over the horizon and blow us from the water. TAPR will continue to work on the FCC frequency issue in conjunction with others in order to try to secure some amount of primary space we can call our own and not have to worry about investing in infrastructure only later to be asked to remove ourselves, because we are interfering with the primary occupant. Now the other two FCC issues. The HF proposal is good news. I will wait some more and see what kind of comments are made, but my hat is off to both the ARRL and ADRS for their effort in bringing this issue forward. The ruling is a mixture of the best of both worlds. I believe that the sub-band concept was proposed initially by Lyle Johnson, WA7GXD. In effect, the ruling states unlimited automatic operations can occur in one sub-band on each HF band and unlimited semi-automatic operations on any portion of the HF bands that allows data transmission. Two potential problems could be that the defined narrow regions for fully automatic operations are possibly too narrow and the limitation of '500 Hz' for semi-automatic operations reduces the possibility of future digital modes. The HF STA, which was initially for packet networking on HF, proved that the nature of automatic forwarding worked successfully, but if these regions are so limited as to cause so much congestion from several modes trying to utilize it, then no one will be able to communicate. Thus, everyone will operate semi-automatic. Maybe not a problem? Also, I can see why 500Hz would be chosen, but that does indeed limit future modes that might operate at much higher speeds, but take up more than 500Hz. If someone can operate at 9600bps in 2Khz or 3Khz, wouldn't that be better than operating longer within 500Hz? The last issue deals with the ruling of Message Forwarding Systems in the Amateur Service. I believe that Phil's petition for reconsideration covers all the points I could make and had hoped TAPR's Regulatory Committee would have filed within the deadline. Why is Amateur digital communications continuing to be held to higher standards than other Amateur modes? The originator of messages should be the only one held accountable for message content. That does not mean that with a BBS store-and-forward system, the first forwarding station operator should not review all incoming messages to help eliminate any problems, but the ruling is specific to one type of technology and does not address more advanced systems. Is this good or bad? Who can tell -- depends on further interpretations. A question I keep asking myself is why is Amateur radio, which is licensed, constantly being highly regulated, while Part 15 operations, which are non-licensed, have few regulations? Somehow Amateur radio has gotten into this mode of having the FCC continuously regulate what we can do, instead of setting very broad definitions and allowing us to self-regulate ourselves. Self regulation is supposed to be one of our strong points - right? The ruling at least helps eliminate everyone in the current BBS forwarding system from getting fined, but still leaves one operator, spending lots of time and money to provide a resource to their local ham community to face legal action based on someone else's illegal use. Why is this different from repeater networks or any other Amateur mode? These regulations are based on one or two occurrences over long periods of time, while the current digital store-and-forward network itself handles thousands of messages daily without problem or rules violations. Very troubling. If you have comments on these issues, please let me or the TAPR Regulatory Committee know. We need the membership's input on these issues to ensure that TAPR is going down the correct paths. Till next quarter, and 150+ DSP-93 kits later. ************************************************************************** Greg Jones, WD5IVD DSP-93 The TAPR/AMSAT Joint DSP Program Announcement of Kit Sales In July 1988, TAPR and AMSAT entered into the Joint DSP Program, in order to fund the development of an eventual DSP unit for Amateur usage. As of the 1993 Dayton HamVention, the direction of development was focused on a modular, standalone DSP system proposed by Bob Stricklin, N5BRG, in Dallas, Texas. The Stricklin KISS design, later renamed DSP-93, offers many of the things that the original project specified. Fifteen months after the decision was made to proceed with DSP-93 development, TAPR and AMSAT are both proud to announce that orders for kits will be accepted from July 15th through August 31st, for the first 150 units. The DSP-93 will be supplied as a complete kit (including box and power supply). For those not wanting to build a kit, there are several preassembled DSP units on the market today. Ads for these units can be found in various publications. It is our hope that the TAPR/AMSAT joint DSP-93 project will expand the use of DSP in the Amateur community and become a tool for education. DSP-93 Design The DSP-93 is designed to provide radio Amateurs the wonderful capabilities of Digital Signal Processing in a stand-alone low-cost design. Not just limited to one mode, the DSP-93 can support data, audio, and video modes with the proper software. DSP-93 has been designed in a modular fashion with two four-layer boards using an interconnecting bus structure. The basic system includes a DSP engine board and a radio/computer interface board. The DSP Engine, bottom board, contains the TMS320C25 DSP, 32K by 16 bits of program and data memory (upgradable to 64K), the clock circuitry (40Mhz), and some programmable array logic for system I/O. The Radio/Computer Interface Board, top board, contains two eight-pin female mini-DIN connectors for radio interfacing. Incoming radio signals pass through a voltage divider to establish the initial levels, then through an eight-channel multiplex chip. The multiplex chip then feeds the single A/D input with either of the two radio inputs or one of the six auxiliary inputs. The Texas Instruments TLC32044 Analog I/O chip is used, which samples and updates at a rate of up to 45K operations per second and includes aliasing filters. This board also communicates to your computer at speeds up to 19.2K baud using a serial connection. The modular design of the DSP-93 allows for either of these boards to be replaced with future boards designed for any number of unique applications. It's sort of like adding a new application card to a PC without redesigning the complete PC. The block diagram shows how the DSP-93 is interfaced. Basic Software Suite The initial offering of the DSP-93 will contain the following software: 1200 baud AFSK, 300 baud AFSK, 1200 PSK, 9600 FSK terrestrial, 9600 FSK full-duplex for satellite operations, and various audio filters. These have been developed, tested, and have been in use during beta-testing. Software currently under test, which may or may not be released with the first batch of kits include: APT, Digital Oscilloscope, SSTV, and HF modes. User interface software for DOS and Windows is also under development and testing. Future software will be distributed on the Internet, CompuServe, Amateur Satellites, and other systems, as well as being made available on disk as part of the TAPR software library. The idea of software for the DSP-93 is to make it as easy as possible to get and upgrade software in the future. Since the DSP-93 is an open architecture, it is hoped that as more Amateurs get their units, more software will be developed and distributed. Code Development A low cost shareware assembler is available for code development. To develop code for this board, you must have good reference material. You can find numerous books on DSP algorithms and developing DSP code. Manufacturers' data sheets and books about the complex chips will also be good reference materials. All the details needed to write DSP code will be supplied with the kits. To make this project a bigger success, more people are needed who want to learn about developing DSP applications, networking, and converting from the real linear world to the digital world. Ideally, everyone taking the challenge will select a particular idea and become so focused in the application that they become the expert. Some of the areas for development might include: new modulation techniques, speech synthesis, filters, spectrum analyzers, and many more applications you will think of. If you choose to work on the hardware aspects of this project, the modular approach should allow you to convert to other DSP chips or Analog I/O chips or to add additional capability. Future Options High Speed Radio Interface The High Speed Radio Interface board is a second radio interface board under development which has higher speed analog I/O chips. In general, its functionality is just like the Radio Interface Board, except that it contains the Burr Brown DSP101 Analog to Digital converter (used for input data) and the Burr Brown DSP201 Digital to Analog converter (used for output). The A/D chip is capable of 200K samples per second with eighteen bits of resolution and the D/A chip can attain 300K updates per second with eighteen bits of accuracy. No date of release or cost has been set at this time. Network Interface Board The Network Interface Board is intended to support higher speed modes which require moving large amounts of data to the computer faster than a serial port can handle. A National Semiconductor ST-NIC chip was selected for the task. The ST-NIC is working in the eight-bit mode. An 8K Static RAM buffer is included for network packets. The DSP-93 will be able to read and write to all the registers of the ST-NIC. This high speed data interface will be an advantage when dealing with video applications. The ability to utilize the card in a network environment will be limited and is intended to work only at a NETBIOS level with a very simple structured DSP protocol. The success of the network board will depend on the available DSP cycles left over between A/D samples after all other tasks are completed. No date of release or cost has been set at this time. TNC Interface Board The TNC Interface Board can be placed inside the DSP-93 for the decoding of HDLC frames for packet radio applications. The board provides the basic functionality required of a TNC as a low-cost option for those that require one entire unit, instead of hooking their DSP-93 to an existing TNC at the station. No date of release or cost has been set at this time. Project Team Much of the development and current success of the DSP-93 project can be attributed to the designers, developers, and testers. Designer: Bob Stricklin, N5BRG. Project Managers: Bob Stricklin, N5BRG and Greg Jones,WD5IVD. Joint DSP Project Officers: Robert Diersing, N5AHD (AMSAT) and Greg Jones, WD5IVD (TAPR). The Alpha-Team: Bob Stricklin, N5BRG, Frank Perkins, WB5IPM, Jon Bloom, KE3Z, Lon Cecil, WB5PKJ, Tom McDermott, N5EG, Robert Diersing, N5AHD, UoSAT/Doug Loughmiller, K05I/G0SYX, John Conner, WD0FHG, Greg Jones, WD5IVD, and Bill Reed, WD0ETZ. The Beta-Team: Jack Davis, WA4EJR, Paul Beckmann, WA0RSE, Scott Zehr, K9GKC, Ron Parsons, W5RKN, Jim Tittsler, 7J1AJH/AI8A, Michael Zingman, N4IRR, Stan Salek, KD6CVL, Mark Hammond, KC4EBR, Marcel Losekoot, Bill Beech, NJ7P, Gould Smith, WA4SXM, Roy Welch, W0SL, Greg Ratcliff, Brian Straup, NQ9Q, Doug Howard, KG5OA, and Robert Greenfield, VE3DSC. Any of the project members welcome questions about their work and involvement. If you know someone on this list, please ask them about their unit and how it operates. Personal contact with testers is one of the best ways to determine the unit's possible usefulness in your shack. Many of the testers are active on the satellites. Ordering your Kit The DSP-93 will sell for $430 as a complete kit, including enclosure and power supply. TAPR kits can be complex depending on the kitting experience of each builder. We don't think you will have trouble with the DSP-93 kit, but it does require some knowledge and experience to successfully go from a kit to a finished, usable unit, depending on the mode of operations. For data radio applications (i.e. 9600 baud FSK), special modifications must be made to your radio for proper operation of the DSP-93. Unlike other TAPR kits in the past, only the interface to the radio and the serial cable to the computer (DB-9) will be the responsibility of the kit builder. All other parts will be in the kit ready for complete assembly. Due to the cost of each unit, TAPR and AMSAT are unable to fund the total cost of inventory that may sit idle on the shelf for months. Neither organization can sustain such an investment at this time, with AMSAT Phase IIID developments and other such TAPR projects ongoing. To avoid this cost, TAPR and AMSAT are requiring that kit purchasers provide VISA/MC information or checks/money orders with their initial purchases. Money for the initial kit purchase will be deposited on September 15th, 1994 to cover kitting costs, with kits being shipped beginning November 15th. If kits are available before November 15th, they will be shipped when available. Orders will be taken for the first 150 units. If more than 150 units are ordered, then a second or third batch will be done as soon as additional parts inventory can be purchased and kitted. In this way, the DSP-93 kit will be provided in the exact numbers required for the demand. Many of the parts in the DSP-93 have between 10-15+ weeks of lead time and have already been ordered for delivery by the end of September. After this initial kit offering, DSP-93 kits will be provided in batches as the demand warrants doing kits. The initial batch of kits will be as large as the demand requires, which we hope is large. The more the merrier! DSP-93 orders for the initial purchase will be taken from July 15th through August 31st, 1994. Orders can be mailed to the TAPR address: 8987-309 E. Tanque Verde Rd #337, Tucson, Az, 85749-9399, call (817) 383-0000 (Office Hours: Tue-Fri, 9am-12noon, 3pm-5pm Central Time), or fax (817) 566-2544. If you have questions concerning the unit, please write or call TAPR for an information pamphlet. The pamphlet will also be made available via fax through the TAPR voice system. Note to TAPR members: Since this is a joint project, this kit will not have a membership discount attached. References Stricklin, Bob. (1994). TAPR/AMSAT Joint DSP Project: DSP-93. Proceedings of the TAPR 1994 Annual Meeting. Tucson Amateur Packet Radio Corp. Stricklin, Bob and Greg Jones. (1993). TAPR/AMSAT DSP-93 Project. Proceedings of the 1993 AMSAT-NA. AMSAT. Stricklin, Bob. (1993). DSP-93: The Joint DSP Program (TAPR/AMSAT). Issue #52, Fall 1993, Packet Status Register. pp. 4-5. Tucson Amateur Packet Radio Corp. ************************************************************************ Introducing the AN-93 TAPR Kit A low cost HF modem kit for RTTY, AMTOR, and Pactor applications. TAPR is proud to introduce a limited run (starting in September) of a kit designed by Johan Forrer, KC7WW. The AN-93 kit provides any PC user with the capability of operating RTTY, AMTOR, and Pactor with this simple modem-only design. AN-93 is the equivalent of a BayCom, BayPac, or PMP setup, but for HF digital operations. Johan developed this board in 1993 and published the design in the May 1994 QEX. Based on that article, we contacted Johan about doing his kit. This very simple kit is for the many that have wanted to play on HF, but didn't want to pay the money for an expensive multi-mode controller. TAPR will be doing a limited run of 100 AN-93 kits. This is not a beta-test, but a market test to see what the level of interest is in this kit design. With the AN-93, only three components are required for HF digital communications: a PC-compatible computer, the AN-93 modem, and software that performs the encoding and decoding. The AN-93 comes with a tuning indicator to allow visual tuning and the unit also provides audio output for an oscilloscope display. The TAPR AN-93 consists of one combined board, instead of two separate boards as shown in the QEX article. This was done to reduce the cost of board production. The combined board dimension is approximately 4" x 3.5", so many common boxes will fit. TAPR still has a few Mouser 40UB102 boxes remaining; these were used for the PSK modem kits, but will hold the AN-93 kit as well. Half of the board is the demodulator and the other half is the tuning display and A/D convertor. Connections to the RS-232 serial and parallel ports are made through a 14-pin connector located on the display portion of the board. The AN-93 currently requires 9 volts @ 150mA, but the final kit may allow for 12 volts. Interfacing to the radio is through a DB-9; the RJ-11 receptacle was replaced to reduce kit cost. After the board is built, the filters must be aligned. TAPR is providing a simple method of generating these tones to allow simple tuning as part of the kit. The kit will be shipped with the A/D converter providing full-memory ARQ capability for Pactor. The TAPR version of the kit will provide both FSK and AFSK outputs for use with more common Amateur HF radios. Modem Specifications: AGC at 100-mV audio input amplitude Prefilter bandwidth 1 kHz Discriminator channel filter bandwidth 120 Hz 170-Hz channel separation Data low-pass filter cutoff 200 Hz Automatic threshold corrector Tuning indicator A/D converter for "soft" error correction Shareware software is included along with Johan's code. If you decide to use the shareware software, TAPR requests that you do submit the necessary registration fee to the author (not to TAPR). As of this printing, it has not been determined if the box can be included in the final price of the kit. The cost of the kit is currently estimated to cost $90. Kits should be available the first of September. If you are interested in getting an AN-93 kit when it is available, call the TAPR office to place your name and address on a mailing list so TAPR can contact you when the kits are ready to go on sale. For a full description of the AN-93 modem and its specifications, refer to the May 1994 issue of QEX. ************************************************************************* BBS-SIG Dave Wolf, WO5H Packet:WO5H@WO5H.#DFW.TX.USA.NOAM Internet: dwolf@tcet.unt.edu The next in-person session of the TAPR BBS-SIG will be at the upcoming ARRL DCC in Bloomington, Minnesota, August 19-21. If you are a packet BBS sysop (any flavor of BBS, including the NOS variants), make plans to participate! Speaking of participation, the BBS-SIG is a great way to get more involved with TAPR and packet issues, if you're so inclined. I suspect that the TAPR BBS-SIG has been sort of a well-kept secret, but this hasn't been intentional. It is possible that relatively fewer BBS-types have access to the Internet than other packet hackers. If you DO have Internet access, when you receive a TAPR-BB, BBSSIG or NETSIG bulletin that lends itself to being ported to the Amateur packet network, please PORT IT! Be sure to include the unique BID (if you use the IMPORT function of your software, this will be automatic) to avoid the creation of a dupe. You don't know how to use the IMPORT function of your BBS software? Get on BBS-SIG and ask. That's one of the reasons BBS-SIG is there! What's been happening with the BBS-SIG lately? It's been a quiet summer so far. The concept of creating a TAPR BBS Guide (that idea came from the Dayton BBS-SIG meeting) seems like a constructive way to jump start lots of struggling sysops. You don't have to be a 'newbie' to be struggling, either! The Guide would include recommended 'TO' and '@' fields, too. If you would like to participate and can make the commitment to do so, please get in touch with me. ************************************************************************* Authorization Of Automatic Control For HF Digital Communications In Amateur Service Proposed (PR Docket 94-59) The Commission has proposed amending the amateur service rules to authorize automatic control of stations transmitting a digital emission on the High Frequency (HF) amateur service bands. This action was requested in petitions filed by The American Radio Relay League, Inc. (ARRL), and the American Digital Radio Society, Inc. (ADRS) The propagation characteristics of the HF bands allow for long distance communications. Amateur operators take advantage of these characteristics to communicate with other amateur stations all over the world. Establishing and maintaining a HF communications link, however, presents operating demands not encountered on the Very High Frequency (VHF) and higher frequency bands. The variables affecting communications in the HF bands are highly complex. To maintain the communications link and avoid causing interference to the communications of other amateur stations, the control operator constantly monitors the activity on the channel being used and adjusts the station's transmitting parameters as needed. Because the presence of the control operator has been necessary for proper operation in these systems, automatic control of an amateur station that is transmitting on any HF band or on the 160 meter MF (medium frequency) band has not been authorized. In 1986 the Commission authorized automatic control of amateur stations transmitting digital communications on the VHF and higher frequency bands and indicated it was interested in authorizing automatic control of stations using the HF bands. To determine solutions to the problem of avoiding interference from automatically controlled HF digital stations, the ARRL conducted a successful feasibility project under a special temporary authority the Commission granted to 50 amateur stations. The ARRL's petition is based on the results of that study. The ADRS's petition contained an additional recommendation from amateur operators who have been experimenting for several decades with digital communications on the HF bands. The Commission said it was gratified by the cooperation and dedication of organizations within the amateur service community in determining the conditions necessary to allow automatic control of stations transmitting data and RTTY (narrow-band direct printing) emission types on the HF amateur service bands. It agreed with the petitioners that automatic control of amateur stations in the HF bands can, with safeguards, make the transmission of data and RTTY emission types practical and effective. Therefore, the Commission proposed to authorize automatic control for stations transmitting data and RTTY emission types on one specific subband of each HF band where such emissions are authorized. It also proposed to authorize communications between a locally or remotely controlled station and an automatically controlled station on any frequency where data and RTTY emission types are otherwise authorized. The Commission said that it firmly believes in the principle that government should be responsive to user needs. It noted that the rules it proposed were the result of a successful feasibility project planned and carried out within the amateur service community and represent the recommendations of two organizations dedicated to bringing the benefits to be derived from the transmission of digital communications on the amateur service HF bands to amateur operators in the United States and elsewhere without causing unnecessary interference to other types of communications. Proposed Changes Part 97 of Chapter I of Title 47 of the Code of Federal Regulations is proposed to be amended as follows: 1. The authority citation for Part 97 would continue to read as follows: Authority citation: 48 Stat. 1066, 1082, as amended; 47 U.S.C. 154, 303. Interpret or apply 48 Stat. 1064-1068, 1081-1105, as amended; 47 U.S.C. 151-155, 301-609, unless otherwise noted. 2. Section 97.109 is amended by revising paragraphs (d) and (e) to read as follows: 97.109 Station control. (d) When a station is being automatically controlled, the control operator need not be at the control point. Only stations specifically designated elsewhere in this Part may be automatically controlled. Automatic control must cease upon notification by an EIC that the station is transmitting improperly or causing harmful interference to other stations. Automatic control must not be resumed without prior approval of the EIC. (e) No station may be automatically controlled while transmitting third party communications, except a station transmitting a RTTY or data emission. All messages that are retransmitted must originate at a station that is being locally or remotely controlled. 3. Subpart C of Part 97 is amended by adding new Section 97.221 to read as follows: 97.221 Automatically controlled digital station. (a) This rule section does not apply to an auxiliary station, a beacon station, a repeater station, an earth station, a space station, or space telecommand station. (b) A station may be automatically controlled while transmitting RTTY or data emissions on the 6 m or shorter wavelength bands, and on the 28.120-28.189 MHz, 24.925-24.930 MHz, 21.090-21.100 MHz, 18.105-18.110 MHz, 14.0950-14.0995 MHz, 14.1005-14.112 MHz, 10.140-10.150 MHz, 7.100-7.105 MHz, or 3.620-3.635 MHz segments. (c) A station may be automatically controlled while transmitting a RTTY or data emission on any other frequency authorized for such emission types provided that: (1) The station is responding to interrogation by a station under local or remote control: and (2) No transmission from the automatically controlled station occupies a bandwidth of more than 500 Hz. Commission Amends Rules Concerning Message Forwarding Systems In The Amateur Service (PR Docket 93-85) The FCC has relaxed the amateur service rules to enable contemporary message forwarding systems to operate at hundreds of characters per second while retaining safeguards to prevent misuse. A message forwarding system is a group of amateur stations participating in a voluntary, cooperative, interactive arrangement where communications from the control operator of an originating station are transmitted to one or more destination stations via forwarding stations, which may or may not be automatically controlled. Currently, the control operator of each station is held individually accountable for each message retransmitted, resulting in unnecessary content review and delays. The American Relay League, Inc. (League) stated that the obligation of the control operator of the first forwarding station should be the establishment of the identity of the station originating the message. Only when this is not done should these control operators be held accountable for improper message content. Also, there are currently no central supervisory authority in an ad hoc amateur service digital network, making these unsupervised systems easy targets for misuse by uncooperative operators and non-licensees. Moreover, the Commission said that it could be difficult to establish after the fact that a particular VHF station originated a fleeting high speed digital transmission. For these reasons, the Commission said there must be on-going oversight of the system and the control operators of the first forwarding stations are in the best position to provide such oversight. Therefore, the Commission will hold accountable only the licensees of the station originating a message and the license of the first station forwarding a message in a high speed message forwarding system. The licensee of the first forwarding station must either authenticate the identify of the station from which it accepts communications on behalf of the system, or accept accountability for the content of the message. The Commission also clarified that the station that receives a communication directly from the originating station and introduces it into the message forwarding system is the first forwarding station. The League and the Colorado Council of Amateur Radio Clubs suggested that the Commission substitute the word "simultaneously" for "instantaneously" in the redefinition of a repeater. The Commission concurred and adopted this modification. The Commission believes that these rule changes will enable contemporary high speed message forwarding systems to operate as their designers intended, while retaining the minimum safeguards necessary to prevent misuse. Rule Changes Part 97 of Chapter 1 of Title 47 of the Code of Federal Regulations is amended as follows: Part 97-Amateur Radio Service 1. The authority citation follows: Authority: 48 Stat. 1066, 1082, as amended; 47 U.S.C. $$ 154, 303. Interpret or apply 48 Stat. 1064-1068, 1081-1105, as amended; 47 U.S.C. 151-155, 301-609, unless otherwise noted. 2. Section 97.3 is amended by redesignating paragraphs (a)(28) through (a)(44) as paragraphs (a)(29) through (a)(45), respectively, adding a new paragraph (a)(28), and revising paragraph (a)(7) and redesignated paragraph (a)(36) to read as follows: 97.3 Definitions. (a)(7) Auxiliary station. An amateur station, other than in a message forwarding system, that is transmitting communications point-to-point within a system of cooperating amateur stations. (a)(28) Message forwarding system. A group of amateur stations participating in a voluntary, cooperative, interactive arrangement where communications are sent from the control operator of an originating station to the control operator of one or more destination stations by one or more forwarding stations. (a)(36) Repeater. An amateur station that simultaneously retransmits the transmission of another amateur station on a different channel or channels. 3. Section 97.109(e) is revised to read as follows: 97.109 Station control. (e) No station may be automatically controlled while transmitting third party communications, except a station participating as a forwarding station in a message forwarding system. 4. Section 97.205 is amended by adding new paragraph (g) to read as follows: 97.205 Repeater station. (g) The control operator of a repeater that retransmits inadvertently communications that violate the rules in this Part is not accountable for the violative communications. 5. Section 97.216 is redesignated as Section 97.217. 6. Section 97.219 is added to read as follows: 97.219 Message forwarding system. (a) Any amateur station may participate in a message forwarding system, subject to the privileges of the class of operator license held. (b) For stations participating in a message forwarding system, the control operator of the station originating a message is primarily accountable for any violation of the rules in this Part contained in the message. (c) Except as noted in paragraph (d) of this section, for stations participating in a message forwarding system. the control operators of forwarding stations that retransmit inadvertently communications that violate the rules in this Part are not accountable for the violative communications. They are. however, responsible for discontinuing such communications once they become aware of their presence. (d) For stations participating in a message forwarding system, the control operator of the first forwarding station must: (1) Authenticate the identity of the station from which it accepts communications on behalf of the system; or (2) Accept accountability for any violation of the rules in this Part contained in messages it retransmits to the system. ************************************************************************* Petition for Reconsideration of the Commission's Rules Concerning Message Forwarding Systems in the Amateur Service (PR Docket 93-85) Phil Karn, KA9Q Petition For Reconsideration Although the Commission's ruling is a welcome improvement over the previous state of affairs in which every station in a network of automatic message forwarders was held accountable for message content, it is nonetheless flawed and should be amended. In particular, the requirement that the "first forwarding station" either authenticate the identity of the originating station or take responsibility for message content is unworkable. The Commission has implicitly assumed a specific architecture for the message forwarding system that is rapidly being overtaken by new systems that render the concept of "first forwarding station" largely meaningless. The present message forwarding network consists predominantly of "packet bulletin board systems" accessed interactively by end users with relatively simple stations. Many of these user stations are either wholly non-computerized (e.g., a "dumb terminal" connected directly to a Terminal Node Controller, or TNC) or use personal computers merely to emulate such a function. Although this may indeed be the prevalent practice today, the increasing availability of substantial computer power to end users is causing the amateur packet radio network to evolve rapidly toward more capability at the user stations, with less in the network itself. This closely mirrors similar trends in non-amateur computer networks, particularly the Internet. The Commission apparently did not consider these issues in its decision, hence the need for this petition for reconsideration. Two examples make this clear: the rise of "personal BBSes" and the amateur TCP/IP network (TCP and IP are the core protocols of the Internet). The personal BBS is just like a multi-user BBS, except that it is operated by and on behalf of only a single local user. In other words, the user and sysop are one and the same. Among the many advantages of the personal BBS is the immediate accessibility to the local user of messages previously received automatically by the BBS, as opposed to having to read them in real time across a slow and often congested packet channel. Such a personal BBS, however, looks like any other BBS to the rest of the network; the other nodes in the network will relay its traffic just as if it were a "regular" BBS. Yet the Commission's ruling and its definition of "first forwarding station" appears to require every forwarding BBS in the network to treat such personal BBSes with special scrutiny that isn't required for other BBSes that simply forward traffic from other users. Indeed, the new rule seems to require that messages from the sysop on even a multi-user BBS be treated differently from messages from other users on that system. Furthermore, consider the case where a personal BBS (or an end user with a "dumb terminal", for that matter) connects to another BBS via a digipeater, a low-level device that simply relays physical packets. This digipeater would apparently become the "first forwarding system" and would therefore have to take responsibility for the content of the traffic it relays, even though it would not have to do so for traffic already relayed by another digipeater or BBS. This is clearly unworkable. The TCP/IP network shows even more clearly the trend toward removing higher-level functions from the network itself and pushing them toward the "edges" of the network. In a TCP/IP network, every user system provides functions analogous to the BBS, only much more sophisticated. Besides conventional BBS functions, these systems often provide file repositories and remote access to computing facilities such as UNIX systems. Many more sophisticated applications, borrowed from the Internet as a whole, are also appearing: graphical user interfaces, powerful resource search and query tools, and so on. However, the lower level functions in the TCP/IP protocol suite performed at intermediate systems are deliberately very simple; indeed, an IP router (packet switch) is conceptually similar to (and almost as simple as) the digipeater. It is important to understand that in a TCP/IP network, all of the nodes between two end user stations (e.g., a user and a server node) are these low-level IP packet routers, and the end-to-end communications they support are real-time in nature. Furthermore, the protocols allow consecutive packets between the same end points to travel through different links and routers; the only reliable place to monitor the traffic between any pair of end points is at the end points themselves. Real-time auditing and approval of each packet is simply not practical. However, the wording of this present Order implies that the control operator of the first IP router forwarding traffic from an end user must either authenticate that user or take responsibility for the end user's traffic, even though the same router could confidently carry traffic that had already been forwarded by another router. This discrimination is wholly impractical and unacceptable; it may even be impossible. Ideally, the Commission ought to abandon all references to the "first forwarding station" and place all responsibility for message content on the originating station, which can be clearly defined as the station that first transmits the message on amateur channels. Any amateur station that relays or forwards traffic already transmitted and received on amateur frequencies, be it a repeater, digipeater, BBS, IP packet router or anything else, would not be held accountable for the content of the communication. As a possible alternative, I would be satisfied with a Commission interpretation of its ruling holding that the distinction between the "originating station" and "first forwarding station" applies only in the special case of a high level intermediate system such as a public BBS that speaks to "dumb terminals" on the user side and speaks BBS network protocols to the rest of the network. In the case of an end user system that speaks the network protocols directly (be they the BBS message forwarding protocols, TCP/IP or anything else) the originating station and the first forwarding station should be considered the same entity. Which in fact they are, since the originating station uses the same forwarding protocols as the rest of the network. I am gratified that the Commission has seen fit to grant partial relief to the rules that have so severely burdened the development of packet radio. However, I am concerned that the changes do not go nearly far enough, and I urge the Commission to reconsider its decision. I understand that the Commission strongly prefers to establish principles of broad applicability that do not have to be constantly revisited as amateur technology and practice evolve. However, this ruling has clearly violated that principle by assuming a specific architecture for the amateur packet radio network that does not accommodate even near term future trends. I urge the Commission to rectify its oversight so that it does not have to revisit this issue again in the near future. ************************************************************************** Commercial Communication Companies Agree to Provide Emergency Communications for Red Cross [from a McCaw/AT&T/American Red Cross press release] An agreement has been signed by McCaw Cellular Communications Inc., AT&T and the American National Red Cross which formalizes a long-standing relationship between the organizations to bring important wireless communications and long distance services to disaster victims. The agreement was signed at the 1994 American National Red Cross Convention in Seattle by McCaw Cellular Chairman and CEO Craig O. McCaw, AT&T Communications Services Group CEO Alex Mandl and Red Cross President Elizabeth Dole. It calls for McCaw and AT&T to rapidly provide free wireless and long distance service, cellular phones and volunteers to aid the efforts of the Red Cross's emergency response team during times of disaster. "This three-way partnership is a landmark event for us," said Dole. "Giving our emergency response teams instant access to reliable wireless and long distance communication can make a material difference in our mission of providing relief and mitigating suffering." "McCaw Cellular and AT&T have been incredibly supportive of our efforts in the past." Dole noted, "We have appreciated the relationship that has been established in so many of our 2,500 chapters as well as during disasters where they have provided relief services and free calls for people in need. We salute their efforts in this stepped up commitment to serve." Craig McCaw commented, "It's no secret to relief agencies, public safety officials and our customers that our country's wireless networks provide a reliable, durable and invaluable communications link during disasters. The lessons we have learned from working side by side with Red Cross personnel during the San Francisco and Los Angeles earthquakes, Hurricane Andrew and the Midwest flooding taught us there is a role and, in our opinion, a responsibility to put our technical and human resources to work to help our neighbors during times of disaster." "We are pleased that our phones and long-distance service will be supporting such a vital cause," said AT&T's Mandl. "The Red Cross helps so many people across the country, and assisting in its work is a great example of how anytime, anywhere communications can make the difference between life and death." AT&T, which will provide 270 cellular phones and free long-distance service, has been a long-time supporter of the Red Cross. McCaw Cellular focuses a large portion of its community relations work, corporate charity, public sector efforts and employee volunteer programs on emergency response activities. Days before the Los Angeles earthquake, for example, 150 senior managers at McCaw Cellular, including Craig McCaw and the company's president Jim Barksdale, participated in a training exercise in which they received Red Cross disaster training and lived for two days as mock victims in a temporary shelter. The training was immediately put to use during the crisis. The agreement calls for AT&T cellular phones to be given to American Red Cross chapters across the country that are located in high-risk disaster areas. McCaw, which does business across the country primarily under the name Cellular One(R), will also use AT&T cellular phones in staging centers to be established in Pittsburgh and Denver. At the centers, a large number of phones and messaging devices will be kept "hot and ready" along with extra batteries and accessories to be dispatched to an affected area. Members of the American Red Cross Quick Response Team, who are the first people dispatched to disasters, will also be armed with the phones. McCaw/Cellular One and AT&T will make staff and resources available during disasters to establish mobile calling centers near Red Cross relief shelters to enable victims to call loved ones across town or across the world. McCaw Cellular Communications Inc. (Nasdaq: MCAWA) is the nation's leading provider of personal communications services; a leader in the cellular industry's transition to digital from analog service; and a leader in the introduction of wireless data transmission. The company owns a 52-percent interest in LIN Broadcasting Corp., which is engaged in cellular telephone operations, television broadcasting and specialty publishing. McCaw Cellular is the nation's fifth largest messaging service provider and also provides telephone service for commercial and private aircraft through its ownership of Claircom Communications Group, L.P. In August 1993, McCaw announced it had reached a definitive agreement to merge with AT&T. Following regulatory approvals, the merger is expected to close by the third quarter of 1994. AT&T is the world's networking leader, providing communications services and products, as well as network equipment and computer systems to businesses, consumers, telecommunications services providers and government agencies. The American Red Cross is a humanitarian organization, led by volunteers, that provides relief to victims of more than 60,000 disasters a year and helps people prevent, prepare for and respond to emergencies. Founded in 1881 by Clara Barton, the Red Cross is an independent, not-for-profit volunteer organization that relies primarily on the generosity of Americans for support. ************************************************************************* Non-Tech Topics Phase IIID - RUDAK-U As published in the last issue, Lyle Johnson, WA7GXD, and a highly competent group in support, are developing an entire user-oriented digital package for the Phase IIID launch called RUDAK-U. TAPR will be sending out a fundraising letter the end of July in order to raise the necessary $6,000 TAPR has committed to this project. The $6,000 represents 10% of the estimated cost ($60,000) of the RUDAK-U project. TAPR is doing a fundraiser in order to collect the necessary money to help fund TAPR's portion of the project. When the Board of Directors made the decision to fund this portion of the project, it was known that if TAPR did not receive the necessary membership support for $6000 in contributions, then this year's financial bottom line would be affected in a negative way. The RUDAK-U system has the capability of providing many of the features that we were all hoping to have some day on Phase IV. What Lyle has designed has some tremendous possibilities for providing both high-speed networking between regional groups and other more advanced activities. However, this project does require money. When you get the note from TAPR asking for a small contribution, please take a serious moment and help bring this unique project to the launch pad next year. If you have contact with a regional packet organization, contact them about contributing to an eventual satellite backbone system. This is not a kit or a publication, but your contribution to this project is making possible the creation of future infrastructure needed for the advancement of many of our current digital modes. Help fund a project that will lead to many new and exciting operational possibilities! ARRL Digital Communications Conference 1995 The American Radio Relay League (ARRL) has accepted TAPR's request to co-host the 1995 Digital Communications Conference (DCC). The 14th ARRL DCC will be co-hosted by TAPR and the Texas Packet Radio Society (TPRS) in the Dallas/Ft. Worth area during September of 1995. TAPR would like to thank Tom Comstock, W5TC, and Mark Wilson at the ARRL for their support and help in getting the conference hosted in the West Gulf Division. TAPR in San Diego TAPR will be attending the ARRL Southwestern Divison Convention in San Diego, Calif., August 26-28. If you are a TAPR member and want to help out at the booth contact Greg Jones, WD5IVD, at (512) 794-0578. We look forward to seeing our various West Coast members. We will have kits and publications available as well as looking for lots of new members! TAPR to Distribute ARRL CNC and DCC Proceedings TAPR has made an agreement with the ARRL to be the distribution point for past proceedings of the ARRL Computer Networking Conference (CNC) and Digital Communications Conference (DCC) proceedings. This will apply to proceedings that are more than two years old. For example, the ARRL will continue to distribute the 12th (1993) and 13th (1994) proceedings this year, then next year, TAPR will distribute the 12th (1993). In this way, TAPR and the ARRL hope that these proceedings will be made more accessible to interested hams. Proceedings should be available from the TAPR office starting in the end of August. TAPR would like the thank Mark Wilson and Jon Bloom for their help with this arrangement. TUC-52/PCON Update The project spent the last quarter locating someone to do the board layout. Dave Dennis, N5BOC, in Dallas, has volunteered and has begun board layout. No other report at this time. Project Proposals The TAPR board has had several enquiries about project funding. All these requests have gone back to the requesters asking for a fully prepared proposal for consideration. If you have a project for the TAPR board to review for funding, request a proposal outline from the office or send Internet mail to tapr@tapr.org. Membership Growth The new and old members continue to pour in. Everyone at TAPR is very happy to see all the old members join back into TAPR and see where we are going in the future. The new member numbers also continue to increase. As was mentioned in the last issue, it is up to the local TAPR members to find and get other Amateurs in this mode to join and help support future projects and direction. As of the end of June, the TAPR membership roster has reached past the 50% point of our 2000 member goal. Just another 500-600 members are needed in order to reach this goal. Why 600? Well - TAPR will lose between 150 and 200 members from non-renewals, so it always takes more new and renewing member to make up for those that decide not to renew. If you, or someone you know, is not renewing, please let us know why, so that we can better address your needs. Packet Status Register Everyone at TAPR hopes the membership is enjoying the new look and feel of the PSR. Bob Hansen, N2GDE, has been working very hard this year in transforming the look of the PSR. We hope that changes in the future will continue to help PSR and TAPR move into a new era of development and publications. Just as a reminder, TAPR is always looking for articles every issue. PSR is a membership-oriented quarterly journal and depends on input from the entire body of those that participate in TAPR. In this way, more than just a handful can participate in what makes TAPR unique. Join the fun. ************************************************************************* A Primer On Reliability As Applied To Amateur Radio Packet Networks. Tom C. McDermott, N5EG Texas Packet Radio Society, Inc. Scope Many messages [on NET-SIG] have been sent regarding the linking of a large number of packet radio switches, nodes, digipeaters, etc. Some authors have commented on the desirability of very long packet networks. This monograph will describe how to calculate the availability of such a system, given knowledge of the performance of the equipment used. Definitiions Let's define some terms. There are 3 basic parameters that need to be known in order to make suitable calculations about network availability: MTBF = Mean Time Between Failures. This is the average (mean) time between failures of a particular piece of equipment. For example: an MTBF of 1680 hours would equate to a piece of equipment failing once every 10 weeks, on average. MTTR = Mean Time To Restore. This is the average (mean) time to restore a failed piece of equipment to service. For example: a piece of equipment with an MTTR of 8 hours implies that it takes 8 hours to: 1) notice that there is a problem, 2) diagnose the problem, 3) drive to the site, 4) repair the equipment, and 5) place it back in service. Of course the actual series of event, and the time to restore all depend on whether the equipment is accessible at any time, backup equipment that may be available, etc. A = Availability. This is the portion of time that a piece of equipment (on average) is available for use. This can be calculated as follows: A= MTBF / (MTBF + MTTR) (1) Series and Parallel Equipment There are two basic configurations of multiple pieces of equipment: 1) series, and 2) parallel. By this is meant the following: two pieces of equipment are in series if both are required to be operating correctly in order to get the job done. For example: suppose that you wanted to transmit a packet message across a 100-mile path, and there were two switches in the middle that were linked, and that the failure of either would prevent your packets from traversing the path. Then those switches, from a reliability point of view, are in series. The failure of either one of them would make the path not usable. In contrast, two pieces of equipment are in parallel when either alone is capable of getting the job done. For example: suppose that you wished to send a packet between two points that were 50 miles apart, and you had a choice of either of two switches, each of which alone was capable of making the path. Then those switches, from a reliability point of view, are in parallel. Let's use some of the basic rules of probability to derive the availability of networks of equipment that each have availability, A. Availability in series We can calculate the availability of n items, all with the same availability, A, that are in series. The combined availability is: An(ser) = An ( 2 ) For example, suppose that we have a packet network consisting of 20 nodes, that each individual node has an MTBF of 4368 hours (6 months), and an MTTR of 168 hours (1 week). Then the availability of a single node is 4368 / (4368 + 168) = 0.963 (96.3% of the time it works). The availability of a network of 20 of these nodes would be: 0.96320 = 0.470 (47.0% of the time it works). We can see that, in general, putting items in series degrades the availability. Availability in parallel We can calculate the availability of n items, all with the same availability, A, that are in parallel. The combined availability is: An(par) = 1 - ( ( 1 - A )n ) (3) For example. suppose that we have a packet network consisting of 2 nodes, with MTBF = 4368 hours, and MTTR = 168 hours, and these two are in parallel. Then the individual availability is 0.963 (as above) and the combined availability is 1 - (1-0.963)2 = 0.9986 (99.86% of the time it works). We can see that, in general, putting items in parallel improves the availability. More complex models We can calculate the availability of more complex networks by reducing them to series and parallel combinations that we now know how to handle. Sometimes, the combinations are not reducable to series-parallel combinations, but these cases are not common in Amateur packet networks. The general procedure is to break up a network into subsections that can be described as being in series or parallel. Then each subsection can in turn be broken up into smaller subsections that are in parallel and/or series, until the remaining network segments are entirely parallel or series. The availability of each subsection can be computed, and the subsection availabilities can be combined using (2) and (3) above to derive the network availability. Some more examples Let's look at a couple of example networks. Network one consists of 40 packet switches, all in series. It's a long haul network, and skinny. Each node has an MTBF of 4368 hours, and the MTTR is 332 hours (2 weeks, since the sysop left on vacation yesterday, and does so frequently! - nice work if you can get it). Then: A = 4368 / (4368+332) = 0.929 An = 0.92940 = 0.053 This network will function, end-to-end, 5 percent of the time, and will not work end-to-end 95 percent of the time. Hmmmm. Ok, let's assume that our sysop loses his cushy job, his extravagent vacation policy, etc., and can get to the site within 72 hours. Then the network availability would be: A = 4368 / (4368+72) = 0.984 An = 0.98440 = 0.520 Well, quite an improvement. The network actually works, end-to-end, 52% of the time. I guess we can all draw some conclusions about the level of service our poor sysops are going to have to provide if we want this stuff to really work. Alternatively, we could do some work up front, and build dual redundant nodes. Those are ones with hot-standby euqipment that takes over the failed equipment with no loss of service (even after lightning hits!). Let's double the investment in our network by providing dual-redundant nodes at each of the 40 sites. Incidentally, building dual-redundant equipment without (joint) failures can be no small task in itself. The availability of this network, assuming our intrepid sysop finds out that he now takes 2 week business trips all the time, can be calculated by breaking our network into some subsections. Each dual-redundant node is a subsection, and we have 40 of those subsections in series. So, first we calculate the availability of the subsection: A2(par) = ( 1 - (1 - 0.929)2) = 0.995 and then the availability of all subsections would be: A40(ser) = 0.99540 = 0.817 Well, that's more like it. This network works 81.7 percent of the time, end-to-end, and the poor sysop can actually hold down a real job now. Ahhh, wait a minute. We have twice as much equipment in the network now, and thus it seems like twice as many things would break. Well, yes. Welcome to the dark side of the force -- err, the dark side of high availability. In order to achieve this level of availability, we have to fix any failed equipment within 2 weeks -- even if the failure does not take the node out of service. If we don't fix it, then the remaining part that still works now determines the node's availabilty, and we are no better off than before (at this node). So, there is no free lunch. Also, we have to be able to detect that something at the node has failed, even though it is still working. OK, so let's just put up two different packet networks, each one of which reaches the two endpoints, but without any of this dual-redundant nonsense. In this case, we can model the two subsections as 40-element series connections of non-redundant nodes, and then we have two of these long strings in parallel. A40(ser) = 0.053 (from above) A2(par) = (1 - ( 1 - 0.053 )2) = 0.103 Well, this strategy didn't work very well compared to making each node dual-redundant, did it? So it seems like our poor sysop is stuck in engineering dual-redundant nodes. Commercial telecom equipment is generally engineered this way. What does it mean? So, one alternate seems to indicate a possible future for packet radio based on dual-redundant nodes, and overworked sysops; another scenario indicates that we cannot have all these nodes in series, i.e.: we need long-hop technology. ************************************************************************* ICOM's IC-820H A Satellite User's Perspective James Miller, G3RUH g3ruh@amsat.org These notes are herewith placed in the public domain. They represent the observations of the author, and are as accurate as I can possibly make them. They are not to be taken as either endorsement or damnation of the product in any way. I disclaim all responsibility for any loss or damage, direct or indirect arising from use or abuse of this material. Caveat Emptor. Summary The ICOM IC-820H will, "straight out of the box:" Work terrestrial UHF or VHF all-modes simplex/duplex very sweetly. Work SSB/CW transponding satellites OK, albeit with a somewhat clumsy human interface. Work satellite 1200 bps PacSats OK, if you can accept doppler tracking with 100 Hz steps. Work terrestrial 9600 bps packet perfectly The ICOM IC-820H will NOT: Work 9600 bps satellites "outa the box;" A modification is needed. The ICOM IC-820H has a number of positive features; beautiful construction, small size, excellent documentation, good frequency management. The ICOM IC-820H has a number of negative features having to do with pre-amplifier and linear amplifier control, power output control, internal switches, and coarse doppler tracking. Introduction A while ago (June 1994) Icom-UK kindly loaned me an Icom-820H transceiver to evaluate. Like you, loads of questions came to mind. I wanted to know: "What's the Icom-820H like? Is it really a 9600 baud packet radio which is data ready right out of the box? What about 1200 bps PacSat use? Would PSK be decodeable? Would the VFOs track sensibly? Doppler tuning facilities? Satellite ready?." And many more. This is not a full-blooded QST review plastered with microvolts and decibels. That'll come from the ARRL Lab. But I have measured what I needed to know. I also assume the reader knows how to use a satellite, has a reasonable idea of what to expect from this sort of radio, and doesn't (say) need "reverse tracking" explained. I'm recording the interesting differences between established practice as popularized by the Yaesu FT-736R, and typical user expectation -- mine. First Impressions The manual is a model of clarity. Outstanding. Yaesu please copy. The schematics are not quite up to Kenwood standard; need more annotation, frequencies, signal names and highlighted principal paths. This would help understanding a lot. Anyway, I located the discriminator and varactor stuff OK, various internal switches etc, and things looked promising. Then I connected up two dummy loads, switched on the radio, and played with all the knobs and buttons until I'd hacked the lot. The Product The IC-820H is a dual-band 144/430 MHz full-duplex all-mode transceiver. It has 100 tunable memories, 10 tunable satellite memory pairs and six assorted others. Output is 30-45 watts. Mine also had an extended receive range: 136 to 174 MHz which was very useful. This feature is not documented in the manual. The radio is small. It's 2/3rds the height, width and depth of a Yaesu FT-736R. But then it has no internal mains power supply, and neither will it accommodate two extra band modules like the Yaesu. It requires a 13.8 volt supply, about 16 amps, and is suitable for mobile operation. A microphone is not supplied and neither is a carrying handle. In England, the combined cost of the radio and a PS-55 supply (GBP 245) is about GBP 1940; an FT-736R from the same dealer is GBP 1700. GBP = Great British pounds sterling. The Hidden Features Being small there are only 32 buttons and knobs on the front panel compared with 67 on the Yaesu, so the lesser used functions, about 20 of them, such as dial dim, pre-amp feed control, RIT rate, CAT baud rate and so on are pre-stored via a configuration process. To invoke this requires the radio to be switched off and on again up to four times, which seemed unnecessarily clumsy to me. Some other functions are relegated to slide switches inside the radio, and adjustment requires you to remove the covers. This takes a few minutes. See you later. Normal Tuning Management The radio is organized around a Main Band and a Sub Band, each assigned to UHF or VHF or vice versa. You transmit on the Main band only. You receive on both Main and Sub simultaneously. There are duplicated volume and squelch controls; Main appears in the left headphone, Sub in the right; an internal switch allows these sounds to be mixed or separated. There is an internal speaker and there are two external loudspeaker sockets; smart wiring selects the expected sum/separated combinations. Storing, retrieving, and swapping frequencies and modes is a doddle. Everything you could possibly expect is provided. Tuning rates are very sensible, and can be quickly adjusted from 1 MHz right down to 1 Hz resolution on SSB/CW, 100 Hz on FM. There are two VFOs each, for VHF and UHF, plus 100 tunable memories initially apportioned 50/50 between VHF and UHF, but you can alter this up to 80/20 either way. The idiom is a little different from the FT-736R's, and took practice to acquire, but within a couple of hours it became second nature. I liked having both frequencies in view. The amber LCD display has very crisp characters and delights the eye. Because you transmit on Main and receive on Sub, and can control each quite independently, you can (and do) operate satellites when in "normal" mode. Unfortunately RIT, passband Shift and optional CW-Narrow do not work on the Sub band, i.e. on the full-duplex receive frequency. Neither do manual AGC fast/slow select nor the mechanical S-meter. Instead, on the Sub band CW or SSB mode automatically chooses AGC fast or slow for you, and there's an LCD bargraph S-meter. Satellite Tuning Management When you enter "Satellite" mode either the satellite VFO pair is used, or one of the 10 satellite memory pairs, or you can transfer the "Normal" frequency pair across (and back again when you leave). When in satellite mode, Main and Sub band frequencies track together, either normal or reverse -- as for example with Oscar-13 mode-B. Alas, there is no proper "untrack" facility; to alter one frequency independently of the other you have to hold in one of two alternative front panel buttons whilst turning the main tuning knob. With practice I managed sort-of using my thumb and forefinger for the main knob, and third or fourth finger for the buttons; left handers would find it nearly impossible. It's really a two handed job, and is excruciatingly fiddly. I discovered an undocumented kludge that partially obviated this; using the microphone Up/Down buttons, only one frequency changed. However the smallest step size from the mic buttons is 100 Hz. (See later). In fact, to tune TX and RX independently you need to adopt a change of attitude to the radio. Just forget all about a so-called "satellite" mode! Do your satellite operating in "normal," and only engage "satellite" when you want to do a quick bit of ganged tracking, or retrieve a frequency pair from the 10 satellite memories. I don't think this is how the designers envisaged things. Intriguingly, there is a blank button position actually marked Satellite, sandwiched between Normal and Reverse. I wonder why it's not fitted and called "Untrack"? Perhaps once it was. As before, since satellite mode receive is on Sub band, passband Shift, CW-Narrow, manual AGC fast/slow select and mechanical S-meter are inoperable, but a RIT has been provided. (Does anyone ever use RIT?) It would have been far, far better if there were a genuine "satellite" mode with Main receive and Sub for transmit. Main has the larger digits which are square in the middle of the radio and it's clearly the object of your visual, mental, and operating focus. And of course Main has all the RIT/SHIFT /CW-N/AGC/METER controls working for it. I really wish I didn't have to say this, but "satellite" mode looks at best to be an afterthought grafted on because the control microprocessor makes it easy. "It's only software." The Yaesu FT-726R first appeared ten years ago, the FT-736R six years, so the operational needs of satellite operators are well established. Why has Icom made such heavy weather of it? Preamplifiers & Linear Amps You can send +10v up either, both, or neither of the VHF/UHF antenna sockets. This supply is removed from the relevant socket on transmit. The manual does not specify a maximum loading; I tried 100 ma and 200 ma and the voltage remained steady; at 330 ma it began to droop. The limit is set by dissipation in a PQ20VZ51 regulator on the display unit. Other than this 10v supply, there is no provision for hard switching of pre-amplifiers or linear amplifiers unless you confine yourself to one band, when you can of course use the PTT line via the accessory socket. Serious operators will regret this omission. In contrast, the Yaesu FT-736R has four control lines, one for each band. Internal TX/RX changeover is by PIN diodes, so it's fast and silent. RF Power Control The front panel sports a high/low power control button. Low power is 4-5 watts. If you have an external linear amplifier or a transverter you need to be able to vary the output power continuously. There is no knob provided for this. There is instead an ALC facility on the accessory socket. The control voltage is -4 to 0 volts into "more than 10K," but you must provide a supply and a pot to do this. And a box, and a place to put it. Tacky. There's some free space on the rear panel though. There are several ways to key this transmitter; there's the Tone button, mixed in with other frequently used buttons and easily hit. Then there's the bigger Transmit button, and the normal PTT (mic or TNC). More than once I accidentally hit the Tone button, sending a minimum of 4 watts skywards. That would have wiped out my S-band converter had it been connected. RF Attenuators You can attenuate the RF input of either or both receivers, by 15db, from a front panel button. This is in lieu of a (big) RF Gain knob, and is an excellent feature. Many preamplifiers have far too much gain; an S-band pre-amp plus converter most certainly does. Being able to cut the signal down to size prevents cross modulation and overloading. Digital Satellite/Terrestrial Operation Before describing this, it's necessary to tell you how the data input and output audio is routed, because it is not unconditional. You might like to draw yourself a little sketch. Both signals are presented to the 8-pin DIN Accessory socket on the rear panel. The incoming transmit audio (TXAudio) passes though a slider switch marked PACT/AMOD: In the AMOD position the TXAudio passes to the Main subsystem where it meets up with the regular pre-amplified microphone sound for use in FM or SSB modes, and then through some audio processing. In the PACT position the audio goes directly to the varactor diode of Main's FM section. The receive audio (RXAudio) also passes through the PACT/AMOD slider switch: In the AMOD position, RXAudio is picked up from either the Main or Sub receiver, according to the setting of another internal slider switch marked MAAF/SAAF, and is squelched. In the PACT position the audio is collected directly from the discriminator of the Main FM circuit, via a 4.7K resistor and 100nF coupling capacitor. It's unsquelched of course. These switches are not accessible without removing the bottom cover. An access hole could surely have been placed next to the accessory socket, which would allow these switches to be tickled with a small screwdriver. Users will probably drill a couple of holes in the bottom, or cut away some of the underside ventilation grill. But why should you need to touch them at all? Read on. 1200 bps PSK Satellites FO-20, PacSat, Lusat, and Weber require an FM uplink, to which is applied audio PSK. The downlink is conventional carrier PSK, and the system is full duplex. Therefore the internal switches must be set to AMOD and SAAF (see above). The uplink "eye" as received at the satellite is OK; it's pinched about 4 db. Remember the TXAudio has been through the regular FM modulator circuits. It's a good idea not to yell into the microphone at this time, unless the Mic gain pot is at minimum, since both signals are added. If you flip the MOD switch to PACT the uplink modulation is text-book perfect, but then you lose your Sub band PSK receive audio! You get Main FM. Grrr! Downlink 1200 bps PSK reception from the Sub band receiver is excellent, as too is Oscar-13's 400 bps telemetry signal. The only snag with these PacSats is doppler tracking the PSK signal. (See later). 9600 bps DFM Satellites Uosat-22, KitSat-23, etc. require the TXAudio to be applied direct to the transmit FM varactor. RXAudio must be picked off directly from the FM discriminator, and the system is full duplex. Thus the internal MOD slider switch needs to be set to PACT. But that immediately picks up the wrong RX audio -- from FM Main's discriminator. For satellites we need FM Sub's discriminator output. Consequently you CANNOT operate the 9600 bps satellites with an Icom IC-820H "straight out of the box." There is a solution, but we're back to modifications I'm afraid. What you do is locate the Sub receiver discriminator IC20, pin 9 and fly that signal out on your own lead. This requires you to remove the big PCB called Main Unit, turn it over and do some fine re-work among the sea of surface mounted devices. Alternatively, you can pick up a downstream version of the signal without removing the PCB, at the optional tone-squelch unit-B socket J20, third pin from the "J". Incidentally this signal is DC coupled to the discriminator chip, so you can implement closed-loop AFC externally using one of the many published circuits. The source impedance is 47K (R329). I checked Uosat-22 and KitSat-23 on Sub-band using this modification. The UO-22 "eye" is poor when it leaves the satellite, with a lot of LF flutter which has always made decoding difficult. But the 9600 bps performance of the Sub band receiver is so good it adds little extra aberration and data decoding was quite satisfactory. The KitSat-23 "eye" was wide open, and data detection perfect. Since there is no AFC indication for Sub band, tracking the changing doppler shift unaided requires either very good judgement, an external system as above, or computer control. Oh, and once again set the mic. gain to zero, or microphone sounds will be added to your transmission. 9600 bps DFM Terrestrial Terrestrial 9600 bps packet works perfectly, "right out of the box." Over the last six years I've tested innumerable radios for 9600 bps operation. The Icom IC-820H now shares top place with Kantronics' D4-10. (The latter is however 2-channel, crystal controlled and UHF only). 9600 bps packet requires the TXAudio to be applied direct to the transmit FM varactor. RXAudio must be picked off directly from the FM discriminator, and the system is simplex. Thus the internal MOD slider switch needs to be set to PACT, which also selects RXAudio from FM Main's discriminator. The transmitter circuit's frequency response is from about 15 Hz to well beyond 6 kHz, so the outgoing signal has superb fidelity. If the drive signal exceeds 1.6 volts pk-pk, corresponding to about +/- 5 kHz deviation, modulation is switched off abruptly and stays off until you reduce the drive. A nice touch. The correct drive level is 1 volt pk-pk for +/- 3 kHz deviation and I confirmed this by measurement. The FM Main and Sub receive circuits are similar. Main uses a pair of Icom part no. FL-211 crystal roofing filters (no spec) and a muRata SFH455E ceramic final filter; Sub uses a pair of FL-212 and the muRata CFW455E. The "E" suffix means 15 kHz bandwidth. The SFH types have particularly flat delay characteristics, and are pin compatible with the more common general purpose CFW series. Main's fidelity is outstanding, with a flat frequency and delay response to over 6 kHz. The "eye" was essentially perfect. You can be mistuned by up to +/- 4 kHz before the "eye" starts to look mangled, and +/- 5 kHz if the packets are short. The Sub receiver is almost equally good, but you can't get at it without modifying the radio as described earlier. No quibble with Icom's claims here; 9600 bps simplex works 101%. PSK Satellite Doppler Tracking When using a 1200 bps PSK digital satellite such as FO-20, PacSat, Lusat or Weber it is essential that the PSK modem can control the radio receive frequency in a closed loop fashion, preferably in small steps. The universal means of doing this is via the Up/Down buttons of the microphone socket. The smallest step from the mic Up/Down buttons of the IC-820H is 100 Hz. This really is too big, as the sudden lurch from one frequency to the next will invariably cause momentary loss of demodulator lock, with attendant corrupted characters. The Up/Down line is also accessible from the accessory socket, but it shares a pin with the ALC control. You select which from an internal slide switch. There seemed to be no way of changing the mic. button step size to smaller than 100 Hz. An oversight? RS-232 Control Icom's system is called CI-V (Communication Interface 5), and is accessed by a rear panel jack with a bi-directional service. The voltage is TTL-ish. You're supposed to buy the CI-V interface which converts to RS232 levels, and also, I assume, de-multiplexes the input and output. The manual only provides a limited description of the control codes required; I guess a full treatise comes with the interface. In particular I couldn't determine what frequency resolution is available via RS-232 control. Other Observations 1. There is a miniature 40mm fan inside the PA section which comes on when the radio is too hot, and the TX is keyed. I spotted the fan on the schematic, but I couldn't find it inside the radio until I provoked it into action during a megabyte file transfer at full power and a 75% duty cycle. The noise is less than a typical computer's. 2. If you want to use speech you must switch your TNC off or disconnect it from the accessory socket, otherwise your speech will be obliterated by data. This is not mentioned in the manual! 3. There is no VOX system. Witticisms The manual is beautifully laid out, with explanations crystal clear, quite devoid of Janglish. Fortunately, two useful tips escaped the proof-readers: IF Shift Control, page 24: "Especially in CW mode, a mechanical noise may sound when rotating the [SHIFT] control, however, it is not a transceiver malfunction." I'm still decoding that one. Satellite Notes 1., page 35: "NEVER set the output power too high. Too much power will shorten the satellite's life." Ah so. Conclusion The IC-820H wasn't really designed with satellite operation as its primary application. It's unlikely to win the hearts of serious satellite users, in the same way as Yaesu's FT-736R, mainly because of its lack of flexibility. But an average user who wants to try out transponding satellites such as Oscar-13 will find it a satisfactory starting point. With the PacSats, 1200 bps doppler tracking is awkward, and 9600 bps full duplex operation requires you to modify the radio. The IC-820H is a nice radio if your needs are normal VHF/UHF operating, although serious VHF/UHF users will bemoan the lack of control over external equipment. It is also fine for low speed data transmission, and is among the first general purpose radios that provides 9600 bps packet radio simplex capability straight out of the box, at which it excels. Acknowledgement My sincere thanks to Dennis Goodwin at Icom-UK for the IC-820H loan. *************************************************************************** Outline of a Broadcast Protocol using Negative Acknowledgement Dirk-Jan Koopman djk@dirku.demon.co.uk A better generic name for this protocol might be 'group communication' rather than a 'broadcast protocol.' It is designed to be used in a situation where a number of packets of information must be shared reliably between a relatively small group of stations which can normally hear one (central) station which we shall call the sequencer. Actually, 'relatively small' could be a quite large number (as hopefully will become apparent). 'Small,' in this case really means finite. The protocol described is prcised from [Tanenbaum 1992 - Modern Operating Systems] and also [Kaashoek et al. - Group Communications in Amoeba and its Applications]. I say prcised, because most of the detail has been left out -- hopefully not to the detriment of understanding! There is nothing the principles outlined which are Amoeba specific. In particular, whether you implement this on top of AX.25 or Amoeba FLIP or IP is largely irrelevant. There are some particulars left out in this document which include joining and leaving a group, plus some housekeeping details which are probably implementation- and underlying transport-dependent. Group communications is so called because you are communicating with a closed (or finite) group of other stations. The aim of this protocol is to allow reliable communications from one member of the group to the whole group with an average of just over two packets for the whole group (if incoming packets are on the same frequency) or just over one packet, if incoming packets are on another frequency. Also, the order of the packets is guaranteed. Before you can start, as touched on earlier, a special station must be selected to act as a 'sequencer;' as an aside, in Amoeba, this is done by election as it is a multiprocessor based operating system and all kernels are created equal for this task; in Amateur radio use, it is much more likely that we will have a suitably located station dedicated (at least partly) to this purpose. The sequence of events is roughly as follows: There are 4 stations in the group (A,B,C,D say) and the sequencer station (S). Station A wishes to send a message to all the other stations in the group. Therefore, station A sends a packet addressed to the sequencer S, with a unique message ID (used to detect duplicates), the sequence number of the last broadcast received by this station (used as a piggyback acknowledgement) and the message data itself. This station then starts a timer. If the broadcast comes back (from S) before the timer runs out, the sending station stops its timer and carries on (updating the sequence number of the last broadcast heard). If the broadcast is not heard and the timer has expired, then A assumes that either the message or the broadcast is lost. In either case the message is retransmitted. If the message was lost, then S broadcasts it in the normal way, otherwise S detects it as a duplicate and a simple acknowledgement is sent back to A instead. The message isn't broadcast again. There is another possibility in that A might get another broadcast, from (say) B, in this case A knows that its message might well have got through, so it queues the message from B and still waits for its broadcast to arrive from S or its timer to expire. At the sequencer, S, the following things happen when a point to point message arrives for broadcast: First a check is made to see if it is a retransmission, if it is, then the sender is sent a personal acknowledgement (as above). If the message is a new one then the 'next sequence number' is applied to it and the 'next sequence number' is incremented, ready for the next message. The message and its indentifier is stored in a 'history buffer' and the message is then broadcast. If the sequencer happens to have an application process on it that is registered as part of the group then the message is then made available to it. Now let us look at what happens when one of the other stations (B,C or D) receives a broadcast: First the sequence number of the broadcast is compared to the last sequence number received (i.e. of the most recently received broadcast message). If the new one is exactly one higher, no broadcasts have been missed. The station then processes the packet. If the sequence number of the packet is more than one greater than the last one received, then one (or more) broadcasts has been missed. The broadcast that has been heard is queued, and a point-to-point request is sent to the sequencer S asking for a (private, in Amoeba) retransmission of the missing packet(s). When they arrive, all the packets are then passed up to the application in sequence number order as though nothing had happened. The only thing that has occurred is a time delay. An example If a newly received broadcast has sequence number 25 and the last sequence number received was 23, the protocol is immediately alerted to the fact that it has missed number 24. It sends a point-to-point message to the sequencer to this effect, the sequencer replies by resending message number 24 from its history buffer. When sequence number 24 is received, packets 24 and 25 are passed up to the application (in that order) as if they had simply arrived together. The history buffer in the sequencer requires management. If nothing is done, then the history buffer will quickly fill up. There are several ways that the sequencer can determine that a certain number of messages have been received by each member of the group: 1. Each request for a broadcast message contains a piggybacked acknowledgement which contains the sequence number, k, of the last successfully received broadcast. This means that all broadcasts up to and including, k, have been received. 2. If a station has been silent for a certain (comparatively long) period of time it is required to send a short acknowledgement message informing the sequencer of its last heard broadcast sequence number. 3. If the sequencer has not heard anything for a (even longer) period of time or its history buffer grows over some threshold size it can send a 'request for status' message, which directs all, or some, stations to send a message telling it the last broadcast sequence number received. In all cases, if there are missing broadcasts detected, by inference, then the missing packets are resent. In addition to the above, it is possible to produce any degree of fault tolerance into the system with a proportion of extra overhead. The degree of fault tolerance (i.e. the number of sequencer stations that can go down before communications become unreliable) is selectable -- but the more 'back-ups' you have the more traffic is generated. The mechanism for this is outside the scope of this article -- especially as I don't think it is particularly relevant for our purposes at the moment. Summary This protocol allows reliable broadcasting to be done on an unreliable network in just over two packets per reliable broadcast (if all stations are on the same transmit and receive frequency, nearly one if the frequencies are different). All application programs receive all messages in the same order sent regardless of how many messages are lost. The worst that can happen is that a short delay is introduced when a packet is lost, which should happen infrequently if the sequencer site and its frequency are carefully chosen. If two processes attempt to broadcast at more or less the same time, one of them will get to the sequencer first and win. The other will see a broadcast from the first station and wait, in case its message has been queued and thus will appear shortly. If it doesn't, then it simply resends. This protocol could form the basis of a group communications protocol particularly where direct 'real-time' one-to-many communications are needed; examples include DX clusters or chat servers. This could (probably) be done using AX.25 UI (Unumbered Information) frames. It is perfectly possible to implement this protocol (or at least the non-sequencer user part of the protocol) within a TNC or equivalent with minimal overhead. ************************************************************************** TAPR Technical Support Group TAPR is looking for more people to participate in our Technical Support Group. This group handles the day to day questions the office receives about technical issues. It is important that we get some more people involved, so that we do not burn-out our current volunteers. Technical support for all TAPR kits and projects is supported by volunteers. The more volunteers we have helping, the better TAPR can help folks with their problems. Due to the amount of information requests and technical support TAPR receives, we have had to begin to prioritize members above non-member requests. This has left some requests from non-members for help and information delayed for weeks, instead of days as it might be if we had more help available. Many of the recent postings on packet and Internet about TAPR's lack of technical help is a result of not having enough people within the organization volunteering with support and information issues. These non-members are future members if we can help them with their problems and concerns. We are looking for additional help in the following areas: TAPR 9600 baud modem kit TNC problems and upgrades DCD Kits Operating Help BBS Questions TCP/IP and NOS Lots of General Packet Radio Questions If you think you might like to help work with folks on their problems, please send email to tapr@tapr.org or contact Dorothy at the office to have your name placed on the list. Providing this help takes maybe 30 minutes to an hour a week depending on the area and the amount of questions we are getting in. The more people we have involved in each area, the less time everyone in a specific group spends on correspondence. You can also be in more than one area if you want. If you have another area you feel you would like to cover, please pass that along to us. We can then make a note of that and use you when and if we get a question in that area. We are also looking for a technical support group manager to help coordinate the follow-up on technical issues within TAPR. If you think you might be interested in this, please e-mail tapr@tapr.org or contact Dorothy. In addition, we are on the lookout for the names of any regional elmer groups that we can pass out. We have lists for some sections of a few states, but we are looking for more. Local elmers are sometimes the best solution to any question or problem. This also applies to any regional packet groups that might be doing the same thing. *********************************************************************** TAPR Technical Support Policy Greg Jones, WD5IVD We have had some complaints from individuals that do not understand how TAPR operates. I want to state for all the membership how technical support is done and I would hope that the membership can help those non-members better relate to how TAPR works. Most technical help and questions are received by mail and phone calls. When someone asks TAPR for technical help or to answer a question the office forwards the request to someone on the technical/question support list. The volunteer then answers the questions by phone (many times by making a collect call) or by writing a letter in reply. Most amateurs asking for help are not on a commercial e-mail service or they would be asking there. I think it is important to publish our current Kit Return and Technical Support policy, so everyone can read it. One reason TAPR is able to keep it costs low is because it does not have to hire someone full time to handle technical support. In the past Lyle Johnson, WA7GXD, did numerous hours a week on technical support. With Lyle moving on to more fun activities for his talent and interest, members within TAPR must take over that load. This process will take time and effort to attain the type of response Lyle was able to provide. How many companies in the world would have had someone of Lyle's capabilities handling this type of task? This is the statement that is sent with all TAPR kits: Thanks for purchasing a TAPR kit. Before you get to building your kit, please take a moment and read the following about kit return and technical support. Kit Return / Refund Policy: TAPR kits can be complex depending on kitting experience of each builder. Before you unpack all your components, read through the documentation and determine if you believe you will have any problems assembling or making operational your TAPR kit. Consider carefully whether you wish to proceed with the unpacking of your kit. Once you begin construction, we cannot accept it back for refund. We don't think you will have trouble with most of TAPR's kits, but some require special knowledge or experience in order to successfully go from a kit to a finished, usable unit. If you decide to return your kit for a refund, contact the TAPR office (below) via mail, phone, or fax for a Return Authorization Number. Mark the outside of the package clearly with the R.A. number and ship it to the shipping address given to you at the time of the R.A. number. Upon inspection of the returned kit, you will receive your purchase price, less shipping and handling. If you return the package without an R.A. number, it will be returned. If you have any questions, you can call the TAPR office at the number listed. Technical Support Technical support for TAPR kits is handled on a volunteer basis. Each kit has a technical support specialist and all questions are sent to this person. Replies are then mailed or faxed back when the volunteer has a chance to cover your question. This might take a week to several weeks, depending on the topic and time of support. A Technical Support Form has been included with your kit. Some kits contain a Frequently Asked Questions list, which provides help on the more common problems. If you have a Technical Support request, please complete the form and either fax or mail it to TAPR at the below address. You might try calling the office for some problems, but the office manager is not a technically sophisticated hobbyist, so she can only write down your problem, which is much better represented by using the Technical Request Form. The form allows for fewer problems in translation over the phone of problems. ************************************************************************** Update on the RUDAK-U Project Lyle Johnson, WA7GXD The design team for RUDAK-U (myself, Chuck Green, Harold Price, Peter Guelzow, and Jeff Ward) have been having discussions and doing some testing since the last PSR. We have all been busy with other aspects of the P3D spacecraft, as well as others, so the progress is a little slower than we would like. The good news is that you can still give us your comments -- it isn't too late! The primary flight computer for P3D is called the Integrated Housekeeping Unit (IHU). This IHU is substantially the same as the one flying on AO-13. The primary differences are: (a) increased memory from 32k bytes to 64k bytes; (b) inclusion of the command decoder on the IHU PC board; (c) the IHU is now a single PC board; (d) the IHU is now on a multi-layer PC board. Why do I mention the IHU? Without it, there is no P3D -- hence, no RUDAK U! So, I have been giving priority to the IHU design over that of RUDAK U. Also, the GPS experiment team has been doing some radiation testing. Paul Barrow has assembled a team of folks in Canada and they have already determined a suitable switching power supply chip for use in a number of modules on P3D -- including, of course, the GPS, RUDAK and IHU modules. Peter Guelzow has done some testing of an Analog Devices 7008 Direct Digital Synthesier chip and it looks absolutely outstanding. It will very likely be the heart of the experiemental modulators on RUDAK E and be used on the DSP channels of RUDAK U. So, how does RUDAK U look at the moment? The CPU will probably be an NEC V53 with a possible Intel i386EX as a backup. The CPU will have 16 megabytes of EDAC memory for program and message storage. The maximum number of uplink and downlink channels hasn't yet been fixed, but there may be as many as 12 uplinks and 4 downlinks. There will be "fixed" channels and DSP channels. The fixed channels will probably be 9600 bps FSK. The system will be able to adjust the relative powers of its downlinks. This means that at times there may only be a single, very strong downlink. At other times there may be more downlinks running, but with weaker signals. My preliminary link calculations show that you will need reasonable antennas on your packet station to make full use of RUDAK-U. The downlink from the satellite will be marginal if we run four of them with equal power and you are at the edge of the antenna pattern from the satellite. You will need antennas with about 10 dB gain on 2 meters, 13 dB gain on 70 cm or 22 dB at S-band. None of these gains are hard to come by, but you won't be able to use a 3 element beam or a J-pole! If we run a single downlink, and we generate 18-20 watts of RF on it at the spacecraft, you should have an extremely loud signal with these types of antennas and a useable signal with maybe 4 to 6 dB less gain. These calculations were based on published numbers for the spacecraft antenna system gains and very conservative numbers for the transmitter power levels. Of course, we could gain nearly 12 dB in performance margin if we had 1200 bps PSK downlinks, but I suspect most of you would rather we didn't make another 1200 bps satellite... (Comments, please!) A possible scenario is to have a downlink using most of the power most of the time with 2 or 3 other downlinks using less power. Then, if you don't have a great antenna system, you can still use RUDAK-U. If you have a better system, you can switch over to less-congested channels. The DSP channels will be fewer in number, perhaps 4 uplinks and 2 downlinks. The purpose of these is to have flexibility in modulation techniques as we progress in packet technology over the next ten or twelve years. I expect to report on both the final system design and on prototype status in the next issue. Thank you for your support of P3D and of RUDAK-U! ************************************************************************* Network Enhancements Implemented in the CT/NJ/NY Region Frank Warren, Jr., KB4CYC Andrew Funk, KB7UV Scott Weiss, KB2EAR Ad-Hoc Tri-State Managed Packet Group (MGTBBS) [From the TAPR BBS-SIG mail group.] Summary The problems of the proliferation of flood routings, widespread mesh forwarding, and an ever-expanding system census had combined to reach a point where the PBBS network in the CT/NJ/NY tri-state region was in dire need of an overhaul. This paper details the approaches taken by the majority of systems in the region to address these problems. Introduction As part of the June 1992 ARRL Hudson Division Convention, a forum was held for regional packet radio System Operators (sysops) and Network Administrators. Our aim was to begin dialog among those operating packet systems in the region, with the goal of improving the packet environment in the region for all concerned. (The systems "talked" with each other, but not the people behind the systems... Until this meeting.) Since this June meeting, Sysops and Network Managers in the tri-state region have continued meeting and planning. This work has developed a cooperative system for the distribution of bulletins. The solution developed combines a consensus on which distribution routes will be supported, a list of suggested "To:" fields which users are encourged to use, cellular hub and spokes bulletin distribution topology, and time reserved exclusively for user access to PBBSs and other network services. Forwarding 'Quiet Hours' The initial decision reached by the group was to prohibit BBS-to-BBS forwarding between 1800 and 2400 local time on all paths which may also carry real-time user data. This provides users with six hours each day, during prime time, when their enjoyment of the packet network is not impaired by contending with automated stations. Hub and Spokes Forwarding Topology At the group's mid-July meeting, a plan to reduce bandwidth consumption by bulletin distribution was formulated. Bulletin distribution now follows a cellularized, hub/spoke or server/client design. Many of the systems in the region use a series of regional backbone nodes maintained as part of the Eastnet Backbone Network (EBN). Others are served by the ROSE X.25 Packet Network maintained by the Radio Amateur Telecommunications Society (RATS). Those systems using the EBN regional nodes receive their bulletins from a single, designated hub/server within their cell. The cells were defined based upon the existing backbone EBN nodes. The cells currently resolve to Connecticut, Long Island, New York City, Downstate New York, Northern New Jersey and Central New Jersey. Cell size and definitions may change, over time, as a function of network traffic and topology. The RATS ROSE Network has bi-directional connectivity with the two New Jersey EBN-based cells and a bi-directional feed to the cellularized (non-EBN) network in Southern New Jersey. Bulletin distribution for systems on this network also follows the client/server model. This design has freed the bandwidth previously occupied (wasted!) by everyone trying to forward everything to everyone else. In addition, this dual-network topology provides redundancy and robustness often lacking in Amateur packet networks. Supported Flood Distributions Table 1 is the list of flood distributions (@-field routes) the region has decided to support for forwarding. Suggested "To:" Fields Table 2 is a list of "To:" fields the group decided to distribute as a partial list of suggestions. The entries for the various PBBS software were originaly proposed as flood routes, but were recast as "To:" values based on explicit statements and examples from several PBBS software authors. Conclusion The plan outlined above, combined with ongoing efforts in user education by the participating SYSOPs, has improved packet operation throughout this region. While not all of these steps may be as useful in other areas of the country, they may serve as a basis for development of a broad-based (dare we hope world-wide?) consensus. We also urge the adoption of dedicated user time, for without users our systems are not needed. Contacting The Authors The authors of this paper, along with the sysops of all systems participating in the Ad Hoc Tri-State Managed Packet Group, can be contacted by sending (using the "SP" command) a single packet message addressed to: RMAIL@KB4CYC.NJ.USA and containing as the first line of text the following: To: rmail@kb4cyc.nj.usa, sysop@tribbs This Remote MAIL message will be processed automatically at the KB4CYC PBBS and become a flood bulletin to all the participating MGTBBS systems. Alternatively, as each of the authors operates a PBBS, they may be reached via packet radio using the following addresses: kb4cyc@kb4cyc.nj.usa kb7uv@kb7uv.#nli.ny.usa kb2ear@kb2ear.nj.usa