---------------------------------------------------------------------------- TAPR -- Packet Status Register -- Electronic Edition TAPR News Service PSR #57, Winter, 1995 ---------------------------------------------------------------------------- Packet Status Register Issue Number 57, Winter 1995 Published by Tucson Amateur Packet Radio Corporation Contents: President's Corner Introduction of the APRS Special Interest Group BBS-SIG Report HF-SIG Report Position Paper on Packet Bulletins EASTNET VHF/UHF Backbone System Amateur HF Digital Bibliography MFJ-9600 Modem Modification Interfacing the TAPR Deviation Meter to a PRO-508 Packet Radio Network for Volcano Monitoring Regional Organization List ICOM IC-970 Modem Interfaces for Satellite Communications IC-970 Modification For 9600 bps Operation A Windows Development Environment for the TAPR/AMSAT DSP-93 A Macintosh Development Environment for the TAPR/AMSAT DSP-93 DRSI Ends Sales of Ham Products FCC Denies Reconsideration of Message Forwarding Rules Spread Spectrum STA Renewed Spectrum Below 5 GHz Transferred from Federal Government Use ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Copyright 1995, 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 #57, Winter, 1995 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 Reflections 1994 was a good year in many ways for TAPR. The Board set eight goals for 1994, which were: 1) continue to watch spending closely, 2) continue to work on increasing membership, 3) work on getting Special Interest Groups active, 4) get closure on current projects, 5) finish work on kit revamps in progress, 6) develop more TAPR involvement in national perspectives, 7) develop more TAPR publications, and 8) finalize TAPR's short and long term goals. The first seven goals were achieved with some success. I'll touch on each in a second. The eighth is an ongoing task and we will continue this activity in the future. The financial statement for November has us in the black and it looks like it will stay that way through December. This will make a second year of positive operations. The Special Interest Groups that were started in March '94 have grown from two groups to six by the end of the same year. On the kit front, the DSP-93 reached closure and began making both TAPR and AMSAT money, the TUC-52 project is nearing prototyping, and the PSK kit, TNC-2 bare board, and DevMeter kit were discontinued. TAPR started to get more involved in national issues and will continue to work more on this area as opportunities appear for our input. In the area of publications, TAPR arranged an agreement with the ARRL concerning past proceedings of the digital conferences and TAPR began to develop a series of books to be published in 1995. The increase in membership was the happiest goal to achieve. The goal that was set by the board was to increase membership beyond 2,000 by the end of 1994. The goal was reached in October and we continue to get new members in daily. Thanks to all those that help with membership and welcome to all the new members! Membership makes this organization operate and allows everyone to benefit from the TAPR effort. I would like to pay my compliments to outgoing board members Jack Davis, WA4EJR, and Ron Bates, AG7H. Although they will be leaving the board, I do not expect them to become any less active in TAPR. Jack continues to help with parts procurement and TrakBox issues, while Ron has been working with the TUC-52 project group. Thanks for all their effort this last year! The Upcoming Year TAPR still has a lot more to continue to work on in 1995. The annual meeting looks like it will be a great event and I look forward to seeing everyone in St. Louis in March. The TAPR election sees four excellent candidates running this year and whoever is elected should bring excellent energy to the board for the next three years. Last year we saw over 50% response from the membership. I hope we can get that good a response this year in voting. As for membership, I would like to see TAPR set a new membership goal of 5,000 members by 1997. This would be another doubling of the membership, which I believe can be accomplished. The set of goals I will be proposing to the TAPR board in March will include: 1) continue to be ever watchful on expenses, 2) continue to work on increasing membership, 3) continue to develop TAPR involvement in national perspectives, 4) continue to look at ways of providing more operational capabilities for digital operators, and 5) work on making TAPR a more rounded national organization. One of the keys to TAPR's success in the long-term future is building good working relationships with the various regional and digital interest groups. This will allow both TAPR and the regional groups involved to become stronger by working together on educational and research issues. On the "don't forget" list, we have the annual meeting in March followed by TAPR's packet activity at Dayton. Dayton is going to see a few changes this year (read further in the ~PSR~). Don't forget to send in your ballot for the election when you get it. Your vote counts. Don't forget, we still need help in answering questions, so if you think you can help, contact Dorothy at the office. Don't forget, when contacting one of our advertisers to mention where you saw their ad. It helps us and them to know that their ads in the ~PSR~ are doing them good. Azden joins us this quarter as a new advertiser. I would like to welcome Keith Sproul, WU2Z, and the APRS-SIG he will chair as the latest SIG to be formed in TAPR. This should be an excellent resource for those interested in APRS activities. Read the SIG section for more information on what this is all about. On a last note I would like to congratulate Bob Hansen, N2GDE, for another excellent year of ~PSR~ editing and production. Much has happened in Bob's life and many do not recognize the commitment Bob has made in the last eight months to continue to produce the ~PSR~. In addition, the ~PSR~ continues to change its look and we all feel that it only gets better. Thanks, Bob. Until next issue, cheers - Greg Jones, WD5IVD ************************************************************************* Introduction of the APRS Special Interest Group Keith Sproul, WU2Z Automatic Packet Reporting System (APRS) is a system used for tracking people, weather, objects, weather balloons, and many other aspects of Amateur Radio. APRS was developed by Bob Bruninga, WB4APR, and was first introduced to the Amateur Radio community at the ARRL Computer Networking Conference in 1992 in New Jersey. Over the last couple of years, APRS usage has grown and extended all across the country, and many new features have been added to this system. The goal of this Special Interest Group is to create a forum for people interested in this type of activity so that they can ask questions, compare notes, and exchange ideas. We will discuss things pertaining to APRS itself, GPS, GPS unit applications of this type of technology, automatic weather reporting, uses of APRS in public events such as bike-a-thons, and uses of APRS in emergencies. I can be reached as follows: Keith Sproul, WU2Z~ 698 Magnolia Road~ North Brunswick, NJ 08902-2647~ Work: 908 563-5389,~ Fax: 908 563-5035~ akasbb1@peabody.sct.ucarb.com~ Packet: wu2z@kb4cyc.nj.usa To subscribe to this mailing list send a message to `listserv@tapr.org` with the following line in the body of the message: subscribe aprssig FirstName LastName *************************************************************************** BBS-SIG Report Dave Wolf, WO5H~ BBS-SIG Chair~ Internet: dwolf@tcet.unt.edu~ CompuServe: 73427,2246 The TAPR BBS-SIG has seen some reasonable activity over the past quarter. The largest issues discussed on the SIG included: permissible bulletin topics on packet, education vs. legislation, reducing overhead of packet messages, refining the TAPR hierarchical proposal for final presentation to the Board of Directors. The issue which generated the hottest responses was, by far, permissible bulletin content. For details on the entire story behind the story, please see the TAPR position paper in this issue of the ~PSR~. The position paper was picked up by the W5YI Report (December 15, 1994) and used as their back page item. It was to have appeared in the January 1995 ~QST~, but it is our understanding it was cut at the last minute. Pity. The folks who could benefit most from this are the users. An update to the proposal for an X.3.4 hierarchical address standard (published in the last issue) also appears elsewhere in this issue of ~PSR~. There will be those who will dig in their heels and fight the change from NA to NOAM and cite many reasons for not doing so. The reasons for X.3.4 go beyond connectivity to the Internet or any other alternative communications network. Hams need a continental element that has greater precision than two place holders offers (that won't conflict with any state/provincial elements!). Barry Buelow, WA0RJT, is working on a BBS User's Guide. This should go a long way to increasing the sophistication of our user base. I know, there are some sysops who like to have unsophisticated users because that makes the sysop feel that much smarter. In reality, the smarter your users are, the more fun you'll have running your BBS! Your reasons for adopting a certain policy or changing the way your board is configured are easier to explain if your user base is better educated. One very simple thing I do personally, is to print out the user docs (that come bundled with AA4RE software) with a few revisions and formatting and spelling corrections to make it look pretty. I send these docs to anyone sending an SASE, and extend this offer in my help and introduction files. This is appreciated by the users and makes it more of a peer- to-peer project, rather than a 'I am the BBS guru, you are the idiot' situation that exists in many communities. I'm looking forward to seeing his work, and from working with him on TAPR projects, know it will be top notch. What are YOU doing to promote better understanding of our digital modes on the local, regional and national levels? There's unlimited opportunity if you have interest! We are looking forward to three big events for the in-person BBS-SIG: the TAPR Annual Meeting in St. Louis, the Dayton HamVention, and the Digital Communications Conference in Arlington, Texas. To make these more meaningful events for all participants, your input is hereby solicited for topics you would like covered. Some volunteer help would certainly be appreciated too. Keeping track of the SIG participants, tracking responses to any surveys that are made during the events, and such. Let me hear from you if you are planning on attending any of these events and wish to help with the organizational aspect of the SIG meetings. There's something I could use some help with and I hope someone jumps forward to volunteer. The on-line BBS-SIG has, like most on-line discussion groups, a perpetual ambient 'noise level' with some occasional gems making themselves apparent above the background din. The BBS-SIG could use, for lack of a better term, a SCRIBE, who would capture the best of the best from the BBS-SIG and TAPR would make it available for all interested. This would be a great assignment for someone who is interested in the work of the SIG, yet might not be interested in entering the issues arena on their own. Internet access is required for you to download and upload SIG activity. Let me know if you would make a good candidate! Looking forward to seeing you in St. Louis if you can make it, and on-line if you can't. Scribes Needed Scribes are needed for writing an overview of a selected SIG each quarter for the ~PSR~. Contact tapr@tapr.org if you are interested and your message will get forwarded to the correct SIG chair. This is an important job that needs to be done. ************************************************************************ HF-SIG Report Johan Forrer, KC7WW~ HF-SIG Chairman This is a summary report that covers the period middle October through December 15, 1994. The archived messages are available for retrieval from the TAPR list server. 1. General. The activities of the group started October with introductions by various interested parties. Common interests include: HF BBS/Gateway operations, Emergency (Red Cross), relief (FEMA) and volunteer (VITA) groups, and Technical interests. Although there presently is a somewhat technical slant to the discussions, any topics related to HF are welcome and are encouraged. 2. Modulation-demodulation Methods for HF Digital. A good start was made with an introductory listing of reference materials on topics such as ALE, CLOVER, G-TOR, AX-25, PACTOR (II), and other miscellaneous HF- communications issues. While in "open house" mode, several useful modulation schemes were suggested, such as the family of modems built around MIL- STD-188-141A (ALE), MIL-STD-188-110 (16 or 39 parallel tones), chirp, and multi-tone orthogonal signaling. The latter submission by Phil Karn, sounded quite interesting and is worthy of further investigation. Another possibility is "Piccolo," i.e., multi-frequency signaling (MFSK). Evidently, several promising options are possible for future exploration; however, it is a little early to make any guess which will be chosen. Probably, the classic arguments of how to arrive at the best bandwidth efficiency need to be evaluated and revisited. With the DSP and PC processing power available to Amateur experimenters, a lot can be achieved. This topic is likely to receive further attention in the future. 3. DSP platforms. There is no question that the interest in DSP techniques for future Amateur HF digital projects will continue. The costs of such DSP platforms have now also become affordable and within reach of Amateurs. There are exciting projects ahead and hopefully will give you the opportunity to expand your knowledge of both theory and applications. Although the learning curve is quite steep, the rewards are great. The TAPR DSP-93 and DSP-sound card options (described in the August and November 1994 ~QEX~), were discussed as possible platforms -- each having advantages and considerations -- use what you feel comfortable with. Hopefully, it would be possible to document our algorithms in pseudo code that could be ported to your favorite processor. It may also be worth following developments on the DSP and DSP-93 SIGs -- once they get started. 4. HF Ionospheric Channel Simulator. There is a need for methods and tools to evaluate experimental modems. The development of such a tool for radio Amateurs was put forward as a possible first objective of this group. It was felt that if such a project were within the capabilities of our present equipment, this would be a great achievement as it would be invaluable during experimental work. This device, also known as a "channel simulator," operates at base band, i.e., audio frequencies, and is supposed to be connected in the audio path between two modems under test. The simulator models the complex effects that the ionosphere has on the propagation of radio signals. A number of typical conditions are possible, i.e., "GOOD", "MODERATE", "POOR", and "FLUTTER FADING". In addition "FLAT FADING" conditions are also defined. These conditions are the result of multipath propagation. Random noise will also be included in addition to multipath effects. Once this need for a simulator was realized, valuable contributions were made by the group in locating technical papers and providing assistance with various formulae and algorithms. This kind of combined effort has proven to be very worthwhile One of the key documents that described such channel simulators was provided in the CCIR recommendations: CCIR Report 549-2, "HF Ionospheric channel simulators", CCIR Recommendation 520-1, "Use of high frequency ionospheric simulators". It was shown how to obtain these CCIR documents: Access the ITU/TIES information via gopher: use your own gopher client and access to info.itu.ch on port 70, or telnet to gopher.itu.ch on port 2000 Please send any messages to "helpdesk@itu.ch" These CCIR documents, however, are based to a large extent on the work done by Watterson et. al and described in: Clack C. Watterson, John R. Jurosheck, and William D. Bensema: "Experimental Confirmation of an HF Channel Model". ~IEEE Trans. on Comm. Tech~. Vol COM-18(6) December 1970. An example from the literature of hardware and software to implement such a model was suggested in: L.Ehrman, L.B. Bates, J.F. Eschile, and J.M. Kates. "Realtime Software Simulation of the HF Radio Channel" ~IEEE Transactions on Communications,~ August 1982, p.1809. A first attempt at simulating the workings of the model, is being evaluated at this time. Your participation and contributions are most valuable -- please consider joining us in this adventure. ************************************************************************* Position Paper on Packet Bulletins Tucson Amateur Packet Radio Approved and released by the Board of Directors, October 28, 1994 There has been a recent flurry of activity on the packet networks, as documented on BBS-SIG, over some packet bulletins issued by Frederick Sober, AB6GQ, an Official Observer Coordinator in the Sacramento Valley section of the ARRL. The concern expressed by AB6GQ is that packet bulletins whose contents do not relate to Amateur radio are in violation of Part 97. I have reviewed AB6GQ's bulletin, two letters from (FCC Personal Radio Branch Chief) Johnny Johnston, and discussed the matter personally with AB6GQ by phone on Sunday, October 23rd. Here is a brief history of events, primarily reported by Frederick: in 1993 as an OO, AB6GQ was contacted by several local packet BBS sysops who were concerned over the content of bulletins addressed, for example, to ALL @ ALLUS, ALL @ WW, and so forth. The content of many of these bulletins did not include ham radio-related subject material, and they wondered if this was a violation of Part 97. According to Frederick, he contacted his section manager, who advised him to get in touch with League headquarters. He was advised by a League Regulatory Information staffer to contact the FCC directly. Someone at the Hayward field office referred him to Washington. An exchange of correspondence with Johnny Johnston ensued (texts of Mr. Johnston's letters have been transcribed to the SIG from copies obtained by Greg Jones). AB6GQ has been advised that the League is going to 'undertake an educational effort' about which something will appear in QST after the first of the year. Frederick advises he is going to wait for further word through the League chain of command for his next, if any, action regarding packet bulletins. Because the spark which created this particular packet 'crisis of the day' was a statement to other Amateurs from an Official Observer Coordinator, and because there was a reported exchange of correspondence with an FCC branch chief, Greg Jones, President of TAPR, received numerous phone calls asking for TAPR's position on this matter. Greg discussed this situation with several League officials and other respected advisers prior to discussing it with the TAPR Board of Directors. Subsequently, Greg requested that I draft this position statement for TAPR. To be succinct, most of the flame wars and great debates over permissible communications exhibit a problem with semantics, not a lack of specificity in the rules. Packet is not some mutant communications form that is not definable by the rules. Packet is no more or less privileged than any other form of Amateur communications. (Packet is used here, but this argument extends to all legal forms of Amateur digital communications which are used for the forwarding of bulletins) Did you know that Part 97 comes complete with its own dictionary? 97.3 includes a list of definitions for the terms used in the document. Two definitions that are either overlooked or misinterpreted by many are 'broadcasting' and 'informational bulletin.' 'Broadcasting' specifically means transmissions intended for reception by the general public (see 97.3 (10)). The term 'informational bulletin,' defined by Part 97.3 (23) has no relation to what we refer to as a packet 'bulletin.' Part 97 defines an 'informational bulletin' as a one-way transmission to hams of a message of subject matter composed solely of interest to the Amateur service. A good example of an informational bulletin is a transmission of ARRL bulletins from W1AW. To conclude that all of this means that a packet bulletin must be confined to Amateur-only subject material is using terribly convoluted logic. Except for unproto, there is no one-way packet mode. It takes two to tango. A packet bulletin is entered on a BBS from the originating station in a two-way communication. From then on out, that packet bulletin is a third-party message. If it gets forwarded from one BBS to another, it is a third-party message being forwarded during a two-way communication. 97.113 lists prohibited communications and their exceptions. There is no specific prohibition against content with potentially controversial or frivolous subject material. This particular 'crisis of the day' arose, as so many others have arisen, because of message content. There is general agreement that many of the bulletins traversing the network aren't worth the electricity used to forward them. Studies in several metropolitan areas show that over 70% of the bulletins NEVER get read. They just get listed. This means users are being very selective about what they read. They DO have a choice. So do sysops. The process of reducing the amount of what many of us consider to be 'noise' on our boards begins with each of us exercising leadership at home. If someone posts a SALE @ ALLUS bulletin on your board trying to unload a camping tent, tell them nicely that this isn't appropriate. If you have a religious fanatic or political alarmist climbing on the electronic soapbox (and that soapbox has your callsign stenciled on the side), it's time for a heart-to-heart. Easy? Not always. Whoever said that running a BBS was gonna be easy? What are you doing to get the word out that packet radio, while sometimes loose, is not a free-for-all. Ham radio, ALL facets of ham radio, because of the wide constituency we have, is a place where people have to be responsible. It's much harder to educate than legislate, but which do you think has the more effective results? The lessons learned: If you've got a question about the rules, use the resources available to you WITHIN the Amateur community INSTEAD of making an end run straight to the Commission. Document who you speak with and what was said. Get whatever you can in writing. Think of the potential impact on ALL of Amateur radio when a small chunk of the overall activity (such as packet in relation to everything else) is the focus of possible new regulation or enforcement. This is not to suggest that the rules be violated or that anyone stick their head in the sand about abuses that may exist. It is better to try to take care of business ourselves, as we are encouraged to do in the rules, than to invite possible over-regulation by the FCC. This issue may be put to rest forever preferably by the League setting the record straight that packet bulletins are not one-way transmissions or broadcasting, and that 97.113 is explicit about permissible content of Amateur communications. Incidentally, I found AB6GQ to be very open about this incident and very surprised to find himself at the eye of a hurricane. He admits to a degree of initial naivet in his effort to be a responsible OO (and now an OOC). Frederick wants everyone to know that he and his team of OOs don't have a hidden agenda and most importantly, they aren't vigilantes. They wanted some answers to questions about packet bulletins. Some missteps and miscommunications (by numerous people) led to something being given far more relevance than it deserved. Submitted October 24, 1994 Dave Wolf, WO5H TAPR BBS-SIG Chair ************************************************************************** EASTNET VHF/UHF Backbone System John T. Gubernard, K2LSX jtg@intac.com The EASTNET VHF/UHF Backbone System [a.k.a. the "EastNet BackBone Network"], referred to as the "EBN," was designed to allow packet information from users and BBSs to flow smoothly over part of the eastern region commonly called "EASTNET." This is being accomplished by building a structured system, with controls on growth to create an environment of maximum throughput. The EBN is not a club or organization, rather a group of interested packeteers who wish to create a packet radio network without engaging in political activities associated with many large clubs. The EBN is structured into three sub-networks, the Local Area Network (LAN), the Regional Network, and Area Network. They are designed as follows: Local Area Network The Local Area Network (LAN) is a point of entry into the EBN system. User stations can connect to other users, other nodes, PBBSs, TCP/IP servers, or gateways on these LAN nodes. All LAN nodes are multi-port nodes removing all inter-node traffic from the LAN or user frequency. The LANs are the only access point available to users of the EBN system. Regional Network The Regional Networks are limited access networks designed to allow communication between nodes within a geographic region. Access to the Regional Network is limited to multi-port network nodes, PBBSs (for mail forwarding only), TCP/IP Gateways, Contest Clusters, and other public server stations. Information destined to nodes outside the Regional Network is sent to the Area Network node associated with that Regional Network. Area Network The Area Network is a main long haul backbone of the EBN. The purpose of this backbone is to move traffic between distant areas of the network, typically about 100 miles between nodes, using above average sites. Area network nodes also serve a Regional Network linking that Regional Network to an Area Network. Communication between the Regional and Area Network is through the RS-232 port of the TNCs at the Area Network site. The structure of the Area and Regional Networks was designed to be transparent to users allowing future upgrades to be implemented without any user impact. The following is a list of active individuals and their e-mail addresses who are associated with the EBN in the Northern New Jersey and Southern New Jersey areas. Mark Herson, N2MH mherson@intac.com Joe Mannino, W2NV joe@intac.com Barry Siegfried, K2MF bgs@intac.com Al Shjarback, WB0MPQ als@intac.com John Gubernard, K2LSX jtg@intac.com Charlie Benn, WB2SNN wb2snn@wb2cop.nj.usa.na Bob Anderson, K2BJG k2bjg@wa2sna.nj.usa.na Ron Hoffman, K2KFE k2kfe@nx2b.ampr.org ************************************************************************** Amateur HF Digital Bibliography Rick Whiting, W0TN Someone on the Ham Digital newsgroup was looking for info on PACTOR the other day. This prompted me to go through my files and prepare a bibliography. This was limited, for the most part, to the ham periodical literature. I specifically excluded professional journals and books as these can be easily located through normal library research techniques. Did I miss any "good ones"? Amateur Radio Periodical Literature Bibliography HF Digital Communications W0TN, Rev. 0, 10-07-94 ALE (Automatic Link Establishment) Adair, Robert T., KA0CKS, David Peach, and Dennis Bodson, W4PWF, "The Growing Family of Federal Standards for HF Radio Automatic Link Establishment (ALE)," Part 1, The National Communications System, The Federal Standards Development Process, and the Basic Definition of Federal Standards 1045 through 1054, QEX, July 1993, pp. 3-8. Wortendyke, David, N0WGC, Chris Riddle, KB0HNM, and Dennis Bodson,, W4PWF, "The Growing Family of Federal Standards for HF Radio Automatic Link Establishment (ALE)," Part 2, Compact Disc for Testing HF ALE Radios, QEX, Aug. 1993, pp. 9-14; Brewster, Larry, N0RNX, and Dennis Bodson, W4PWF, "The Growing Family of Federal Standards for HF Radio Automatic Link Establishment (ALE)," Part 3, Where are the Federal Standards for HF ALE Radio Networking Going?, QEX, Sept. 1993, pp. 14-19; Sutherland, David, and Dennis Bodson, W4PWF, "The Growing Family of Federal Standards for HF Radio Automatic Link Establishment (ALE)," Part 4, Network Simulation for the Radio Amateur, QEX, Oct. 1993, pp. 13-18. Smith, Paul C., K3ZMO, and Dennis Bodson, W4PWF, "The Growing Family of Federal Standards for HF Radio Automatic Link Establishment (ALE)," Part 5, An Amateur's Practical Approach to HF ALE Radio Systems, QEX, Nov. 1993, pp. 9-12. Redding, Christopher, and Dennis Bodson, W4PWF, "The Growing Family of Federal Standards for HF Radio Automatic Link Establishment (ALE)," Part 6, Federal Standard 1049--The Future of ALE Operation in Stressed Environments, QEX, Dec. 1993, pp. 7-9. Levreault, Bob, W1IMM, and Ken Wickwire, KB1JY, "Some Recent Amateur Use of Federal Standard Automatic Link Establishment (ALE) Signaling," Proceedings of the 11th ARRL Conference on Digital Communications, Nov. 1992, pp. 32-39. AMTOR/SITOR Bingemer, Armin, DK5FH, "AMC--The AMTOR Controller," QEX, Feb. 1992, pp. 3-11. Henry, Bill, K9GWT, "New AMTOR Mode," CQ, Nov. 1989, pp. 36-40. Huslig, Michael J., "Unique Identification Signals For CCIR 625," Proceedings of the 12th ARRL Conference on Digital Communications, Sept. 1993, pp. 28-29. Martinez, Peter, G3PLX, "AMTOR, An Improved Error-Free RTTY System," QST, June 1991, pp. 25-27. Newland, Paul, AD7I, "An Introduction to AMTOR," QST, July 1983, pp. 11-13. Newland, Paul, AD7I, "Algorithms and Methods For SITOR/AMTOR Systems," QEX, July 1988, pp. 9-12. Young, Teresa, Stephen Rieman, and David Wortendyke, N0WGC, "A Preview of HF Packet Radio Modem Protocol Performance," Proceedings of the 13th ARRL Conference on Digital Communications, Aug. 1994, pp. 152-155. "HF Modem Over-The-Air Performance Test Report, Globe Link Corporation HF Modem Model GLC-1000A," Fed. Emergency Mgmt. Agency (FEMA), Washington, DC, 20472, Feb. 22, 1993. "HF Modem Over-The-Air Performance Test Report, Ascom Radiocom Ltd. ARTOR HF Modem," Fed. Emergency Mgmt. Agency (FEMA), Washington, DC, 20472, April 12, 1993. APLINK (AMTOR to AX.25 Packet Link) Mortensen, Jim, N2HOS, "APLINK: The Delivery System--Part 1," QST, Oct. 1991, p.73. Mortensen, Jim, N2HOS, "APLINK: The Delivery System--Part 2," QST, Nov. 1991, pp. 81-82. CLOVER Horzepa, Stan, WA1LOU, "CLOVER: The Future of HF Data Communications?," QST, Jan. 1993, p. 107. Petit, Raymond C., W7GHM, "The 'Cloverleaf' Performance-Oriented HF Data Communication System," QEX, July 1990, pp. 9-14. Petit, Raymond C., W7GHM, "The CLOVER-II Communications Protocol Technical Overview," Proceedings of the 11th ARRL Conference on Digital Communications, Nov. 1992, pp. 47-51. Petit, Raymond C., W7GHM, "CLOVER-II: A Technical Overview," Proceedings of the 10th ARRL Conference on Digital Communications, Sept. 1991, pp. 125-129. Westhuizen, Mike Van Der, ZS6UP, "A Practical Comparison Between Clover and Pactor Data Transfer Rates," CQ, Vol. 50, No. 2, Feb. 1994, pp. 40, 42. Young, Teresa, Stephen Rieman, and David Wortendyke, N0WGC, "A Preview of HF Packet Radio Modem Protocol Performance," Proceedings of the 13th ARRL Conference on Digital Communications, Aug. 1994, pp. 152-155. "HF Modem Over-The-Air Performance Test Report, HAL Communications Corp. PCI-4000 HF Modem," Fed. Emergency Mgmt. Agency (FEMA), Washington, DC, 20472, July 6, 1993. G-TOR Anderson, Phil, W0XI, Michael Huslig, Glenn Prescott, WB0SKX, and Karl Metcalf, WK5M, "G-TOR The New, Faster HF Digital Mode for the KAM-Plus," Kantronics, Inc., 1202 E. 23rd St., Lawrence, KS 66046, U.S.A.,1994. Huslig, Mike, Phil Anderson, Karl Medcalf, and Glenn Prescott, "G-TOR: The Protocol," Proceedings of the 13th ARRL Conference on Digital Communications, Aug. 1994, pp. 49-79. Huslig, Richard, and Phil Anderson, "GMON--A G-TOR Monitoring Program for PC Compatibles," Proceedings of the 13th ARRL Conference on Digital Communications, Aug. 1994, pp. 80-85. Prescott, Glen E., WB0SKX, and Phil Anderson, W0XI, "A Theoretical Evaluation of the G-TOR Hybrid ARQ Protocol," Proceedings of the 13th ARRL Conference on Digital Communications, Aug. 1994, pp. 86-89. Prescott, Glenn, WB0SKX, Phil Anderson, W0XI, Mike Huslig, and Karl Medcalf, WK5M, "G-TOR: A Hybrid ARQ Protocol for Narrow Bandwidth HF Data Communication," QEX, May 1994, pp. 12-19. Prescott, Glenn E., WB0SKX, and Phil Anderson, W0XI, "Hybrid ARQ For HF Data Transmission," Communications Quarterly, Vol. 4, No. 3 (Summer), 1994, pp. 31-40. Packet (AX.25) [Not recommended for HF] AX.25 Amateur Packet-Radio Link-Layer Protocol, Version 2.0, Oct. 1984, American Radio Relay League, 225 Main St., Newington, CT 06111, U.S.A. Karn, Phil, KA9Q, "Spectral Efficiency Considerations for Packet Radio," Proceedings of the 10th ARRL Conference on Digital Communications, Sept. 1991, pp. 62-66. McLarnon, Barry D., VE3JP, "HF Packet: Where Do We Go From Here?," Proceedings of the 6th ARRL Conference on Digital Communications, Aug. 1987, pp. 126-133. Young, Teresa, Stephen Rieman, and David Wortendyke, N0WGC, "A Preview of HF Packet Radio Modem Protocol Performance," Proceedings of the 13th ARRL Conference on Digital Communications, Aug. 1994, pp. 152-155. PACTOR Clas, Martin, DL1ZAM, and Peter Mack, DL3FCJ, "PTC--The PACTOR Controller," QEX, Oct. 1991, pp. 7-11. Helfret, Hans-Peter, DL6MAA, and Ulrich Strate, KF4KV, "PACTOR--Radioteletype With Memory ARQ and Data Compression," QEX, Oct. 1991, pp. 3-6. Reedy, Gwyn, W1BEL, "PACTOR: An Overview of a New and Effective HF Data Communication Protocol," Proceedings of the 11th ARRL Conference on Digital Communications, Nov. 1992, pp. 62-64. Westhuizen, Mike Van Der, ZS6UP, "A Practical Comparison Between Clover and Pactor Data Transfer Rates," CQ, Vol. 50, No. 2, Feb. 1994, pp. 40, 42. Young, Teresa, Stephen Rieman, and David Wortendyke, N0WGC, "A Preview of HF Packet Radio Modem Protocol Performance," Proceedings of the 13th ARRL Conference on Digital Communications, Aug. 1994, pp. 152-155. "HF Modem Over-The-Air Performance Test Report, Globe Link Corporation HF Modem Model GLC-1000A," Fed. Emergency Mgmt. Agency (FEMA), Washington, DC, 20472. PACTOR II Rink, Dr. Tom, DL2FAK, "Update on the Development of PacTOR-2," Special Communications Systems, Rontgenstr. 36, 63454 Hanau, Germany. Miscellaneous Baiya, Harun, David Balson, and Gary Garriott, "Digital Radio Technology and Applications," Proceedings of Intl. Workshop organized by the Intl. Dev. Res. Center, Volunteers In Technical Assistance (VITA), and UN University, Nairobi, Kenya, Aug., 1992. Cadmus, Clayton, KA0GKC, and Bruce L. Meyer, W0HZR, "FSK Signal Monitor," Communications Quarterly, Vol. 3, No. 2 (Spring), 1993, pp. 45-50. Chandler, Dr. Alan, K6RFK, "HF Modems for Data Transmission, A look at the Differences Between Commonly Used Designs," Communications Quarterly, Vol. 1, No. 2 (Spring) 1991, pp. 74-78. Clark, Tom, W3IWI, "Comments on HF Digital Communications Part 1--Link Level Issues," Proceedings of the 9th ARRL Conference on Digital Communications, Sept. 1990, pp. 265-270. Clark, Tom, W3IWI, "Comments on HF Digital Communications Part 2--Data Protocol Issues," Proceedings of the 9th ARRL Conference on Digital Communications, Sept. 1990, pp. 271-274. Henry, Bill, K9GWT, and Ray Petit, "HF Radio Data Communication, CW to CLOVER," Communications Quarterly, Vol. 2, N0. 2 (Spring), 1992, pp. 11-24. Johnson, Lyle V., WA7GXD, "Thoughts on an Adaptive Link Level Protocol," Proceedings of the 8th ARRL Conference on Digital Communications, Oct. 1989, pp. 97-107. Kinsner, W., VE4WK, "Lossless Data Compression Algorithms for Packet Radio," Proceedings of the 10th ARRL Conference on Digital Communications, Sept. 1991, pp. 67-75. Karn, Phil, KA9Q, "Toward New Link-Layer Protocols," QEX, June 1994, pp. 3-10. McIntyre, Lewis F., "Error Correction In Data Transmission," Communications Quarterly, Nov. 1990, pp. 88-94. Nagle, John J., K4KJ, "Diversity Reception: An Answer to High Frequency Signal Fading," Ham Radio, Nov. 1979, pp. 48-55. Shapiro, Garry, NI6T, "Optimizing the PK-232MBX for RTTY and AMTOR," Communications Quarterly, Vol. 3, No. 1 (Winter), 1993, pp. 83-91. Sykes, B., G2HCG, "The Enhancement of HF Signals By Polorization Control," Communications Quarterly, Nov. 1990 pp. 23-28. Wickwire, Ken, KB1JY, "The Status and Future of High Frequency Digital Communications," Part 1: Overview, QEX, June 1992, pp.3-14. Wickwire, Ken, KB1JY, "The Status and Future of High Frequency Digital Communications," Part 2: HF Modems and Their Performance, QEX, July 1992, pp. 3-15. Wickwire, Ken, KB1JY, "The Status and Future of High Frequency Digital Communications," Part 3: Simulating The Performance Of HF Digital Networks, QEX August 1992, pp. 12-17. Wickwire, Ken, KB1JY, "The Status and Future of High Frequency Digital Communications," Part 4: Where Is HF Digital Networking and Where Is It Going, QEX, Oct.1992, pp. 10-18. "Low-Cost Digital and Packet Radio Techniques: Operation and Applications," Volunteers in Technical Assistance (VITA), Arlington, VA, Spring 1994. Proceedings of the 3rd FEMA MF/HF Packet Radio Conference, Fed. Emergency Management Agency (FEMA), Washington, D.C. 20472, April 1992. ************************************************************************** MFJ-9600 Modem Modification David Bray, N0ITS N0ITS @ KB0CZV.#NWCO.CO dcbr@chevron.com I have been working with other node-ops around my area to assist them with setting up 9600 baud links, and have found a disturbing characteristic of all five of the MFJ-9600 modems I have come in contact with. If the transmit output level on the modem is set to anything over the lower 1/3 or 1/2 of the adjustment range the signal becomes very distorted. I have determined that the source of this trouble is when the signal passes through Q4 and Q5 on the modem board. I have been bypassing these transistors by removing C34 and C37, connecting them in series, and re-inserting them back into the board so that the signal will still go from U10 (pin 1) to the output of the modem. The only reason I can see that Q4 and Q5 are there in the first place is to remove the TXD line from PLL radios when the oscillator you are modulating is also a reference for the receiver. When this change is made, the modem gives a clean output signal, and is working well in our network at all five locations where these modems are in place. I have successfully interfaced this modem with Motorola Micor UHF mobile, Motorola Maxar UHF mobile, and Motorola Syntor UHF mobile radios. I hope this helps all of you out there. ************************************************************************* Interfacing the TAPR Deviation Meter to a PRO-508 Toshio Imao, JA2DXY Thank you for developing the very convenient TAPR Deviation Meter Kit (version 1.0). This report describes how to interface this tool to a Radio Shack PRO-508 Scanner. Step 1: connections: Step 2: Configuration of the EEPROM values: B65A change to 29 ; for IF frequency B65B change to CC ; change to 10.7 MHz B62B change to 85 ; for discriminator B62C change to 00 ; output polarity B62E change to 85 ; B62F change to 1F ; This completes the modification except for the connection of the power supply lines. ************************************************************************* Packet Radio Network for Volcano Monitoring Roland Machenbaum 8 Tour-de-Champel 1206 Geneve, Switzerland. internet: machen@univ-savoie.fr Abstract This paper describes an implementation of a packet radio network on Taal volcano (Philippines). The network, based on Amateur radio hardware and software, allows the Philippine Institute of Volcanology and Seismology (PHIVOLCS) to retrieve real-time data from various instruments located on and around the volcanic island. The actual list of instruments includes 10 digital seismic stations, 3 tiltmeters, 2 radon sensors, 1 geochemical station (water temperature and conductivity), and an acoustic station. The original features of the network are the use of only one radio frequency simplifying frequency allocation procedures and equipment management, redundancy allowing failures of nodes without loss of data, and low power consumption reducing the cost of field power supplies. The network is linked to the Internet by a radio link from PHIVOLCS to the University of the Philippines (UP). This link allows foreign organizations to access the data, and provides basic Internet services (mail, ftp, telnet,...) to PHIVOLCS and any user located in the Taal vicinity. The Volcano Taal volcano is a 5 km diameter island located 60 km south of Manila and is situated in a 20 km diameter caldera filled by a lake. Its last eruption occurred in 1977 and its history is composed of several deadly eruptions. As such, it has been chosen as one of the 10 decade volcanoes by the International Decade for Natural Disaster Reduction commission (IDNDR). Joint projects between PHIVOLCS and the University of Savoie, France have improved the monitoring of this volcano. Transfer of data between the island and PHIVOLCS' main office in Manila has always been a problem due to the lack of existing communication infrastructure on the island. Packet Radio Solution Radio Amateurs have developed packet radio for more than 10 years now and have constructed a worldwide network supported by a constellation of satellites. The choice of Amateur radio hardware and software was motivated by its low price, proven reliability, and a large choice of equipment. The basic equipment to access or create a network is a radio, a TNC (Terminal Node Controller) and a computer or terminal. The TNC chosen has a 9600 bps raw bit rate on the radio port and the radio is a 2 Watt UHF transceiver. The frequency assigned by the NTC (National Telecommunication Commission) for the network is 424.850 MHz. A growing community is using the excellent NOS (Network Operating System) of Phil Karn, KA9Q which implements TCP/IP over packet radio. An upgraded version of NOS was used to link PHIVOLCS and the Taal network to the internet. TNC+ As suggested by its name, the TNC can act as a node and as a terminal simultaneously. The TNC alone acts as a repeater ("digipeater" in Amateur radio terms). With a computer connected to its serial port, more sophisticated routing functions can be added. Software exists to replace the original repeater function by higher-level routing functions, but most of the time the terminal function of the TNC is then lost. The digipeating scheme is not efficient in noisy environments if the number of hops between the source and destination is greater than 1. A packet lost on any segment of the link will be retransmitted starting from the source even if it successfully crossed the first segments. Delays and low throughput appear on a digipeater based network. Most instruments cannot be connected directly to the serial port of the TNC. For the volcano monitoring application, it is costly and not practical to install a computer at every node of the network. So another kind of interface is needed. Most of the nodes of the network will be idle when no measurements are being taken. For example, the sampling of a tiltmeter takes 10 seconds every 15 minutes. Power could be saved by turning off the unused communication equipment during idle time. Less power consumption results in less expensive, lighter and easier design of solar panel and battery power supplies. To overcome the above problems it was decided to design a special interface board that would connect to the serial port of the TNC and add the following functions: packets are acknowledged on every segment to avoid retransmission over the whole link. This is an improvement over the digipeater scheme. switching off and on, at preset times, of the radio and TNC to save power. provide 3 asynchronous serial ports, 1 synchronous serial port, 16 output lines, 8 input lines, 1 counter input, 3 analog input channels (8 bit A/D converter) direct connection of up to 8 A/D converters (21 bit, 2 channels, analog amplifier with programmable gain ranging from 1 to 128) monitoring of the power supply voltage (battery level) remote modification of the TNC parameters a watchdog will reset the board and TNC if the TNC stays continuously on or off for more than 3 hours. This could be due to hanging of the board, the instrument, or the master PC. This feature improves reliability of the network. The interface board is a MC68HC11 microcontroller with 32 Kb memory expandable to 128 Kb. The TNC is running a radio Amateur software package, called "The Firmware," copyrighted by NORD>>This software is labelled "free for non-commercial usage." The interface board uses the host mode of The Firmware. The TNC connected to its interface board was named TNC+. The Taalnet software This software is running on a PC (386/33) and implements the master function of the network. It is written in Borland Pascal version 7 and runs in protected mode. It is composed of several units, one unit contains the specific list of commands used to retrieve data from each instrument. This unit needs to be updated when a new instrument is added. Field stations are called periodically. The current settings are the following: The main 15-minute period is subdivided into three 5-minutes intervals. At the beginning of the first interval, the low frequency data are retrieved, connections are established to the 3 tiltmeters, the 2 radon sensors and the geochemical station. The total call lasts 1.5 minutes so several low frequency instruments can still be added. The second interval is reserved for the call to the acoustic station. This station is composed of a hydrophone located in the main crater lake at a depth of 40 meters and connected to a digital oscilloscope (Fluke Scopemeter PM97) through a set of filters. Taalnet will switch the filters and drive the oscilloscope to perform waveform acquisition at various frequencies. The call lasts from 1.5 to 3 minutes depending on the amount of data to be retrieved. The last interval is dedicated for the call to the digital seismic stations. These stations continuously monitor seismic signals and a triggering algorithm runs concurrently to detect seismic events. Upon detection, the event is stored in the on-board memory. A maximum of 32Kb can be retrieved from this station due to limitations in the node's buffer. An external clock source consisting of an OMEGA signal receiver is needed to insure correct time stamping of the data. Only one station is called at each seismic station interval, so for 10 stations the period is 10x15 minutes (2 hours and 30 minutes). The call lasts from 2 to 5 minutes depending on the number of relays to be crossed. This scheme causes delays in the reception of seismic data but avoids the overloading of the network in case of seismic swarms. Previously, the 10 stations were polled for data at each seismic interval. This scheme will be reintroduced when another type of digital seismic station becomes available. At the beginning of a call, an "unproto" (connectionless) packet is sent to synchronize the clock of remote nodes to the PC clock. The unproto mode was chosen to avoid automatic retransmission of these packets without control of the upper protocol layer. A node will read the contents of the synchronization packet and update its clock accordingly. If the packet was delayed due to retransmissions, the node would not be aware of that fact and would update its clock according to a time already elapsed. It is better not to receive a synchronization packet than to receive an incorrect one and have it retransmitted after an unknown delay. At the end of each call, Taalnet checks the battery level of the nodes, the correct reception of the synchronization packet, the next wake-up time of the node, and if it has been reset. This information is stored in log files. If the node has reset, or if an error is detected, the wake-up configuration parameters will be sent. After no error is detected the node will be turned off. On the Taal network, 2 relays are configured as permanently "on" to allow communication over the network at any time (see Internet Access). In case of failure of a link, another route, if available, will be tried. The new route will be remembered and tried first on the next call. Taalnet uses the Dijkstra algorithm to find the shortest route to a node. The topology and the status of the network is displayed on the screen along with the time remaining before the calls to each node. Different colors show links currently used, links out of order, stations connected, and stations having low battery voltage. When no data transfer is in progress the user can use the Taalgraf option (written by Nicolas Poussielgue) which draws graphs showing the variation of all the parameters measured during the last 8 days. Taalgraf can also be invoked from any computer connected to the LAN (Local Area Network). Early battery problem detection is possible by using Taalgraf daily. All Taalnet parameters and even Taalnet itself are stored on the file server (see Data Organization). This allows telemaintenance of the network through the Internet. People having access rights can remotely change the parameters or update the Taalnet version. Data Organization A SUN IPX workstation is used as the central file server for Taal data by running the NFS server. If the LAN is operational, the data gathered by the Taalnet software is stored on the file server, if the LAN or the IPX is down, the data is stored on the local hard disk of the PC running Taalnet. Data will be appended automatically on the file server when the LAN is restored. Most of the PCs connected to the LAN are running the NFS client software allowing the access of Taal data by multiple users simultaneously. Foreign organizations can also access the IPX through the Internet allowing worldwide distribution of the data. Internet Access The installation of the link to the Internet was done in collaboration with ASTI (Advanced Science and Technology Institute) based in the University of the Philippines (UP). Most of the work was done by Denis Villorente of ASTI and comprised mainly of searching, compiling and testing of different NOS versions followed by correct configuration of the NOS parameters and other UNIX machines on the network. The hardware is composed of a PC with an ethernet board, a 9600 baud TNC, a TEKK radio and a Yagi antenna at each side of the link. The distance between PHIVOLCS and UP is about 5 km. ASTI is connected to the Internet via a 64 kbit/s leased line. The radio frequency used is the same as the one used for the Taal network. This allows any user in the Taal vicinity to access the Internet, and theoretically, any Internet user to access the Taal network, although problems will appear with heavy traffic. The parameters give priority to the gathering of data from Taal, but in case of poor radio conditions (encountered during daytime), the use of the same frequency will cause disconnections on the Taal network and the data currently being transferred will be lost. To overcome this problem the link to UP will be replaced by a public switched telephone link. However the radio interface in PHIVOLCS will be kept to allow users in the Taal vicinity to access the Internet. The PCs are running the grinos (Gerard van der Grinten, PA0GRI) version of NOS. The PC in PHIVOLCS is also the mail server and users can read and write their mail from any computer running the popmail software and connected with an ethernet board to the LAN. The domain "phivolcs.dost.gov.ph" was created with its primary name server consisting of a SUN SPARC 2 workstation located in the PHIVOLCS building. This phivolcs domain is not mandatory for the Internet connection, but to simplify separation between ASTI and PHIVOLCS. Access to the Internet from Taal is done using a 9600 baud TNC, TEKK radio and a computer or terminal. An AX.25 connection is established to one of the PCs running grinos. The list of relays used (digipeaters) must be specified with the "connect" command. The user can then read or send his mail or issue a telnet connection to any Internet host. To check the latest data retrieved from Taal, the user needs to issue a telnet connection to the SPARC IPX of PHIVOLCS. If the user doesn't have his own TNC and radio he can go to any of the instruments and use the equipment there. Data gathering from Taal is not affected if the communication traffic is kept low. The access from Taal has proven its usefulness by facilitating the maintenance of the monitoring network: a technician or scientist in the field can keep in touch with his team anywhere in the world in case of questions or problems. In case of emergency, the network could help to relay information directly to and from the volcano and its surroundings. Source and cost of software and hardware mentioned in this paper: nos, grinos: by ftp anonymous to ftp.ucsd.edu, free popmail: by ftp anonymous to univax.univ-savoie.fr, free nfs: by ftp anonymous to univax.univ-savoie.fr, 20 US$/year (shareware) TNC+ composed of: TNC-2H (9600 baud): Symek, Germany, 250 US$ TNC interface board: contact the author, 350 US$ Radio KS-960: Tekk, USA, 250 US$ Taalnet: contact the author, free ************************************************************************** Regional Organization List If you have corrections or additions to this list, please contact the office. TAPR hopes to keep this list as accurate as possible in order to refer information and individuals to their regional group(s). List is current as of 15 Dec. 1994 Amateur Radio Research and Development Corp (AMRAD) PO Box 6148 McLean, VA 22106-6148 Newsletter: AMRAD Newsletter American Radio Relay League (ARRL) 225 Main St Newington, CT 6111 Internet: INFO@ARRL.ORG Newsletter: QEX / Gateway Arizona Packet Radio Association 8402 E Angus Dr Scottsdale, AZ 85251 Central Illinois Packet Radio User Society (CIPRUS) c/o Larry Keeran K9ORP RR 1 Box 99B Downs, IL 61736-9717 Central Iowa Technical Society (CITS) c/o Ralph Wallio W0RPK 1250 Hwy G24 Indianapolis, IA 50125 Chicago Amateur Packet Radio Association (CAPRA) PO Box 8251 Rolling Meadows, IL 60008 Newsletter: The CAPRA Beacon Cincinnati Amateur Packet Radio Experimenters Society (CAPRES) c/o John Schroer IV KA8GRH 948 Halesworth Dr Forest Park, OH 45240 Colorado Digital Electronics (CODE) 3631 Brentwood Terrace Colorado Springs, CO 80910 Internet: info@code.org Colorado Packet Association (COPA) c/o John Radomski KT0H 2080 S Fairplay Aurora, CO 80014 Connecticut Digital Radio Association (CONNECT) c/o Tom Hogerty, KC1J 83 Harold Rd Farmington, CT 6032 Eastern Packet Radio of Michigan (EPROM) c/o Jay Nugent WB8TKL 3081 Braeburn Cir Ann Arbor, MI 48104 EastNet BackBone Network (EBN) c/o John Gubernard, K2LSX 81 Harcourt Ave Bergenfield, NJ 07621-1916 Florida Amateur Digital Communications Association (FADCA) 812 Childers Loop Brandon, FL 33511 Newsletter: FADCABeacon Georgia Radio Amateur Packet Enthusiast Society (GRAPES) PO Box 871 Alpharetta, GA 30239-0871 Newsletter: Grapevine Hamilton and Area Packet Network (HAPN) Box 4466 Station D Hamilton, ON L8V 4S7 Canada HEX 9 Group PO Box 151 Orilla, ON L3V 6J3 Canada Mid-Atlantic Packet Radio Club c/o Tom Clark W3IWI 6388 Guilford Rd Clarksville, MD 21029 Mississippi Amateur Radio Digital Association (MARDA) c/o Patrick J Fagan WA5DYV 2412 E Birch Dr Gulfport, MS 39503 Mt Ascutney Amateur Packet Radio Association c/o Carl Breuning N1CB 54 Myrtle St Newport, NH 03773 Mt Beacon Amateur Radio Club PO Box 841 Wappingers Falls, NY 12590 New England Packet Radio Association (NEPRA) PO Box 208 East Kingston, NH 03827 Newsletter: NEPRA PacketEar North East Digital Association (NEDA) PO Box 563 Manchester, NH 03105 Northern California Packet Association (NCPA) 6608B Alhambra Ave Suite 111 Martinez, CA 94553 Newsletter: NCPA Download Northwest Amateur Packet Radio Association (NAPRA) c/o John Gates N7BTI 750 Northstream Ln Edmonds, WA 98020 Newsletter: Zero Retries Ohio Packet Enthusiasts Club (OPAC) c/o Bob Ball WB8WGA 830 Riva Ridge Blvd Gahanna, OH 43230 Oregon Digital Network Coordination Council (ODNCC) 7860 SW 69th Av Portland, OR 97223 Pacific Packet Radio Society (PPRS) PO Box 51562 Palo Alto, CA 94303 Packet Radio Organization of Montana (PROM) c/o Glenda Allen KE7TB 165 Conifer Rd Libby, MT 59923 Packeteers of Long Island (POLI) c/o Alex Mendelsohn AI2Q 92 Hathaway Av Elmont, NY 11003 Newsletter: The POLI Parrot Pennsylvania Packet Association (PaPA) c/o Bryan Simanic WA3UFN 9 Wild Cherry Dr DuBois, PA 15801 Radio Amateur Satellite Corp (AMSAT) PO Box 27 Washington, DC 20044 Newsletter: AMSAT Journal Radio Amateur Telecommunications Society (RATS) c/o J Gordon Beattie Jr N2DSY 206 North Vivyen St Bergenfield, NJ 07621 Rochester Packet Group c/o Fred Cupp W2DUC 27 Crescent Rd Fairport, NY 14450 San Diego Packet Group (SDPG) c/o Mike Brock WB6HHV 10230 Mayer Cir San Diego, CA 92126 San Diego Packet Radio Association (SANDPAC) c/o Barry Gershenfeld 5085 Arroyo Lindo Av San Diego, CA 92117 Newsletter: San Diego Packet Radio Association Newsletter South Carolina Amateur Radio Digital Society (SCARDS) PO Box 1281 Columbia, SC 29202 Newsletter: SCARDS Newsletter Southern Amateur Packet Society (SAPS) c/o Wayne Harrell WD4LYV Rt 1 Box 368 Sycamore, GA 31790 Southern California Digital Communications Council (SCDCC) PO Box 2744 Huntington Beach, CA 92647-2744 Newsletter: The I-Frame Tennessee Network (TENNET) c/o Jeffrey Austen K9JA 2051 Clearview Drive Cookeville, TN 38506 Internet: jra1854@tntech.edu Texas Packet Radio Society (TPRS) PO Box 50238 Denton, TX 76206-0238 Internet: dwolf@tcet.unt.edu Newsletter: The TPRS Quarterly Report Tucson Amateur Packet Radio Corporation (TAPR) 8987-309 E. Tanque Verde Rd #337 Tucson, AZ 85749-9399 Internet: TAPR@TAPR.ORG Newsletter: Packet Status Register TwinsLAN Amateur Radio Club c/o Kermit Kramer W0RFD 1121 Xerxes Av S Minneapolis, MN 55405 Newsletter: The TwinsLAN Beacon Utah Packet Radio Association (UPRA) c/o Bart Van Allen KA7ZFD 11883 S Kinney Cir Riverton, UT 84065 Vancouver Amateur Digital Communications Group (VADCG) 9531 Odlin Rd Richmond, BC V6X 1E1 Canada Newsletter: The Packet Wake Digital Communications Group (WDCG) c/o Randy Ray WA5SZL 9401 Taurus Ct Raleigh, NC 27612 Western Michigan Packet Radio Association (WMPRA) PO Box 4612 Muskegon, MI 49444 Wisconsin Amateur Packet Radio Association (WAPRA) PO Box 1215 Fond Du Lac, WI 54935 Newsletter: Badger State Smoke Signals ************************************************************************* ICOM IC-970 Modem Interfaces for Satellite Communications Roy Welch, W0SL This is not a 9600 modification. This is the procedure for setting the IC-970 up for 1200 bps PSK satellites. Do not use the IC-970 microphone connector for transmit or receive audio. There seems to be too much audio shaping in this path. Use the DATA connector on the back of the IC-970. I have tried it both ways without much luck through the microphone connector. The DATA connector method works very well. PacComm PSK-1 Modem 1. IC-970 Interface - The IC-970 DATA connector leads to be used are as follows (see page 13 of owner's manual): a. Pin 1 is transmit audio from the PSK-1 VHF RADIO connector pin 1 to IC-970. b. Pin 7 is the push to talk lead from the PSK-1 VHF RADIO connector pin 3. c. Pin 8 is the UP/DOWN lead from the modem to the IC-970. This lead is connected to the PSK-1 UHF RADIO connector pin 1. Install a 470 ohm resistor from pin 1 to pin 5 of the PSK-1 UHF RADIO connector. d. Pin 9 is a ground lead to the PSK-1 VHF RADIO connector pin 2. e. Pin 10 is the SUB band audio output from the IC-970 to the PSK-1 VHF RADIO connector pin 4. (See Note 1) 2. Set the PSK-1 parameter configuration as follows: MODE - SATellite MODEM - IN (in line) JT/SP - JOINT (for IC-970) AFC - USB or LSB (same as the mode selected on the IC-970) KC TUNER RADIO TYPE - NONE (not used at this station) RS232 SPEED - (RS232 port not used at this station) DCD SENSE - Use default except for the Kantronics TNC. (Doesn't seem to make a difference in Full Duplex mode). MAXIMUM STEP RATE - 12 steps per second MIC-CLICK SENSE - ACTIVE LOW (for IC-970) CLICKS-PER-STEP - 1 The PSK-1 allows about 150 to 200 hertz drift before frequency correction pulses begin. In the IC-970 in SSB mode, each pulse results in a 10 hz frequency change. Ten such pulses occur for each change in the IC-970 frequency readout. The above arrangement will track an overhead satellite pass with maximum Doppler shift. TAPR PSK MODEM 1. IC-970 Interface - The IC-970 DATA connector leads to be used are as follows (see page 13 of owner's manual): a. Pin 1 is transmit audio from the modem VHF RADIO connector pin 1 to IC-970. b. Pin 7 is the push to talk lead from the modem VHF RADIO connector pin 3. c. Pin 8 is the UP/DOWN lead from the modem to the IC-970. This lead is connected to the modem UHF RADIO connector pin 5. d. Pin 9 is a ground lead to the modem VHF RADIO connector pin 2. e. Pin 10 is the SUB band audio output from the IC-970 to the modem VHF RADIO connector pin 4. (See Note 1) 2. Construct the following circuit on a 12-pin header strip socket and install it on the combination JP5/JP6 plug in the modem: $&topview[v] The TAPR PSK modem allows about 30 to 40 hertz drift before frequency correction pulses begin. In the IC-970 in SSB mode, each pulse results in a 10 hz frequency change. Ten such pulses occur for each change in the IC-970 frequency readout. The above arrangement will track an overhead satellite pass with maximum Doppler shift. Note 1: The IC-970 DATA connector pin 10 only carries SUB band audio. In order to use your TNC for simplex (MAIN band) terrestrial packet communications you must obtain Main band audio from IC-970 DATA connector pin 5. This will require you to provide a means of switching the modem (PSK-1 or TAPR) VHF RADIO connector pin 4 to either IC-970 DATA pin 10 or DATA pin 5 for SUB band or MAIN band audio respectively. Note 2: The IC-970 has an internal switch (see pages 13 & 42 in your owner's manual) which lets you set this input for 100 mv (default) or 3 mv. Placing a jumper on JP5 in the PSK-1 or JP7 in the TAPR PSK modem significantly increases the level of transmit audio from the modem which can then be adjusted with R40 on the rear panel of the PSK-1 or R6 in the TAPR modem. You should leave the IC-970 in the 100 mv input position in this case. ************************************************************************** IC-970 Modification For 9600 bps Operation Roy Welch, W0SL Read all of this before starting any mods! 1. Prepare three lengths of small coax, each in series with a 10mfd non-polarized capacitior. The capacitors can be made an integral part of the coax using shrink tubing such that the braid of the coax and the one free lead of the capacitor extend from the end of the shrink tubing. The capacitor lead and the braid lead should be brought out of the shrink tubing, each inside of its own insulated sleeving. The capacitors provide DC blocking and the shrink tubing arrangement provides as small a package as possible at the Main circuit board end of the coax lead (space is a bit tight). 2. If you have the IC-970-H model, remove the power supply from the top and lay it over the side of the IC-970. This will reveal a metal tray beneath the supply. Don't drop the screws! It will be a real troublesome job trying to find them again down in the guts of the radio. Use a screwdriver with a screw holding attachment. It will be a real help. 3. Remove the metal tray from the top of the radio. Don't drop the screws. This will reveal the MAIN circuit board where all wiring will be done. 4. Remove all screws around the circuit board holding it to the radio. Again, watch the screws! By now you can guess that I dropped one. 5. Locate IC-11, IC-5, and D16. The Main Band receive FM audio is on pin 9 of IC-5. The Sub Band receive FM audio is on pin 9 of IC-11. The transmit audio is sent to the anode of D16. 6. You must turn the circuit board over to reach the foil side to make connections. This will require unplugging one or two of the interboard connectors. 7. Solder the capacitor leads of the prepared coax to pin 9 of IC-11, pin 9 of IC-5 and anode of D16. The connections may be made to any convenient spot on the foil that leads to the proper connection spot. The coax braid lead is soldered to nearby chassis ground foil. You will have to trace the ground foil from the nearest mounting screw hole out to where it comes near to the connection points. Check carefully for solder bridges, shorts, etc. Be sure to label the free ends of the coax NOW!! If you don't, you will kick yourself around the block when you get the board back in and then try to figure out which coax lead is which. Replace the board, routing the free ends of the coax to the right rear of the radio near the accessory socket. Don't drop the screws! 8. Remove the blank metal cover plate from the spare accessory plug holes in the back of the radio. Fabricate another cover (easy to do) so you can retain the original for replacement sometime when you sell the radio. Mount a small DPDT Radio Shack type switch on this metal plate so it protrudes from the rear through one of the two blank accessory holes. This switch will switch the 9600 audio output from either the Main Band (for terresterial packet) or from the Sub Band (for satellite packet). 9. Wire the two receive audio leads and another short length of small coax to the switch so you can switch either of the receive audio leads to the short length of small coax. Solder the coax braids to the unused switch terminals. It is not required, but it is a nice place to terminate these leads. Replace the new cover plate with the switch protruding from the back of the radio. It is easy to remember the switch positions if you mount the switch such that toggle up is MAIN band and down is SUB band receive. 10. The D16 lead, and the now single receive audio lead from the switch will be terminated on two unused pins on the DATA socket on the rear of the radio. Connections will be made on the small circuit board attached to the data socket. This whole assembly can be removed by removing a couple of screws and one cable plug. 11. On the small circuit board find the pads that go to DATA socket pin 6 and pin 11 (currently not used). Solder the D16 lead to one lead of a 2200 ohm resistor and the other lead of the resistor to the pad going to pin 6 (resistor prevents loading down the regular mic audio). You can put this resistor in series with the capacitor at the D16 end if you wish and are neat about it. I personally feel it should be installed at the DATA socket as described so that if you ever want to change its value to help the transmit audio level on a stubborn 9600 modem, you won't have to worry about dropping screws again. Solder the receive audio lead to the pad going to DATA socket pin 11. Solder both the coax braids to a nearby chassis ground pad. 12. CAUTION: Data socket pin 13 has 13.8 volts DC on it. It is a good idea to cut the solder side of this pin or otherwise insulate it on any plug you plug into the DATA socket. The spacing is close and soldering to the 13 pin "DIN" plug is rather trying. You DO NOT want 13.8 volts DC getting shorted to something and vaporizing a foil trace in your radio or otherwise going into your 9600 modem by accident. 13. We used this arrangement at the Soviet Space Exhibit and it worked fine. I have made mods. to both the H and A models of the IC-970. Good luck and have fun (you will if you don't drop any screws). *************************************************************************** D93WE: A Windows Development Environment for the TAPR/AMSAT DSP-93 Tom McDermott, N5EG This article describes the D93WE (DSP-93 Windows Environment) program, a Windows development environment for the TAPR/AMSAT DSP-93 digital signal processing unit. The purpose of the development environment is to provide the following features in an easy-to-use point-and-click Windows interface: Download of already-assembled software to the DSP-93 Fast, efficient Edit/Assemble/Download cycle for development of TMS320C25 assembly programs Various utility programs, such as oscilloscope, function generator, and spectrum analyzer Integrated communications terminal that operates at 19 Kbaud, including Cut, Copy, Paste, Clear, Search, etc. The program runs on a PC or compatible computer running Windows 3.1. It is written in Borland C++ version 3.1, and uses the Object Windows Library (OWL), version 1.0. The OWL is an object-oriented interface to Windows, and provides a clean, robust implementation. Several design issues arose with the choice of the OWL interface to Windows, but the speed of development effort and the solidness of the application are attributable to the choice of this package. The total software package is about 4,000 non-comment source lines of code, including C++, TMS assembly, and resource files. The D93WE package is provided along with the DSP-93 unit by TAPR. DSP-93 Hardware The DSP-93 was developed by Bob Strickland, N5BRG. It is a powerful, general purpose DSP board set based on the Texas Instruments TMS320C25 processor. Several analog interface boards have been planned, the one currently available is a voice-frequency board optimized for audio-bandwidth signal processing, and optimized for interconnection to various radios at audio frequency. This analog board is based on the Texas Instruments TLC32044 converter (CODEC) IC. This IC contains anti-aliasing filters, a 14-bit A/D, a 14-bit D/A, and reconstruction filters. The sample rate and the bandwidth of the filters are programmable, but not with very much resolution. Due to the low resolution of the 32044 counters, and difficulty in changing the sample rate, the sample rate was held constant, and much of the software selectively discards samples in order to alter the effective net sample rate. DSP-93 Software The TMS assembly code makes use of the excellent monitor ROM in the DSP-93, providing many of the needed interfaces between the DSP-93 and the Windows program. The monitor ROM provides a software download capability, and the ability to start an application. It also provides calls to allow receiving or sending ASCII characters between the DSP-93 and the Windows program, and it provides a call to reset the DSP-93 back to the monitor. The four DSP software programs that were developed to support the Windows D93WE application consist of four TMS assembly modules: Sampling Oscilloscope Function Generator Spectrum Analyzer Memory Test Sampling Oscilloscope The sampling oscilloscope is a simple idea, with a few complications. The Windows code first downloads the program to the DSP-93 and starts it, then waits for the user to click a button. The START button initiates sampling by the DSP-93. D93WE sends a parameter-block (some ASCII hexadecimal characters) to the DSP-93 that define the sampling interval, trigger level, trigger slope, voltage gain + port selection, and auto-trigger flag. The DSP-93 software sets the A/D to sample at a 62.5 kilosamples/second rate. However, the software discards most of the samples. The more it discards, the slower the net sampling rate. When you choose the sweep rate on the oscilloscope, you are setting the number of samples that the DSP-93 throws away between samples that it keeps. The trigger logic is what causes the scope to start the sweep at the same point on the waveform every sweep. The trigger level is a binary number that equals the equivalent voltage that the sweep will start at. The slope determines whether a positive-going or a negative- going voltage will start the sweep when the trigger level is crossed. The program receives each sample during an interrupt and compares it to a previous sample saved from the last valid sample time. If, for example, the positive slope is set, then if the old sample were below the trigger level and the new sample is above the sample level, then the scope is triggered, and samples will be acquired. Autotrigger prevents the scope from waiting forever if no signal ever meets the trigger criteria. In this case, it keeps count of how many times a comparison is made against the trigger criteria and fails. After a large number of comparisons fail, it goes ahead and triggers the scope anyway. This is useful if you want to see what is on the scope input, but you are not sure where to set the trigger level. It may be useful to turn off auto-triggering if you want the scope to wait, possibly a long time, until just the right trigger condition is met. This can be handy for capturing seldom-occurring transient events when the scope is in the single-sweep mode. Once the scope is triggered, the program acquires 512 samples from the A/D converter, storing them in memory. Once all 512 have been stored, the program converts them to ASCII- hexadecimal, and sends them to the PC on the serial cable. After it completes the sending, it sends the letter 'Q' to signify end-of-block. During Beta-testing, some PCs would occasionally drop characters at 19.2 kilobaud, and the program would lock up waiting for all 512 samples to be received. Now, the PC checks for the 'Q' character, and assumes the sweep is complete even if less than 512 samples have been received. This problem is well-known for certain 80X86 processor / serial I/O chip combinations when running at 19.2k baud under Windows. The port selection and gain values select the programmable-gain multiplexer, and the input port selection multiplexer on the DSP-93. The DSP-93 can select one signal from up to eight inputs, and has 4 gain values usable by these applications. Function Generator The function generator program is downloaded from the PC to the DSP-93 and then started. It is based on a numerically controlled oscillator, or NCO. Basically, the D93WE program sends the DSP-93 some parameters (like in the scope program), one controls how fast the NCO accumulates, one determines the amplitude, and one determines the type of waveform. The NCO works by accumulating phase. The D/A converter is set to interrupt the TMS320C25 processor at a 62.5 kilosamples / second rate. During each interrupt, the software adds a phase- increment value to the current phase value of the NCO, the NCO rolls-over upon reaching 65536 (a 16-bit accumulator). So, the larger the increment value, the faster the NCO accumulates phase, and the faster it rolls over thus producing a higher frequency. The value of the NCO register at any time is proportional to the phase of a signal, with 0000h representing 0 radians, and 10000h representing 2-PI radians. Thus the NCO continually increments from 0 to 2-PI, rolls over to a small number (the remainder), and keeps increasing. A large part of this DSP-93 program consists of 4 tables in memory, that are downloaded along with the actual program software. One table converts phase to sinewave-amplitude, one converts phase to trianglewave-amplitude, one converts phase to squarewave-amplitude, and one converts phase to sawtoothwave-amplitude. Each table contains 256 entries, corresponding to a few degrees resolution of a complete cycle. The program in the DSP-93 looks-up the amplitude corresponding to the current phase in the NCO, and then multiplies that amplitude number by the output amplitude level setting. The product of these two generates an amplitude with a great deal of resolution and adjustability. Unfortunately, the 256-word tables provide a fair amount of aliasing, and the resulting waveforms have some severe beat-notes associated with them. Higher resolution tables would improve this, but the download time would be very long. So 8-bit (256- entry) tables are the compromise. The sinewave has fairly low distortion over much of the frequency range, but the triangle, square, and sawtooth waves are distorted at the higher frequencies, and when close to subharmonics of the sampling frequency. The TLC32044 CODEC chip filters, and the limited table resolution prevent the function generator from operating well above about 800 hertz, except for the sine wave which works well to much higher frequencies. The low-frequency usefulness is determined by the AC-coupling capacitors on the DSP-93. In fact, the low-frequency performance of the DSP-93 can be substantially improved if the AC coupling capacitors are replaced by small-value resistors. However, if you do this, be careful not to apply excessive DC voltage to the I/O pins, or you may damage the CODEC IC. Spectrum Analyzer The spectrum analyzer operates much like the oscilloscope, and in fact, uses much of the same logic as the scope. The D93WE program forces the trigger level to zero, and the slope to positive. After the program captures a complete buffer of 512 samples in memory, it performs a Discrete Fourier Transform (DFT) on the sample set. The DFT is much simpler (and slower) than the Fast Fourier Transform (FFT) but yields the same results. Normally, the FFT is used when speed of the transform is important. However, the limiting factor in speed is the 19.2 kilobaud serial interface to the PC, not the processor speed. The DFT calculations are overlapped with the sending of the serial characters to the PC, with the result that the computation time is mostly happening while the DSP-93 would be otherwise idle waiting for a character to be completely sent to the PC at 19.2kbaud. The DFT computes both a real and an imaginary value at each given frequency. Since the A/D converter on the DSP-93 captures only one sample per sample-time, the input is real-valued. This means that the Fourier-transform contains a mirror-image of the DC-to-one-half sampling frequency values in the range of one-half-sample-rate to f-sample. So, we can throw away the upper half of the spectrum, since it's merely an alias of the DC to 1/2 f sample spectrum. This results in the DSP-93 program sending each frequency sample pair (real, imaginary) to the PC, for a total of 256 pairs, or 512 samples. This is the same total number of characters as the scope program sends, so the spectrum analyzer runs at about the same speed as the scope. Some care has to be taken to properly scale the A/D samples, and the range of the sine and cosine tables to prevent numeric overflow in the DSP-93 during the computation. The PC program has to receive the sample pairs, and generate the magnitude of the signal (see below). Memory Test A useful program tests the RAM memory of the DSP-93 unit. This proved to be invaluable late in the beta-test program. The program runs seven tests: All-zeros to DATA RAM All-ones to DATA RAM Unique pattern to DATA RAM high-to-low Unique pattern to DATA RAM low-to-high All-zeros to PROGRAM RAM All-ones to PROGRAM RAM Unique pattern to PROGRAM RAM high-to-low The all-zeros and all-ones programs usually detect a stuck bit in a RAM chip. A stuck data line or two shorted data lines would prevent the DSP-93 from operating at all. The unique pattern, however, is very powerful at finding a number of different faults, and is highly recommended. Since the 320C25 is a 16-bit processor with 64k address spaces (DATA and PROGRAM), the unique pattern is nothing more than the value of an address written as data at that address. All addresses are written, then all read back and tested. If address lines are stuck or open, this test will usually find it. In the final testing of the beta-units, a subtle hardware timing problem was discovered by this test, with the result of the bug being that writing certain addresses changed the data values in unrelated other addresses! One of the GALs (Generic Array Logic, 22V10) on the DSP-93 was reprogrammed before the production units were shipped, and it solved the problem. Windows Display Software The windows program coordinates the DSP-93 instruments by sending parameter blocks to the instruments each sweep period, or updating the parameter values for the function generator if the user changes the sliders associated with frequency, amplitude, or changes the wavetype selection. Oscilloscope This program, when started, sends a parameter block to the DSP-93 to start a sweep, along with the sweep rate, trigger, level, slope, gain, port number, and autotrigger flag. If the PC is in the recurrent sweep mode, then each time after the DSP-93 triggers and sends the acquired values back to the PC, the PC will send a new parameter block back to the DSP-93, starting a new sweep. If the PC is in the single-sweep mode, then the PC will not send a new block. The user will have to click START to get going again. The display contains some grid lines (in blue) that set the horizontal and vertical divisions on the scope face, and a red horizontal line, that can be moved up and down with the trigger-level selection. This way, the trigger level can be visually adjusted just by looking at the receive signal. In the single sweep-mode the screen is erased when the parameter block is sent to the DSP-93, so you will have some visual feed back if the DSP-93 did or did not trigger. This is very useful when autotrigger is turned off since you may want to setup to trigger on a rare event, and if you see a sweep, you know that it triggered. Another very useful feature of a digital scope, is that the previously displayed samples do not always have to be erased between sweeps. If the INFINITE PERSISTENCE button is checked, then the samples are not erased between sweeps. This is most useful if the scope is reliably triggering. It can identify jitter, and other problems with received waveforms. It also allows an extremely simple eye-pattern monitor. If you capture some positive going and some negative going sweeps in the infinite persistence mode, you will effectively have an eye-pattern. This may be more useful, however if triggered off a signal without any jitter, which seems like a future instrument possibility (one to phase-lock a DSP-93 clock to the received signal with a low-bandwidth PLL, trigger off of the PLL, and then display the received signal). Figure 1 shows the Oscilloscope display. $&fig1 Function Generator The windows program to display the control panel for the function generator is not very sophisticated, and just allows modification of the parameters, which are sent to the DSP-93 any time the controls on the pop-up panel are adjusted. Spectrum Analyzer The spectrum analyzer program is very similar to the oscilloscope program, except that it has to do some processing with the received signal pairs. Recall, the DSP-93 sends (real, imaginary) pairs to the PC. The spectrum analyzer computes the magnitude (square-root of real-squared plus imaginary-squared) and displays that value. There is a linear and a log mode for display. The PC displays a scaled value directly to the screen in the LINEAR mode, while in the LOG mode it computes the LOG of the value, and then scales that value before displaying it on the screen. The persistence modes are different for the spectrum analyzer than for the oscilloscope. The display is always erased between sweeps, regardless of the persistence mode. However, in the MAX-HOLD mode, the PC keeps a running maximum of the magnitude of each frequency bin, and selects either the maximum of some previous sample or the current sample (whichever is greater). When the MAX-HOLD button is initially clicked, the register is zeroed out for all 256 frequency bins. This mode is useful for watching sporadic frequency components that pop up every once in awhile. The INTEGRATE mode instead integrates the new magnitude for each frequency bin with the previous values for that same frequency bin. It does this by a process known as exponential integration, since it settles to a final value much like a single-pole integrator does. 1/16 of the new input magnitude is added to 15/16 of the current integrated value. This is useful for suppressing random noise in the LOG displays, since the noise averages out while the signal continues to accumulate. You can sometimes see signals 'grow' out of the noise in this mode. The integrator is not zeroed when this button is clicked, because it takes too long for the integrator to settle out. Instead, the current sweep value is loaded into the integrator, so it settles from the current value. This results in a much faster integration to the final value. The reason it was chosen to have the PC compute the magnitude of the frequency bins is that at some later time, the program could be easily modified to display the real and imaginary parts, or to display the magnitude and phase parts of the Fourier transform. The DSP-93 software would not have to change. Figure 2 shows the spectrum analyzer display. $&fig2 Other Windows Functions Since the windows program will be used by people with a wide variety of experience, it was decided to provide several different ways to download software. Extremely useful feedback from the beta testers provided the insight to this. Casual users just want to point and shoot at the program they want to download. So a menu with a drop-down file browser is provided. Some people like to configure their applications, so a user-configurable menu was provided. This allows you to specify up to ten program titles (more descriptive than the file name) along with ten associated files in the D93WE.INI (initial settings) file. Then you can have your menu say anything you like, and when you click it, some associated program will be downloaded to the DSP-93 and executed. This could be set up, for example, to display up to ten different modems for the DSP-93, and then you could select each modem with one mouse click. Finally, the third way to select the program is very useful to program developers. In this mode, you select the name of some DSP-93 assembly program you are working on in the SET-PROGRAM-NAME popup of the DEVELOPMENT window. Then, one mouse click invokes a user-specified editor with that file opened for edit. Another click causes that program to be assembled (with user-adjustable parameters set once in another window). A shareware assembler is available, the actual assembler launched is configurable within the D93WE.INI file. A single click to a third menu downloads the newly assembled program to the DSP-93 and executes it. This EDIT-ASSEMBLE-DOWNLOAD cycle is very fast, and removes much of the tedium from writing and testing the code. Another single mouse click will allow you to view the assembled listing file, which is sometimes useful. The notepad editor that comes with Windows is nice for this edit function, but I have found the PFE (programmers file editor) a freeware (not shareware) program available on Internet to be much nicer, and with many useful features. $&fig3 Terminal and Implementation Notes The D93WE program contains a built-in terminal for displaying the results of serial input and output with the DSP-93. In OWL/C++ , it is very simple to include the functionality of a full-screen editor in the program. When writing C++ code, you just 'inherit' your application object from a full-screen editor object, and then anything the editor can do, your new application can now also do! Unfortunately, the stock Borland OWL TEditWindow object lacks any serial I/O capability, so some slight trickery is needed to give it those functions - the TEdit object had to be replaced with a new object (derived from TEdit) that knows what to do with keystrokes. This turned out to be a significant amount of effort to get working properly on all the various different computers that our beta testers had, but the result was worth the trouble. The terminal window inherits the Cut/Copy/Paste capability of its base class, and so you can cut and paste the terminal window contents to/from the clipboard. It also inherits the Search/Replace capability of its base class so you can search the terminal window for a specific character sequence. This proved useful when looking through the monitor code one night for TMS320C25 RETURN instructions while debugging some assembly code. Another class (a C++ object definition) that proved to be useful was a TInstrument class. It was derived from a TDialog object (a Windows dialog-box), and then given a virtual function to handle received serial I/O from the DSP-93. The class was made pure-virtual (meaning you can't instantiate a TInstrument, you must use the TInstrument to derive yet another object, in C++ lingo, the TInstrument is a virtual base class). However, all the instruments (scope, function generator, and spectrum analyzer) are objects derived from the TInstrument object, and thus they all inherit knowledge of how to receive control from a timer, and they know how to handle serial reception. The main program just hands control over to the current instrument, whatever that may be, and everything sort of happens correctly by magic. A far cry from monstrous switch statements used when writing C-based Windows programs. On Line Help The D93WE program contains extensive on-line help, using the Windows standard help system. Additionally, the three instruments contain context-sensitive help directly from the control panel of the instrument. I have found that writing and debugging the HELP system while simultaneously developing the program resulted in comprehensive help text. Certainly, some important topics would have been forgotten if the help system had been put off until the end. The whole package was developed as a series of prototypes, with additional functionality in each test release. Constructive feedback from the beta-testers helped in establishing many of the features of the current version. Help matched each version, so the beta testers tested not only the program, but the usefulness of the help system at the same time. Unfortunately, not all of the beta-testers actually read the help before asking questions, but this probably is an accurate representation of how the final users will operate the program! The on-line help is extensive enough that a printed manual was deemed not necessary by some of the users (those that used the on-line help, I hope). Acknowledgements I would like to thank Bob Stricklin, N5BRG for his assistance, and to the DSP-93 beta testers who tried all sorts of PCs and combinations that I would not have thought of, and who provided many useful comments, suggestions, and ideas for improvements. Note: D93WE is copyright 1994 Tucson Amateur Packet Radio Corporation. *************************************************************************** DSP-93 Control: A Macintosh Development Environment for the TAPR/AMSAT DSP-93 Ron Parsons, W5RKN This article describes the DSP-93Control application, a Macintosh interface for the TAPR/AMSAT DSP-93 digital signal processing unit. The purpose of the interface is to provide the following features for Macintosh users: Download of already-assembled software to the DSP-93, either in Macintosh or DOS file formats Fast, efficient Edit/Assemble/Download cycle for development of TMS320C25 assembly programs Various utility programs, such as oscilloscope, function generator, and spectrum analyzer Integrated communications terminal that utilizes the Apple Communications Toolbox. The program runs on a Macintosh computer running MacOS 7.0 or later. It is written in MPW C++, and uses the MacApp object framework, version 3.0.1. The framework is an object-oriented interface to the MacOS, and provides a clean, robust implementation. This article should be read in conjunction with the previous article D93WE - a Windows Development Environment for the TAPR/AMSAT DSP-93 by T.C. McDermott, N5EG. Both that program, and the application described in this article were written to provide similar functionality to users of the DSP-93 in different computer environments. Thus I will describe only unique elements of this application or elements which were implemented differently. The Integrated Terminal Emulator When this application is launched for the first time, the user is asked to configure the serial port used by the terminal emulator. Because the Apple Communications Toolbox is utilized, any serial port on the Macintosh may be used, even additional serial ports provided by add-in serial interface cards. Baud rates up to 57.6 kbs may be specified although the default rate of 19.2 kbs will probably be used for the DSP-93. The baud rate may be changed on the fly by choosing DSP-93 Serial Configuration from the Settings menu. A maximum of about 32000 characters are retained in the scrollable terminal window. Text may be selected and copied to the clipboard, but the characters in the terminal window may not be altered. A menu item in the Settings menu is provided to let the user choose whether to echo characters typed into the terminal. This option should not be chosen for the DSP-93 as that unit echoes the characters. The Integrated Text Editor An existing text file may be opened by choosing Open from the File menu. New text files may be created by choosing New from the File menu. The editor is a full-featured text editor following the Macintosh user interface guidelines. Styles, copy, paste, undo, and search and replace are supported. A maximum of about 32000 characters is supported in each file. An arbitrary number of text editing windows may be opened simultaneously. Printing to the chosen output device is supported. Assembling Programs An integrated assembler for the TMS320C2x is provided by choosing the Assemble item in the Actions menu.. The assembler does not handle the #include macro (actually it does if you precede the # with a space - it works but gives an error message). The assembler does not handle all expression operators and other niceties that the DOS based TASM 3.0 does. It is sufficient to assemble many simple programs including all the test programs provided with the DSP-93. The output of the assembler is written to the same folder that contains the assembly source file. The object file name is the same as the assembly source file name with .OBJ appended. The listing file name is the same as the assembly source file name with .LST appended. Both files are Macintosh format files (the line end character is an ASCII 13 (CR)). The user is informed about any errors which may have occurred in the assembly. The listing file may be opened in the integrated text editor. Running Programs on the DSP-93 The application can download programs to the DSP-93 using object code in either DOS format files (the line end character is an ASCII 13 (CR) followed by an ASCII 10 (LF)) or Macintosh format files (the line end character is an ASCII 13 (CR)). Two menu items are provided for this in the Actions menu. The program downloaded to the DSP-93 is automatically executed on completion of the loading sequence. The DSP-93 Instruments The same three instruments, Sampling Oscilloscope, Spectrum Analyzer, and Function Generator, that are described in the D93WE article are supported by this application. The interface and window appearance are virtually identical. See the D93WE article for a full discussion of the instruments. The instruments are loaded and executed by choosing an instrument in the Instruments menu. This application assumes that the Macintosh version of the object files supplied with D93WE are to be loaded. If the appropriate object file is not found in the folder that contains the DSP-93Control application, the user is asked to locate the appropriate object file. Figure 4 shows the Macintosh Oscilloscope interface displaying a 1200 bps packet audio signal. Note the two different periods of the waveform corresponding to different binary digits. Figure 5 shows the Macintosh Spectrum Analyzer displaying a 1200 bps packet audio signal. Note how the two peaks corresponding to the low and high tones of the AFSK signal are displayed. $&fig4 $&fig5 The Future I would like to provide an assembler with more complete functionality. If you know of C source code for such a beast, please let me know. Acknowledgements I would like to thank Tom McDermott, N5EG, for writing the DSP-93 instruments and documenting their interface so clearly. I would also like to thank Bob Stricklin, N5BRG, for his loader code for the DSP-93. Although this application and D93WE were developed independently, there is an amazing similarity in the source code of the two programs. This is most likely due to both of us using an object-oriented application framework. If anyone has the inclination to develop software for today's GUIs, I strongly urge you to learn and use an object framework. Although the learning curve may appear steep, the results, once you are able to see over the peak, are worth it. ************************************************************************ DRSI Ends Sales of Ham Products [Information from Andy Demartini, aed@drsi.com] Some time ago, DRSI notified all of its dealers that it has discontinued all Amateur radio products. DRSI will continue to provide repair service and telephone support for its Amateur products in the field, but we have retired the designs and no more will be built. DRSI is providing full telephone, fax, and e-mail support for its customers. We are also repairing broken products both in and out of warranty. We are open 9-5 EST, Monday to Friday, and have installed a voice mail system for after-hours support. For the last four years of DRSI's eight years in business, we have been developing industrial packet radio products and making a name for ourselves in those markets. For the last two years, we have steadily reduced our Amateur advertising and hamfest promotions. On October 1, 1994, dealers were notified that DRSI was ceasing further manufacture of Amateur products. From this point forward, DRSI will focus entirely on its industrial products for the "wireless revolution." The decision to cease Amateur production was made to allow DRSI as a company to focus all of its resources, both human and financial, on industrial products. The simple truth is that the industrial markets place a significantly higher value on our knowlege and expertise. This added value results in a markedly better return on investment. So, we have made a hard choice, but one which will result in better returns for the people who give us their 8-, 12- and 16-hour workdays. *************************************************************************** FCC Denies Reconsideration of Message Forwarding Rules [Release from the FCC] The Commission has denied the petition of Phil Karn asking for reconsideration of its decision concerning message forwarding systems in the Amateur Service. [Phil's petition was printed in PSR #55] Karn sought reconsideration of the Commission's decision that requires the licensee of the forwarding station to either authenticate the identity of the station from which it accepts communications on behalf of the system, or accept accountability for the content of the message. On March 30, 1994, the FCC adopted an Order which provided that in contemporary message forwarding systems, the control operators of intermediate forwarding stations, other than the first forwarding station, would not be held accountable when their stations retransmitted improper communications inadvertently. The purpose of the Order was to relax the Amateur service rules to enable these systems to operate at high speed while retaining the minimum safeguards necessary to prevent misuse. Denying reconsideration, the Commission said the Order did not address, nor was it intended to address, what accommodations should be made for message forwarding systems that may be developed in the future. This issue appeared to be the main concern of Karn's request for reconsideration. The Commission said that if the present accommodation becomes unworkable in a system using a different architecture, the managers of that system can request necessary rule changes at the appropriate time. ************************************************************************ Spread Spectrum STA Renewed Dewayne Hendricks, WA8DZP The STA that allows unrestricted use of spread spectrum emissions from 6 meters and up in the Amateur bands has just been renewed by the FCC. This STA was originally granted three years ago to Robert Buaas K6KGS, and has been renewed each year. Interested Amateurs may participate and operate under this STA by contacting Robert and getting his approval. This year's renewal is significant in that it has no expiration date. The text of the STA follows below: Dear Mr. Buaas: This is in response to your request date April 30, 1994, for extension of the special temporary authority (STA) and waiver of the Commission's Rules that you were granted on May 26, 1993. That STA and waiver permitted certain amateur stations to conduct experiments involving Code Division Multiple Access (CDMA) spread spectrum (SS) emissions. Your request was presented to the Interagency Radio Advisory Committee, which expressed no objection to an extension. Accordingly, the STA and waivers granted May 26, 1993, are extended until completion of your data communications experiments. All other conditions of the May 26, 1993, authorization will remain in effect. Sincerely, Robert H. McNamara Acting Chief, Private Radio Division Also be advised that the ARRL is very close to submitting a petition for rulemaking to the FCC regarding changes to Part 97 to allow less restrictive use of spread spectrum in the Amateur service. ************************************************************************* NPRM: Allocation of Spectrum Below 5 GHz Transferred from Federal Government Use [Edited from a release by the FCC] Introduction By this action, we propose allocations for 50 megahertz of spectrum that was identified by the Department of Commerce for transfer from Federal Government to private sector use. The spectrum we are considering is at the bands 2390-2400 MHz, 2402-2417 MHz, and 4660-4685 MHz. We believe that the allocations proposed herein will benefit the public by providing for the introduction of new services and the enhancement of existing services. These new and enhanced services will create new jobs, foster economic growth, and improve access to communications by industry and the American public. Background On August 10, 1993, the Omnibus Budget Reconciliation Act of 1993 (Reconciliation Act) was signed into law. The Reconciliation Act required that the Secretary of Commerce identify 200 megahertz of spectrum currently allocated for use by Federal Government agencies, for transfer to the FCC for use by the private sector. All of the 200 megahertz of spectrum recommended for reallocation must be located below 5 gigahertz, with at least 100 megahertz of this being below 3 gigahertz. The Reconciliation Act also required the Secretary of Commerce to issue within six months of its enactment a report making a preliminary identification of reallocatable bands of frequencies and to issue within 18 months a final report recommending the spectrum for reallocation. In its report making a preliminary identification of spectrum, the Department of Commerce was required to identify at least 50 megahertz of spectrum for immediate reallocation. The remaining spectrum is to be made available over a ten-year period. The frequency bands identified for reallocation in the Preliminary Report are listed in Appendix A. Three of these frequency bands, 2390-2400 MHz, 2402-2417 MHz, and 4660-4685 MHz, were identified for immediate reallocation. The Reconciliation Act also requires that the Commission allocate, and propose regulations to assign, the 50 megahertz of spectrum that is immediately available no later than 18 months after its enactment. Accordingly, on May 4, 1994, we released a Notice of Inquiry (NOI) in this proceeding seeking information on potential applications for the 50 megahertz of spectrum that is being transferred immediately from Federal Government to private sector use. We stated in the NOI that spectrum reallocated for private sector use has the potential to provide for the continued growth and development of advanced communications and technologies, thereby creating new high technology jobs and economic growth. Although the spectrum considered in this proceeding has some characteristics that will affect its future use by non-Government applications, we believe that all of the spectrum can be used to promote advanced technologies and provide economic growth. In response to our NOI, we received 77 comments and 17 reply comments. Internationally, 2390-2400 MHz is allocated in Region 210 on a primary basis to the fixed, mobile, and radiolocation services, and on a secondary basis to the Amateur service. Domestically, this band is currently allocated on a secondary basis to the Amateur service. The 2402-2417 MHz band is allocated internationally in Region 2 on a primary basis to the fixed, mobile, and radiolocation services, and on a secondary basis to the Amateur service. Domestically, the band is currently allocated on a secondary basis to the Amateur service. The 2402-2417 MHz band lies within the 2400-2500 MHz band that is available for use by industrial, scientific, and medical (ISM) applications. Radio services operating within this band must accept harmful interference that may be caused by ISM devices, which include a large number of microwave ovens commonly used in households. In addition, the 2400-2483.5 MHz band is available domestically for use by equipment authorized under Part 15 of the Rules. Internationally, 4660-4685 MHz is allocated in Region 2 on a primary basis for fixed, fixed-satellite, and mobile services. This band is allocated domestically on a primary basis for non-government fixed-satellite service space-to-Earth links, with use limited to international inter-continental systems. However, there is currently no non-Government use of this band. An agreement with Canada requires that certain United States Government terrestrial line of sight and troposcatter systems be coordinated with Canada. This agreement also permits use of this band by airborne or other mobile stations but requires that such stations protect Canadian systems. Discussion We are now considering allocating the spectrum at 2390-2400 MHz, 2402-2417 MHz and 4660-4685 MHz for new or developing services, or to provide spectrum to reaccommodate existing services. In response to our NOI initiating this proceeding we received a number of competing and generally mutually exclusive proposals and requests, many of which might benefit the public. Our principal objective in making this spectrum allocation decision is to ensure that the spectrum is put to its best and most valued use and that the greatest benefit to the public is attained. We believe that the way to achieve this goal is to adopt a broad and general allocation. Such an approach would allow for flexible use of these bands so that licensees would be able to offer a wide range of services employing varying technologies. This approach is similar to one taken in previously where we redesignated spectrum in the 2 GHz range for emerging technologies. In that proceeding, we allocated 220 megahertz of spectrum to Fixed and Mobile services and identified it for use by emerging technologies. Later, we provided for the personal communications services (PCS) to use 140 megahertz of this spectrum. The remainder is available for future use. We therefore request comment on an allocation approach that would designate the 2390-2400 MHz, 2402-2417 MHz and 4660-4685 MHz bands for general Fixed and Mobile services, rather than specify these frequency bands for particular uses. In this context, we believe such a flexible allocation that relies substantially on market forces may be appropriate. We also believe that under such an approach most of the services to be provided in this spectrum would likely meet the statutory criteria for auctions. Therefore, we are proposing to make licenses for this spectrum available though competitive bidding, to the extent possible and practicable. We also believe it is important to provide for a market structure that provides for competition in the provision of new services. A competitive market structure would promote economical prices for users and provide operators with incentives to develop and introduce innovative service features and technologies. One approach for developing a competitive market structure would be to divide the spectrum into channel blocks of one to two megahertz. Licensees would be given exclusive use of these channels within a specified geographic area. We request comment on this approach and the appropriate amount of spectrum to specify for a channel block and the extent of the geographic areas to which channel blocks would be licensed. While we believe that the above plan for allocation to Fixed and Mobile services would ensure that the spectrum is used for services that are most highly valued by the public, we also recognize that such an approach may be difficult to implement given certain factors that are unique to these bands. For example, there are incumbent Amateur users in the 2390-2400 MHz and 2402-2417 MHz bands and the 2402-2417 MHz band is affected by emissions from ISM devices, including millions of household microwave ovens. In addition, a growing number of unlicensed Part 15 devices are also operating in this band. Accordingly, we believe it is appropriate also to solicit comment on identifying specific communications services as an alternative to relying only upon the general allocation. A number of such proposals were presented in the comments to the NOI. In the 2390-2400 MHz band, In-Flight Phone Corporation (In-Flight) proposed an allocation for an aeronautical audio/visual service (AAVS). In-Flight's AAVS proposal has the potential to furnish commercial air travelers with real time video and audio information and entertainment services. According to In-Flight, the AAVS would be able to share spectrum with the Amateur and other services and, because it would be a ground-to-air service, would not present an interference problem for adjacent channel space research and radioastronomy operations. Another alternative for the 2390-2400 MHz band is a proposal from Southwestern Bell that this band be paired with the 2300-2310 MHz band and be used for wireless local loop service. As described by Southwestern Bell, a wireless local loop service would be enable a Local Exchange Carrier (LEC) to provide telephone service to the home via radio links rather than through a copper or fiber cable to each home. According to Southwestern Bell, the benefits of a wireless local loop service include reduced costs in providing telephone service to new customers, reduced telephone service maintenance costs, and rapid deployment of telephone service to new customers. Southwestern Bell further states that because of the high density of use in any particular area, a wireless local loop service would not be compatible with Amateur use of the spectrum. We observe that this spectrum also could be used to provide unlicensed PCS or Multipoint Distribution Service (MDS). One possibility would be to provide unlicensed PCS services in either or both of the 2300-2310 MHz and 2390-2400 MHz bands.26 Alternatively, the 2300-2310 MHz and 2390-2400 MHz bands could be used to accommodate the MDS currently operating at 2150-2160 MHz, freeing that spectrum for unlicensed PCS. There may also be benefit in using either the 2390-2400 MHz or the 2300-2310 MHz band for intelligent vehicle highway systems (IVHS). Motorola suggests that spectrum under consideration in this proceeding may be suitable for short range IVHS services. In response to the NOI, we received several other suggestions for use of the 2390-2400 MHz band. These uses include interactive video in rural areas, low power communications, mobile-satellite service (MSS), and advanced private communications. We believe, however, that most of these uses are already adequately accommodated in other bands, could be accommodated under our general allocation proposal for these bands, or may not be suitable for the 2390-2400 MHz band. We request comments on our conclusions regarding these other alternatives. We invite comments on any other services that might be provided in this spectrum. Parties supporting alternative proposals for this band should address the compatibility of the proposed service with the Amateur and other services. Commenting parties should also provide a cost/benefit analysis for the service, along with specific information regarding operating parameters and any other relevant information. We also note that, while we have not specifically identified spectrum for advanced private communications as requested by the Coalition of Private Users of Emerging Multimedia Technologies (COPE), private users can receive service from commercial service providers and can compete in obtaining spectrum on the same basis as commercial providers. Additionally, we will continue to consider COPE's request for spectrum as we determine uses for additional spectrum being reallocated from Federal Government use under the Reconciliation Act. In the 2402-2417 MHz band, the presence of ISM equipment, unlicensed devices (particularly spread spectrum devices) and other non-Government users present a particularly challenging environment in which to implement new radio services. Any equipment operating in this band must use transmission schemes that are extremely robust and versatile. Commenters to our NOI indicate that many of the companies currently manufacturing unlicensed Part 15 equipment for the 902-928 MHz band have begun to develop or modify this equipment for use at 2400-2483.5 MHz and several firms are selling devices for use in this band. We also note that Part 15 use is consistent with a number of suggestions for use of this spectrum, such as in-building voice and data systems, and small area communications. All of these uses can be accommodated under Part 15 of our rules. In light of this we request comment on retaining future use of this band by Part 15 equipment. Possibilities include eliminating this band from Part 15 use in order to avoid any potential conflicts with future licensed services, maintaining Part 15 use of this band and also implementing licensed services, or maintaining Part 15 use of this band while limiting licensed use of the band. We request further comment on other suggestions received for use of the 2402-2417 MHz band, including providing licensed services in this band that are subject to technical rules that are similar to the rules for unlicensed Part 15 devices, or use of the band for MSS. MSS providers appear pessimistic regarding the utility 2402-2417 MHz for MSS. However, Loral/Qualcomm states that it is continuing to evaluate the possibility of providing MSS in this band. Both the 2390-2400 MHz and 2402-2417 MHz bands are currently available for secondary use by the Amateur service. The Reconciliation Act directed the Department of Commerce to seek to avoid excessive disruption of the Amateur service and to determine the extent to which, in general, commercial users could share the frequency with Amateur radio licensees. The Department identified spectrum for transfer in light of this directive, and concluded that these two bands could be made available for commercial use without severely affecting the Amateur service. However, in their comments, the Amateur service community argues that the Department failed to meet the criteria of the Reconciliation Act. We recognize the importance of the Amateur service and, in making our allocation decisions, we will take into account existing use of the spectrum by the Amateur service. We therefore solicit information on several options. One approach for accommodating Amateur service use of these bands is to maintain a secondary allocation for the Amateur service in all or part of this spectrum. Another approach is to make the Amateur service the primary user in a portion of this spectrum while either maintaining a secondary allocation in the remaining portions of the bands or eliminating the other portions from the Amateur service. We also solicit information on the degree of disruption to the Amateur service that would result if all or part of this spectrum was removed from the Amateur service. We request comment on these options, including the ability of various radio services to share spectrum with the Amateur service. Appendix A NTIA Preliminary Spectrum Reallocation Plan Band Status Schedule 1390-1400 MHz Exclusive January 1999 1427-1432 MHz Exclusive January 1999* 1670-1675 MHz Mixed January 1999 1710-1755 MHz Mixed January 2004 2300-2310 MHz Exclusive January 1996 2390-2400 MHz Exclusive Immediate 2402-2417 MHz Exclusive Immediate 3650-3700 MHz Mixed January 1999 4635-4660 MHz Exclusive January 1997* 4660-4685 MHz Exclusive Immediate * Protection for a limited number of facilities would be required for an additional period of time.