---------------------------------------------------------------------------- Tucson Amateur Packet Radio Corp Packet Status Register -- Electronic Edition TAPR News Service PSR #53, Winter, 1994 ---------------------------------------------------------------------------- Packet Status Register Issue Number 53, Winter 1994 Published by Tucson Amateur Packet Radio Corporation Inside - President's Corner TAPR Office Changes Membership Demographics Annual Meeting Announcement Board of Director Elections Member Discount PCON - Packet Printer Controller DSP-93 Project Update PCON and TUC-52 Project Updates MetCon Project Ideas Dayton Convetion Preliminaries TrakBox Panel Layouts More on using the Alinco DR-1200T at 9600 baud. Teacher uses Packet Radio National Digital Communications Conference announcement AMSAT-UK E-Mail address. Review of Pico-J Portable Antenna GRAPES address correction. Error Correction Codes for Packet Radio HROUTE Forwarding - an alternate approach DOC Using the G3RUH modem at higher speeds. Packet software for the MAC: Savant. Interim Report of the ad hoc 219 MHz Committee. Secretary's Report -- A year in review. Getting out of KISS mode. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ TAPR gives premission 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 form this issue: Reprinted from: TAPR News Service, PSR #53, Winter, 1993 Please attach the following to the end of all articles and information used: TAPR membership costs only $15/year! 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: John Koster, W9DDD Director: Jack Davis, WA4EJR Director: Mel Whitten, K0PFX Director: Ron Bates, AG7H 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 Report Welcome 1994, goodbye 1993. I hope everyone had a pleasant holiday break. The outstanding news for 1993 is that TAPR showed a financial upturn. This was good news, since TAPR has been generally losing money for the last number of years. Several years ago, Andy Freeborn, N0CCZ, showed that TAPR would be in serious financial trouble if it continued to show losses each year. Andy was right and we must continue to have everyone concentrate on working to keep things turned around. This good news can be attributed to Jim Neely's hard work as treasurer and everyone's responsible fiscal control over operations this last year. We still need to continue to work towards several years of successful financial progress in order to get back to solid footing as an organization. The other positive news from last year is that the goals that were set for 1993 were all met: 1) TAPR showed a financial up-turn, 2) projects that were in limbo are now in a state so as to eventually recover money spent on research, 3) the flow of information dissemination was increased, 4) board communications were moved from CompuServe to Internet, 5) the TAPR information server was brought on-line, 6) membership decline was stabilized, and 7) overall membership activity was increased. A pretty full plate, which I believe the Board did a great job accomplishing. This past year required a lot of work from everyone and I believe that 1994 will see a continued increase in TAPR activity and will cause an increase in membership participation. As TAPR continues to grow and become active, it is necessary for tasks to be moved outside the board of directors. One past TAPR trend was the feeling that individuals had to be on the Board in order to do anything within TAPR. I want to avoid this at all costs. There are plenty of things for folks to be doing that do not require direct interaction with TAPR's financial resources. The purpose of the Board of Directors is to set direction, set policy, and most importantly to control and take responsibility for TAPR's financial resources. It is my hope that TAPR will become successful in areas other than the traditional one of designing and developing new pieces of hardware, which takes considerable financial resources for each new project. Concerning membership, the numbers for 1993 were down again, but the last three months of the year saw over 100 new members, which helped a lot to offset recent membership decline. Long-time member renewals have been on the decrease for several years now, so it is very important to bring new members into the organization. I believe that preliminary efforts in getting TAPR's name out once again to the Amateur community has begun to show positive results. Just the first part of January has seen over 50 new members! We will continue the ads for this coming year and we have a convention/hamvention package available for those that would like to distribute TAPR information at those affairs. Just contact the office. In order to broaden membership impact and participation, we are instigating Special Interest Groups (see SIG write-up for more information). The intention is to provide groups for discussion in areas of national interest. Different areas of the U.S. have different needs and concerns and there seems to be a lack of national discussion that is widely disseminated. These groups will be formed as needed and anyone, TAPR member or non-member, can participate. We plan on trying to host SIG meetings three times a year: TAPR Annual Meeting, Dayton HamVention, and at the ARRL National Digital Communications Conference. With these face-to-face meetings and dialog via digital means, there should be some positive results. The first ones that will be getting underway for 1994 are the BBS SIG and Regional Networkers SIG. Both of these we feel are needed in order to bring focus on national issues in both areas. A TCP/IP SIG has been talked about, but we are still looking for someone to chair the group. The first meetings of the SIGs will be held at the TAPR Annual Meeting. The SIGs will be responsible for setting their own agendas and activities within their groups. Methods will need to be developed on how actual "TAPR Recommendations" are adopted from the SIGs. I have high hopes for this year to continue to build on what we accomplished in 1993. I will be recommending the following goals for 1994 to the Board at the annual meeting: 1) continue to watch spending very 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. All of these goals fit into TAPR's vision plan which was started in 1993. That vision sees TAPR moving back into a national perspective and moving towards covering a larger segment of the Amateur digital community. In the mid-80s when TAPR got rolling, TAPR grew with its members from those early days, beginning at a lower understanding of this aspect of the hobby to more advanced stages of design and understanding. In the last few years, these original members of TAPR have been decreasing, while TAPR's activities have remained at a rather high state of development and technology understanding. This has not reflected the change in the Amateur community -- that of an increasing beginning and intermediate user base. TAPR needs to shift some of it emphasis from high-end development down to more intermediate level projects and publications. The purpose is two-fold: 1) to bring in new members and begin to move them into the high levels of understanding and usage and 2) to be able to have a large group of Amateurs who will be able to participate in the future of TAPR. The Board gave a lot of thought to how much the organization should shift -- possibly even trying to cover very novice packet users, but in the end the Board felt that by shifting too much to the lower levels might possibly dilute what TAPR is about and does -- that the regional groups throughout the U.S. are doing a good job currently in getting these very beginning digital operators active and on the air. The Board has decided that TAPR will expand its focus to incorporate more intermediate users. That does not mean that we will not produce any beginning materials; this means that we will focus on devoting financial resources on this new range. I want to finish this president's report by discussing the annual meeting, the Board of Directors meeting, and Board elections. As you will read and hear several times in the next few months, the annual meeting is March 4th, 5th, and 6th, 1994 in Tucson, Az. (Take a read on the blurb later on for all the important information) We hope to see you at the meeting this year, but if you don't make it, TAPR will be at Dayton as usual and we will be present at the ARRL National Digital Communications Conference. One of the things I hope the Board will discuss this year is the possibility of having the annual meeting away from Tucson every other year, thus allowing more participation from folks not able to attend Tucson while still allowing TAPR to return to its roots on a regular basis. On the second point, the Board of Directors meet Friday of the annual meeting and if you need to meet and discuss something with the Board, please drop a note to the office before the actual Board meeting in order for your item to be added to the agenda. It is important to have the agenda organized in order to cover things in a logical manner and cover everything needed in one short day. On the last point, I was very pleased to have such a good turnout for this year's Board elections. TAPR has had years in the past when there was not enough interest to fill the slots up for election. That was one reason we changed from fifteen to nine directors. The entire slate of board nominees consists of outstanding individuals. I believe that this one item alone shows a lot of change in the direction and interest within the organization. When you receive your ballot in the mail, please take a moment to read the biographies of each candidate. Each person holds special talents and gifts which they can bring to the TAPR Board and the future direction of the organization. Your vote is important, so take the time, select five candidates for the Board, and then mail back your ballot to the office. Cheers - Greg P.S. TAPR is doing another 120 TrakBox units for shipment in February. ***************************************************************************** Office Changes The TAPR troops descended on Tucson during the week of December 13th, 1993, in order to close and pack the TAPR office at the Johnson's. This brought to an end many years of dedicated service by Heather Johnson. After packing the office and cleaning the storage shed, we had 36 boxes of an average of 40+ pounds each being shipped. A lot of stuff! It was a lot of work by all. The office opened again January 11th, with a record number of calls. The office received 80+ calls the first day. Dorothy, our new office manager, had her trial by fire that first day. Several things have changed, primarily our phone numbers and address. The old address will be good for several more months, so we should not miss anyone's mail. New Office Manager Dorothy Jones, KA5DWR New Office Hours: Tuesday - Friday 9am - 12noon & 3pm - 5pm Central Time TAPR's new address is: Tucson Amateur Packet Radio 8987-309 E. Tanque Verde Rd #337 Tucson, Az 85749-9399 New Office Number is: (817) 383-0000 New FAX Number is: (817) 566-2544 Our Internet address will remain: TAPR@TAPR.ORG The next time you call, you will discover another major change. First of all you will be welcomed by the TAPR voice system. This replaced the previous single line with answering machine. The system supports, voice mail, bulletin messages, and FAX-back ability (when calling from a FAX). We are also adding an additional phone line in order to eliminate those times when calls get that busy signal. The goal is to provide more service to members when the office is closed, which is a lot, considering we only have 20 office hours a week. During office hours the system will allow transfer to Dorothy, the new office manager. Otherwise the system will try to provide information and services needed by most phone callers. With the FAX option, the system will be able to FAX information back to those calling from a FAX machine. We hope to have FAQ (Frequently Asked Question) sheets and product information available via the FAX option. If you have input after you make a call, please leave that on the system so that we can improve the setup. The system also supports a questionnaire, so after you leave that message, hold for the next voice prompt and then take the TAPR questionnaire. One final note, please have a little patience with Dorothy; it will take a little time to approach Heather's expertise on TAPR's product line and support. ***************************************************************************** Membership Demographics Greg Jones, WD5IVD While converting the TAPR database into the new format, I got a little restless and ran a few numbers on the database of all current members as of December 31st 1993. Here is what the numbers showed. TAPR has members in all 50 states, plus Washington DC Membership as of January 1st, 1994 is 952 members 85% are U.S. residents and 15% reside outside of the U.S. (international) We have members in 26 countries. Membership expirations were as shown in the chart. Total U.S. Membership is 807. Non-U.S. membership is 145. Since TAPR did not keep 'member since' dates, it was not possible to determine the length of membership before expiration or how many new members we had each year. The new database tracks these now. We hope to be sending out a survey to all members sometime this year in order to get a better snap-shot of what these numbers might mean. Detailed Non-U.S. Statistics Distribution by country, ranked by % of Non-U.S. Membership. Canada 63 43.45% Japan 14 9.66% Spain 11 7.59% Italy 11 7.59% England 8 5.52% New Zealand 5 3.45% France 4 2.76% Israel 4 2.76% Australia 3 2.07% Germany 3 2.07% New Caledonia 2 1.38% Switzerland 2 1.38% American Embassy 2 1.38% Netherlands 2 1.38% Sweden 1 0.69% Oman 1 0.69% Slovakia 1 0.69% Chile 1 0.69% Norway 1 0.69% S Africa 1 0.69% Philippines 1 0.69% Argentina 1 0.69% Bolivia 1 0.69% Greece 1 0.69% Venezuela 1 0.69% Summary Statistics -- U.S. Membership Density by % 24 states 12 states 1 - 2 % 4 states 2 - 3 % 6 states 3 - 4 % 5 states >>4 % Membership Distribution 29 states 14 states 11 - 30 members 8 states >>30 members Detailed Statistics -- U.S. Distribution by state, ranked by % of U.S. Membership CA 135 16.73% AZ 63 7.81% NY 48 5.95% TX 39 4.83% PA 34 4.21% WA 32 3.97% OH 31 3.84% NJ 31 3.84% IL 29 3.59% CO 29 3.59% MI 27 3.35% MA 23 2.85% FL 21 2.60% CT 18 2.23% VA 17 2.11% OR 16 1.98% MN 14 1.73% IN 14 1.73% GA 14 1.73% TN 13 1.61% NM 13 1.61% MO 11 1.36% NC 10 1.24% MD 10 1.24% OK 9 1.12% LA 9 1.12% IA 9 1.12% WV 8 0.99% WI 7 0.87% KY 7 0.87% UT 6 0.74% NE 6 0.74% AK 6 0.74% SC 5 0.62% KS 5 0.62% AL 5 0.62% HI 4 0.50% NV 3 0.37% NH 3 0.37% MT 3 0.37% MS 3 0.37% ME 3 0.37% AR 3 0.37% WY 2 0.25% RI 2 0.25% ND 2 0.25% VT 1 0.12% SD 1 0.12% ID 1 0.12% DE 1 0.12% DC 1 0.12% ***************************************************************************** TAPR 1994 Annual Meeting Join some of the brightest and most enthusiastic of today's packet pioneers at TAPR's annual meeting on March 4th, 5th, and 6th, 1994, in Tucson, Arizona. The meeting informally begins Friday afternoon with the opening of the hospitality suite and continues later that evening with dinner. Dinner is always low-key and provides a great opportunity for those who arrive Friday to discuss and chat about projects before the rest of the weekend begins. Friday evening, after dinner, the first meeting of the Regional Networkers Special Interest Group will be held. The annual meeting formally begins Saturday with presentations and papers on several exciting new hardware and software projects as well as discussion on other projects of interest throughout the day. A mini-symposium concerning future directions in Amateur packet radio will be held during the afternoon session. Issues concerning packet networking and BBS operation are also anticipated. Saturday evening, after the TAPR dinner, will feature an open forum during which attendees will be given an opportunity to influence the future direction and research with which TAPR is involved. After the TAPR forum, the first meeting of the TAPR BBS Special Interest Group will be held. On Sunday, a special NOS TCP/IP workshop will be led by Johan Reinalda, WG7J/PA3DIS, principal author and developer of JNOS. Johan will also be available for more advanced discussions about JNOS and related activities. These are exciting times for packet and TAPR. This year's meeting should be a super-charging event for everyone who can attend! Call for Papers Papers are welcome from everyone. Since there is limited time during the weekend, all attempts will be made to allow those present to talk. Deadline for submission of papers is Monday, February 10th, 1994. Contact the TAPR office to request an author's information package. Contact Keith Justice, Program Chairman, (Internet: kf7tp@kf7tp.stat.com) for additional information. Meeting Place and Accommodations The TAPR Annual Meeting and all presentations and meetings, will be held at the Best Western Inn at the Airport, 7060 South Tucson Boulevard, Tucson, Arizona 85706. Phone (602) 746-0271. The room rate is $54 per night, which includes a complimentary full American breakfast buffet and daily complimentary cocktails with hors d'oeuvres between 5 and 6 PM. Make your reservations early. Schedule of Events Friday Afternoon, March 4th Registration Hospitality Suite Dinner Regional Networkers SIG Saturday, March 5th Registration Presentations Lunch Presentations / Symposium Dinner TAPR long-range plan session BBS SIG Sunday, March 6th Special TCP/IP Half-day Workshop conducted by Johan Reinalda, WG7J/PA3DIS Detailed conference information and schedule will be mailed to all pre-registered participants. Costs Annual Meeting Registration wo/Dinner w/ Dinner Saturday ** Pre-registration (before Feb 17th): $20.00 $34.00 Late Registration or at door: $25.00 $39.00 Annual Meeting registration includes a copy of the TAPR 1994 Proceedings, and a lunch ticket for Saturday afternoon (limited space). **TAPR Dinner Saturday evening (limited space) Sunday NOS TCP/IP Half-day Workshop Pre-registration (before Feb 17th): $10.00 Late Registration or at door: $15.00 Workshop attendees receive a set of disks and workshop materials. Contact the TAPR office by Phone, Fax, or e-mail (Internet: tapr@tapr.org) to pre-register or for additional meeting information. MasterCard and VISA accepted. ***************************************************************************** Board Nominations The following is the biographies submitted by each of the Board nominees. Ballots have been sent out separately to each current TAPR member as of January 16th. The deadline for ballot return is Feb 16th, 1994. When you receive your ballot, read it over, select five candidates and return your ballot to the office. Your vote as a member is important to the organization. Two of the three positions will be for one year in order to have three Board members up for election each year. The Board is made up of nine members. These members are responsible for setting organization goals and directions, and taking responsibility of TAPR financial resources. An executive committee of President, Vice President, Treasurer, and Secretary are chosen during the yearly Board meeting. The executive committee is responsible for the day-to-day running of the organization. Jack Taylor, N7OO RR-3 Box 1690 Sierra Vista, AZ 85635 Telephone: (602) 378-6178 Internet: n7oo@huachuca-emh8.army.mil A ham for 40+ years, the past few have been devoted nearly exclusively to packet radio. My interests are in casual keyboarding, TCP, BBS operation, RF link design and, in exploring the node network. Prior to retirement, I was a test director on both small and large-scale military communications systems, including HF, microwave, tropo-scatter and satellite technology. I feel TAPR is to packet radio as is apple pie to America. If elected to the Board, I would actively strive to see TAPR prosper. Ron Bates, AG7H 621 E. Windward Cr Tucson, Az 85704-7333 Telephone: (602) 297-7446 Internet: rbates@tucvax.tuc.nrao.edu I began my Amateur career in 1964 as an active CW novice operator. Years later upon completing a 4 year stint in the Air Force, I re-licensed and upgraded to the Advanced Class. In the late 70s I upgraded to Extra and began building home-built VHF-UHF solar powered repeaters. In November of 1981 I was installing an antenna atop a tall observatory shaft at Kitt Peak National Observatory outside Tucson. As I climbed down I was met by a group of excited and enthusiastic people. Of course most were hams and they invited me to share in this dream of theirs called packet radio. Having already experimented with straight ASCII over the air I knew these folks were up to something really great and perhaps would have a profound impact on Amateur Radio. I attended their 2nd meeting. Held deep in the chambers of the huge Kitt Peak 4-meter optical telescope. We would soon form a club known to the world as "Tucson Amateur Packet Radio." Ever since then I have worked with and learned much over the past decade being involved with TAPR. I participated in the Alpha and Beta TNC testing projects during the early 1980s. Over recent years I have been TAPR's TNC-2 technical representative assisting owners world-wide in technical advice. I currently work for the National Radio Astronomy Observatory, Kitt Peak VLBA Station. My technical background also stems from work at IBM for 8 years, television broadcasting, microwave test, and medical and chemistry electronics. If elected to the Board, I desire to see TAPR retain its founding philosophy of developing affordable leading-edge packet radio equipment to the Amateur community. Our continued success relies on this founding commitment which I hope to impart to fellow members in a productive and peaceful manner. Mel Whitten, K0PFX 3219 Haas Ave Bridgeton, MO 63044 Telephone: (314) 739-1108 My Amateur radio career began at age 12 with continued interest in all the digital modes from high speed CW and Teletype to Packet Radio. I have served as an officer in various radio clubs and I am currently vice-president of the Missouri Amateur Packet Society. Working with MoAmPS and other packet groups, I was instrumental in developing the high speed backbone of eastern Illinois and Missouri. As a sysop for the MSYS BBS in St. Louis and a node operator for a Gracilis switch and the MO-CALIF worm hole, I remain active in day-to-day packet activities. My interest in Packet Radio began when St Louis was chosen as one of the beta sites for TAPR's TNC. This was the beginning of a long time association with TAPR and engineering support in the development of the TNC-1 and TNC-2 and currently supporting user's questions on TAPR's 9600 baud modem. As a Board member, I would utilize my past experience and knowledge in making those decisions that will help TAPR meet its goals and vision for the coming years. Professionally, I have worked for a large telecommunications company for the past 26 years and I am currently a senior development engineer. It is because of these qualifications that I ask for your support toward my nomination on TAPR's Board of Directors. Jack Davis, WA4EJR (Board Member) 25341 Orellano Way Laguna Hills, CA 92653 Internet: 72356.441@compuserve.com I was first licensed in 1961 and currently hold a General Class license. I have been an active member of TAPR for ten years and currently hold a Board of Directors position. I participated in the development of a cooperative effort by Sueo Asato, JA6FTL, and Bruce Lockhart, SM0TER, called TrakBox. The TrakBox is a stand-alone controller used by satellite enthusiasts to automatically control steerable antenna systems. I wrote the proposal for TAPR to distribute the TrakBox and am currently the TrakBox Project Manager. In this capacity I act as liaison between TAPR and the developers. I am also responsible for components, documentation, and support of this project. It is estimated there are 650 TrakBox controllers in use around the world. Many of them from the kits offered by TAPR. I would like to run for another term in order to continue my work on this project and to help manage the other activities of TAPR. John Koster, W9DDD 1821 Blake Drive Richardson, TX 75081 Telephone: (214) 644-1748 Internet: jkoster@tenet.edu A ham since 1959, I've always been interested in digital forms of communications starting with RTTY in 1960. The past 8 years I have been very active in packet, and since 1987 have been deeply involved with the TexNet Support Group (a service of the Texas Packet Radio Society). I was the head of the Software Group and supported the TexNet code from 1989 till just this last year. I am interested in radios and modems for high speed network backbones. I would like to see the country linked with a highly reliable VHF/UHF network. If elected to the Board of Directors, I would be committed to TAPR becoming an even stronger and better organization. Greg Jones, WD5IVD (Board Member, President) 7201 Wood Hollow #458 Austin, TX 78731 Telephone: (512) 794-0578 Internet: gjones@tenet.edu A ham since 1977, I originally got involved in packet radio due to TAPR's efforts during the great TAPR TNC-2 development in 1985 and have been active ever since. My primary interest in Amateur Radio is digital communications. I have served as an officer or a Board member of TAPR since 1989. This last year has seen a lot of personal time put into TAPR in order to start in motion the necessary changes to lead TAPR into another 10 years of successful Amateur involvement and service. I hope to get re-elected in order to continue the changes that were started this previous year. If you have any questions, my phone is always answered by me or my machine, but since I am a PhD student at the University of Texas, Austin, my answering machine gets most of the calls (I know the librarians by their first names). I check my Internet mail daily, so that is the best way to contact me. Call me or write me if you have any input. We are always looking for folks to get involved or help out with problems. My two primary Amateur goals are to see TAPR improve and grow as an organization and see more educational items disseminated to both hams and schools. William A. Beech, NJ7P PO Box 38 Sierra Vista, AZ 85636-0038 Internet: bbeech@huachuca-emh8.army.mil I have been active in Amateur radio since 1965 and on packet since 1985. I have developed several versions of the TheNet code (version 2.00 through 2.12) over the past 4 years. This code is in use at thousands of sites worldwide. In the past month I have begun a collaborative effort with Dave Roberts, the author of TheNet X1J. In the last year I have rewritten the AX.25 standard, updating and aligning it with the current International Standards. We have added the functionality suggested by Eric Scace (K3NA) and others over the past 9 years. Last year at the Annual TAPR meeting, Doug Neilsen, (N7LEM) and I demonstrated a second generation TNC running code we developed from the new standard. This standard is currently in review by a committee of TAPR members. I am currently active on several of the OSCAR satellites including FO-20, UO-22, KO-23 and 25. I am currently working as a Computer Engineer (GS-0854) with the US Army. I previously worked in the US GOSIP program as the Protocol Engineer for X.25 and ISDN. ***************************************************************************** Member Discount The Board has decided that being a member of TAPR should be more than just another person who gets a PSR quarterly and helps to support TAPR. What does this all mean to you? Paid up TAPR members will now receive 10% off all kits and publications purchased. This is TAPR's way of saying thanks for being a TAPR member. ***************************************************************************** PCON (Packet Printer Controller) Paul Newland, AD7I PCON, in its most basic form, is a printer controller that serves to convert serial asynchronous ASCII data to a format suitable for driving a common personal computer parallel printer (or a low-speed ASCII/Baudot serial asynchronous teleprinter). PCON's basic features include: flow control (via XON, XOFF), printer motor control, answerback generation, and power-on and power-off page control. PCON's operation is very similar to a classic unattended TELEX terminal. The only significant difference is that a personal computer parallel printer is used as the hard copy device instead of the more typical mechanical teleprinter. A typical use for PCON is to interface a parallel printer to a packet radio TNC. Such a system provides the functionality of a "rip-and-read" message printing system where the person receiving the message doesn't need to know anything about radio or computers. The person simply tears off a page of paper that contain messages from the printer and do with it as he or she pleases (i.e., read them, file them, distribute them, etc.) There are a number of emergency services applications for such functionality. The PCON system is based on an 8752 microcomputer (see TUC-52 in this issue). The microcomputer takes data it receives on its internal serial port and sends it in parallel format to a parallel printer. When enabled via configuration commands for public service applications, PCON can also provide a means for remote packet stations to read status switches and write to status lamps connected to PCON. Thus a message can be sent to an unattended remote site (hospital, fire house, EOC, NWS, etc.) where the message is printed. When read, the reader can then change the status of a switch, based on a light set by the sending station. Later the sending station can poll the unit and see what status switches have changed (remote telemetry). Depending on how individuals coordinated how these switches are changed on the unit, different things could be remotely determined (such as acknowledgement of the message). This would be similar to MetCon telling you that someone had opened the door of the repeater or that the wind was blowing at such and such a speed. Operational Scenarios There are three basic operational scenarios for PCON for packet radio applications. Scenario 1 doesn't require any changes to TNCs. Scenario 2 assumes that the TNC includes some sort of personal mailbox with forwarding capabilities. Scenario 3 assumes that the TNC can get messages from a BBS system. Each of these scenarios is described below. Scenario 1 - PCON TELEX Functionality This scenario provides only a direct-connect message printing system. The message sending station (MSS) must establish a direct connection (perhaps via a network) to the TNC that's attached to a PCON system (also called a PTNC). When the MSS (message sending station) connects to the PTNC (TNC equipped with PCON), the connect message will cause the printer to be powered up and the "*** CONNECTED..." message will be printed on the printer. The MSS operator would then send "WRU > ." The WRU is the ENQUIRY (^E) character while the >(which is just a ^M) is needed to cause the MSS in conversational mode to packetize the WRU and send it to the PTNC. When the PTNC's PCON receives the WRU it will respond with it's Answerback, a free text string of less than 24 characters that is chosen by the PTNC station's licensee. Typically, the Answerback will look something like "DE W1AW." PCON Answerbacks always end with > to ensure that TNCs in conversational mode correctly packetize the Answerback. Since the Answerback is generated only if the printer is operational and on-line, the operator at the MSS can assume that all is well if the Answerback is received at the MSS. If the MSS operator does not receive an Answerback in response to the WRU then the PTNC system is assumed to have malfunctioned and the MSS operator drops the connection without sending the message. If the MSS operator does receive an Answerback, he or she then sends the message and ends with another WRU in order to get a final Answerback. If the final Answerback is received the MSS operator then assumes that the message was correctly printed, since an Answerback was received at the start as well as the end of the message printing operation. If the final Answerback is not received, then it's highly probable that the printer ran out of paper during the message printing process or it jammed or otherwise suffered some malfunction. The MSS operator should think of the Answerback at the start of a message as meaning that the PTNC station is ready to copy a message and the Answerback at the end of the message means QSL -- the PTNC station has received and printed the message. Scenario 2 - PCON Mailbox Functionality Consider a TNC that includes a personal mailbox system that includes the ability to forward to/from a cooperative community full-feature BBS. Consider also that the TNC firmware has been modified to include a new system configuration variable called PCON that is defaulted to OFF. The TNC personal mailbox operates in normal fashion when PCON is set to off. Now consider that the system configuration variable PCON is set to ON and that a PCON system is connected to the TNC's serial port (thus becoming a PTNC). Whenever a message has been entered into the PTNC's personal mailbox (by either direct entry from another packet operator or from forwarding by the community full-feature BBS) the PTNC sends the message to its serial port to be printed by PCON. At the end of each message, the TNC would send a WRU to PCON and then check to see that PCON responds with an Answerback. If the Answerback is detected, the message can be killed from the personal mailbox system and a form-feed character can be sent to the printer to cause it to move to a new top of form. The goal of this process, to get all packet mail messages for the user onto a hardcopy printer without any operator intervention, is achieved. Note: This is all dependent on TNC firmware being enhanced. Scenario 3 - PCON Mail Grab Functionality Mail Grab is like a personal mailbox but with a twist. The mailbox system (Scenario 2) assumes that there is a cooperative community BBS that is willing to forward mail to personal mailbox systems. Unfortunately, that isn't always the case. That's the reason for the Mail Grab system. Mail Grab is just like a personal mailbox. However, the TNC is also capable of being programmed with a "CONNECT-STRING" and an "INTERVAL." The PTNC uses this information as follows. Every INTERVAL minutes (60 is a good minimum number) the TNC will use the data in the CONNECT-STRING to connect to another station (a BBS). The TNC then sends a RM (read mine) command to the community BBS and captures all BBS transmitted message data, perhaps determining the message boundaries if possible. If message data was not detected, the TNC disconnects from the BBS and the process ends here. If message data was detected, the TNC will send those messages to the PCON system connected via the TNC's serial port (without disconnecting from the BBS). After all messages have been sent to PCON, the TNC seeks an Answerback from PCON to determine if all messages were printed successfully. If an Answerback was received, the TNC can send a KM (kill mine) command to the BBS and then log off from the BBS. Again, the goal of this process, to get all packet mail messages for the user onto a hardcopy printer without any operator intervention, is achieved. The additional twist with the Mail Grab system is that the PTNC licensee doesn't need the cooperation of a community BBS for forwarding. Conclusion Other functionalities are certainly possible and we encourage their development. However, we feel that the three functionalities above will meet most users' needs. Enhancements to PCON should be very possible with the additional code space available (see TUC-52). I would be happy to discuss the operation of PCON with any TNC designer or manufacturer. I would also be glad to help test systems and software that might make use of PCON. Unfortunately, PCON hardware availability is limited at this time (wire wrap prototypes) so loan of PCON systems are not yet possible. Beta-test is planned for later this year. TAPR will be announcing later this year a beta-test schedule. In the meantime, I would be happy to test your hardware/firmware with a PCON prototype. ***************************************************************************** DSP-93 Project Update Bob Stricklin, N5BRG The alpha testing is going well and the project is on schedule. The group is still working out a few minor bugs before producing the beta-version of the DSP-93. We currently have seven of the original ten boards functional. Some of the code is also in place which will be needed to move on with beta testing. Frank, WB5IPM, has successfully used the DSP-93 with a modem routine he wrote to communicate with one of the Amateur satellites at 9600 baud. Lots of enthusiasm is present from the current participants. The challenge is to keep the ideas for additions and changes limited to those which are real improvements or requirements for the future generations of the DSP-93. Changes take time and add risk. After some documentation and logistics on parts are worked out, we will lunge forward with the beta-test. The project currently has 12 beta-tester requests pending. A letter of participation is currently being drawn up for mailing to those individuals. If you submitted a beta-test form and do not hear from the DSP-93 project by the end of February, contact the TAPR office. ***************************************************************************** PCON and TUC-52 Project Updates Paul Newland, AD7I During the initial stages of the PCON (Packet Printer Controller) project, the project group decided to develop the processor board as a separate board from the interface board. This would allow the processor board to be used in other TAPR projects in the future. We have informally dubbed this system the "TAPR Universal Controller 52" or TUC-52. The TUC-52 is a microcomputer system that's based on the 80c32 processor. This is an 8-bit single-chip processor developed by Intel and cloned by many other manufacturers that provides some basic microcomputer functions. One feature of the 8051-family is that it can be run in an external bus mode so that standard EPROMs and RAMs can be used for additional memory needs. TUC-52 makes use of this external bus feature. The TUC-52 has all the features of the 80c32 processor except that P0 and P2 are lost to bus expansion. What remains on the 80c32 are an 8-bit full duplex UART, three timer counters, two external interrupt inputs (all with bit I/O) and an additional 8-bit I/O port (the P1 port). We've added the capability to address up to 64K of EPROM, and up to 64K of battery-backed RAM (BBRAM). In order to recover the 80c32 I/O lost to the bus expansion function, we've included an 82c55 parallel I/O port. The 82c55 isn't quite as flexible as the P0 and P2 ports lost to bus expansion; however, the 82c55 does provide an 24 additional I/O lines to replace the 18 that were lost to bus expansion. TUC-52 also includes a bit-banged I2C (pronounced EYE SQUARED SEE) interface bus that can be used to communicate with any slave I2C parts. TUC52 includes socket sites for two 8-pin I2C parts. One is a time-of-day clock and the other is a 256-byte EEPROM. There are some neat features of the TUC52 that may be of interest to you. First, the TUC-52 can make use of the Dallas Semiconductor DS80C320 as the CPU. This part is a really souped-up version of the 80c32. For the same crystal frequency the DS80C320 will execute many more instructions per second than the standard 80c32. Additionally, there is a floating point basic program available in ROM that can run on TUC-52. This basic system (MCS BASIC-52) is a firmware system developed by INTEL and then reworked by many after-market companies. One neat thing about BASIC-52 is that you, the user, can use TUC52 to develop your own basic control programs. TUC-52 provides the hardware to form a rudimentary file system that BASIC-52 interfaces with. Thus, you can have TUC-52 store many different BASIC-52 programs in the TUC-52 BBRAM. You can even configure TUC52 to start executing your basic program at power-up, without any operator intervention. This has lots of possibilities. For most TAPR projects, TUC-52 will interface to an Application Specific Printed Circuit Board (ASPCB) that will have any specialized connectors or additional I/O hardware needed for the specific application. The interconnection between TUC-52 and the ASPCB will be through a 50 conductor ribbon cable. Most likely, the boards will have a 4.5 x 6.5 inch form factor and will stack via 1/2 inch stand-offs. The first application for TUC-52 will be the processor core for the PCON (Packet Printer Controller) project (see article on PCON in this issue). The PCON project turns a parallel printer into a serial printer with motor control. Whenever serial characters are sent to PCON over the RS-232 link PCON will power up the parallel printer and cause the characters to be printed on the hard copy device. Normally, PCON will connect to the serial port of a TNC. This will create a stand-along "hands off" automatic message delivery system. The user just reads the messages off the printer paper without any special action. Many other projects are possible. Let us know of any applications where you think TUC52 might be useful. ***************************************************************************** MetCon Project Ideas Paul Newland, AD7I METCON (Telemetry and Control) was designed to serve as a telemetry system for packet radio. However, that doesn't mean it can't be used for other applications as well. There are a couple of things that I've thought of doing but just haven't been able to find the time to do them. Maybe these ideas will resonate with you and get you interested in doing the project. These ideas are based on the observation that METCON can serve as a vehicle for getting real-world signals into a PC. Once the signals are in the PC, common programs like QuickBasic (or whatever) can be used to process and display the data on the PC's color video monitor or the paper printer. Here's a couple of my ideas where METCON could be used for other than its original intended purpose. Strip Chart Recorder One tool that I've wished I've had at home over the years is a strip chart recorder. To most lay people this is the business end of an EKG machine that's used to give a doctor a status report on the human heart's function. A roll of paper is dragged across a pen and the pen can be deflected back and forth across the page (like the needle of a mechanical voltmeter). Another way to think of it is as an oscilloscope with a paper display instead of a video display. Modest commercial strip chart recorders with dual channel inputs start at about $1000. At work we use strip chart recorders to monitor the voltage and current to NiCad batteries as they charge and discharge, the time varying voltage characteristics of telephone lines, relay bounce and actuation times, etc. For the ham workshop why not use METCON to measure analog signals, pass them to a PC via the RS-232 port, and have the PC display them on the video monitor (and possibly the printer) as a strip chart display? In this case the cost of a strip chart recorder would be the cost of the METCON system (assuming that you already had the PC and printer). Most real strip chart recorders can be set to run as fast as 50 cm per second and as slow as 1 cm per hour. My guess is that a METCON-based strip chart recorder that takes inputs from the VTF (voltage to frequency) board really could run no faster than 1 cm per minute, since there are only 7 samples per minute of each channel (up to 8 channels). The advantage of using a VTF is that the PC would get about 12 bits of data per sample and the VTF board can be a long distance from the METCON system. But, for a system that takes inputs from the A/D board, and with the METCON running in a high speed A/D reporting mode, well over 100 samples per second could be sent to the PC (and that's 8 channels each sampled 100 times per second). The downside of using the A/D board is that there would only be 8 bits of data per sample. Anyway, this looks like it has some possibilities. NiCad Battery Exerciser Ever wonder how much life your NiCad battery packs for your hand-helds had in them? How about using METCON and a PC to form a "battery exercisor"? Here's how it might work. A power supply, some resistors and METCON's relays would be configured to allow the battery to be charged at the standard C/10 rate and discharged at a C or C/10 rate. (If the battery uses AA NiCad cells then C is somewhere around 500 mA Hours -- thus C/10 becomes 50 mA, C becomes 500 mA and C/10 is again 50 mA). Charging at C/10 simulates the standard wall transformer chargers that need 15 hours to charge a battery. The C discharge rate simulates a hand-held transmitting at 2 watts and the C/10 discharge rate simulates a hand-held receiving with the squelch open. The computer program would ask you how long to charge the batteries (15 hours is typical), how low to discharge the batteries (1.05 volts per cell -- for a standard 7.2 volt NiCad pack (6 cells) that would be a terminal voltage on the battery of 6.3 volts), how much receive time per transmit time (a typical answer would be 3 for 3 units of receive time for 1 unit of transmit time) and how many cycles to run (I'll assume 3). After entering the data, the PC would run through it's algorithm, which is: Charge the battery at C/10 for the period the user asked for (15 hours in this case). After the charge period begin discharging the battery at C for 30 seconds then switch to discharge at C/10 for 90 seconds (assuming the user asked for 3 units of receive for each unit of transmit) and then switch back to C for 30 seconds and again C/10 for 90, etc. Every 5 minutes report the battery voltage on the video monitor and the printer. As soon as the battery voltage gets down to the minimum discharge voltage selected by the user, restart the cycle by going back to charging the battery for 15 hours. Do this charge and discharge cycle 3 times (if that's what the user asked for). The length of time it take to discharge the battery at the alternating C and C/10 rate can be used as a figure of merit. Several cycles are run to see the "discharge time" trend. If any of these METCON projects are of interest to you (or any other project based on METCON) and you would like to write the PC program for them, contact Greg Jones, TAPR's President. I have a hunch that Greg will be willing to work out some arrangement to get you some METCON equipment for your development efforts. ***************************************************************************** Dayton Convention Preliminaries For those die-hard Dayton conventioneers your calendar was marked last year for this year's event. For those not quite addicted, the dates are April 29th, 30th, and May 1st. TAPR will be attending and sponsoring various activities during the weekend. Everything is not firm yet, but we are working on it. TAPR will have a hospitality room open either Friday or Saturday at the Radisson (???), and we will be organizing TAPR SIG meetings after the traditional dinner at McNasties. Of course, TAPR will be present at the exhibit booth as always. ***************************************************************************** TrakBox Panel Layouts Felton Mitchell, WA4OSR If you're building the TAPR TrakBox kit, a set of design files are available to help layout the front and rear panels. The panel layout files are enclosure specific for the Bud LB-1663 Contempo box. This box is a 'ten-tec' type box, gray in color with black plastic side panels, with the following dimensions: 3 1/4" high 7 1/32" wide 7 3/16" deep The box is a mite too small for the pcb to fit into the pcb grooves molded in the plastic side panels, therefore you have to trim the printed circuit board by about 3/32 of an inch. This is easily done with a hand file. It is much easier to do if you haven't populated the board. If you don't want to trim your pcb, you can still use the layout as an example of "how to do it." The layout is for two types of satellite selector switches: 1) the 10-position rotary switch furnished with the TAPR kit (My switch only had 9 positions; a few of the switches had a stop, I had to take the switch apart and remove the stop. Now it has 10 positions.) 2) a pushbutton 16-position switch. I since have replaced the rotary switch with a pushbutton switch from Mouser Electronics. There are panel layouts for both switch types, and the Mouser part numbers are on the design page. The drawing files with the extension .CDR are Corel Draw 3 files. The files with the .GIF extension are GIF files, 1024x768, which you can use to see what the files look like if you don't have access to Corel Draw. If anyone needs a different file type please let me know. I can furnish any file type supported as an export file from Corel Draw. There are nine Corel Draw files available. They show different views (front, back, mirror, etc.) and there are versions for both types of switches (a sample is shown in the figure). The files are available in the HamNet forum on CompuServe. Look for a file named TRKBOX.ZIP. The layout files were created by Raymond Cagle, W4UJZ from information I furnished. As you can see from the layouts, Raymond has done an outstanding job, and you should see the finished product! Raymond has developed a method of transferring the images to the metal that results in a panel that is nothing short of spectacular!!! We will be publicizing the transfer technique shortly. If you find the layouts useful, please drop Raymond a QSL card and let him know about it. He spent a lot of time on the design and he isn't even on the satellites yet! Note: Any errors in the layouts are the fault of WA4OSR, as W4UJZ relied on my information to design the layouts! Good luck with your TrakBox! Mitch, WA4OSR packet: WA4OSR@ W4IAX.#MOBAL.AL.USA.NA internet: fmitch@netcom.com ***************************************************************************** More on using the Alinco DR-1200T at 9600 baud John Webster, KK4LP I recently helped convert three of these Alinco DR-1200T radios to operate at 9600 baud using the following instructions received from Koji Yamada of Alinco: This modification procedure does not require complex removal of the VCO unit as described in the January 1993 issue #49 of Packet Status Register, and therefore poses less risk of damage. Transmitter Modifications a. Remove R31 b. Remove C40 and replace with one end free and the other end reconnected to Pin #7 of the VCO board. c. Connect a jumper between the now free end of C40 and the hot end of C35. The Mic input is now connected directly to the VCO via C40. Transmit deviation should be checked and adjusted as necessary. Try the new TAPR Deviation Meter. Receiver Modifications a. Disconnect (from the PC board) the pink wire that goes to Data Output on the Mic Connector and reconnect it to Pin #2 of the IF Board Connector. (This eliminates the Low Pass filtering.) b. Replace the FL2 filter with a wide bandwidth SFH455B filter. (Available from Alinco.) Note: Replacement of the FL2 filter, while recommended, may not be mandatory with the G3RUH modem but the extra bandwidth is definitely needed with the K9NG modem. We did replace the filters in our application, and the DR-1200Ts worked fine at 9600 bps with one complaint. We found that the T/R turn-around time was very slow forcing us to set TXDelay to over 200 milliseconds, time enough to send a whole packet. If anyone knows of a modification to speed up the DR-1200T's turn-around time, we would appreciate hearing from you. ***************************************************************************** Another Forward Looking Teacher Seeks to Use Packet Radio Larry Lucas, N5XRZ Sheri Herod, KB5UUE, a computer teacher at Arlington Park Community Learning Center in Dallas, Texas, is working on implementing packet radio in the classroom. Sheri obtained her Technician Class License as the result of taking a special graduate course at the University of North Texas during the summer of 1992. The class, taught by Greg Jones, WD5IVD, was a course on radio-based communications from the perspective of uses in education. It has taken Sheri a while to get things going, but she recently applied for and received a grant from the Junior League of Dallas. Sheri's project proposal was titled "A Packet Full of Learning." With the $1488 she received, Sheri intends to set up two stations on opposite sides of the school so classes within the building can communicate with each other. Because of Sheri's enthusiasm, other teachers at Arlington Park have expressed a desire to obtain their Amateur radio license so they can participate. As Sheri puts it: "We hope to communicate with other schools and set up a pen-pal message exchange. We also want our students to study for an Amateur radio license. Later, we would like to connect to other countries to share information." Sheri's goal, then, is to have classes in her school communicating down the hall and around the world. We applaud Sheri's efforts and wish her much success. Start looking for requests for communication from KB5UUE. ***************************************************************************** ARRL National Digital Conference 1994 Announced The TwinsLAN Amateur Radio Club has announced that it will sponsor the 1994 ARRL National Digital Communications Conference on August 19 through 21 at the Thunderbird Hotel and Conference Center in Bloomington, MN. The theme for this year's conference is "Digital Communications - Amateur Radio of Today... and the Future." The objective of the conference is to create a forum for radio Amateurs and experts in digital communications to meet, publish their work and present new ideas and techniques for discussion. Presenters and attendees will have an opportunity to exchange ideas and learn about recent hardware and software advances, theories, experimental results, and practical applications. Areas of interest include generation, coding, modulation and demodulation, transmission, networking, processing, presentation and application of voice, text, image and data information. The conference site is located near the Minneapolis/St. Paul International Airport, just off Interstate I-494. Free 24-hr shuttle service is available to and from the airport. Agenda The agenda for the three-day event includes informal activities for attendees and family members on Friday, August 19 through noon Sunday, August 21. Formal conference activities, including presentation of papers and six forums are scheduled for Saturday, August 20, from 8:30 am to 5 pm. A detailed agenda will be available when schedules are finalized. Call For Papers Anyone interested in digital communications is invited to submit a formal paper for publication in the conference Proceedings. Presentation at the conference is not required for publication. Papers are due by June 20 and should be submitted to Maty Weinberg, ARRL, 225 Main St., Newington, CT 06111 or via Internet at lweinber@arrl.org. A schedule for presentation of papers will be available in early July. Accommodations On-site accommodations are available at a special rate of $67 (plus tax) for single occupancy or $73 (plus tax) for double occupancy. Make reservations directly with the Thunderbird Hotel at 800-328-1931 before July 29 for these special rates. Be sure to mention you are attending the National Digital Communications Conference. Off-site accommodations are available in the area starting at $39.95. Contact the NDCC Info Line for a list of facilities. Early reservations are encouraged. A list of area campgrounds for RVs is also available. Northwest Airlines is offering an additional 5% discount on airfare to and from the Twin Cities for conference attendees. Call the NDCC Info Line for details. A Family Weekend Family participation in the NDCC is encouraged. The hotel has a large pool for guests. Informal outings are planned to the Minnesota Zoo (admission extra) and the Mall of America, the largest indoor shopping mall in the US. Free scheduled shuttle service is also available from the conference center to the Mall. Minnesota is a great place to visit in August. Consider making this weekend an addition to your family vacation plans. Twin Cities and Minnesota tourist information packets are available on request to the NDCC Info Line. Registration The conference registration fee is $45 per person, which includes a luncheon buffet, a set of conference papers (including those submitted but not presented) and transportation to the Mall of America on Saturday evening. Registration, by check payable to "TwinsLAN Conference," must be received by August 12. Mail your registration form and check to: 1994 National Digital Communications Conference c/o Paul Ramey WG0G 16266 Finland Ave. Rosemount, MN 55068 Additional Information Contact Paul Ramey at the NDCC Info Line, 612-432-1149 (evenings and weekends) or Carl Estey via Internet e-mail at estey@skyler.mavd.honeywell.com. ***************************************************************************** AMSAT-UK E-Mail Address Jeff Ward Ron Broadbent, G3AAJ, Secretary for AMSAT-UK, has now been re-connected to the Internet. His address is: r.broadbent@ee.surrey.ac.uk Please update your address books. Mail sent to this address prior to 17 January 94 will NOT have reached Ron, so please re-send it. If you have any continuing difficulties with email to this address, please send your enquiries to me (j.w.ward@ee.surrey.ac.uk) and I will try to sort them out. ***************************************************************************** Product Review: AntennasWest Pico-J Two-Meter Portable Antenna Dave Wolf, WO5H [This review courtesy of Packet Power Newsletter Copyright 1994 Maingate Resources. Permission to reprint in the PSR granted by David A. Wolf, Maingate Resources.] If you're one of the many technically-oriented folks who travel on business quite a bit, you might normally take a laptop computer with you. Since you're a ham, you might also toss a small, low-current consuming TNC like a KPC-3 into your briefcase with your handheld, and do a little packet radio while you're stuck in your hotel room at night. Sure beats running up your expense account watching an in-room movie, or pretending to be a lounge lizard in the hotel bar. Portable packet pioneers had several major obstacles which have been largely overcome. The first was the electrical noise generated by the computer. Today's generation of portables are a lot quieter, both by regulation and just plain better design. Another problem was the noise of the TNC. Even some of the 'micro' TNCs created more than their fair share of RF noise. The solution was to move the handie-talkie as far away from the TNC and computer setup as you could. This meant having to carry a long and often bulky interface cable with you. Ideally, the HT had to be positioned near a window. A chair made an excellent HT holder, especially if the antenna of choice, the AEA Hot Rod, was extended to maximum. Just sitting on a table top, the HT would tend to tip over easily with the Hot Rod extended and you accidentally pulled on the interface cable. If you like to travel and take your portable packet equipment along with you, you'll want to consider the Pico-J from AntennasWest. This is a slender J-pole constructed of TV-type twin-lead, fed with six feet of RG-174 coax. The coax is terminated in a BNC (gold-plated center pin). The J-pole is an end-fed, half-wave vertical antenna. Since it is a half-wave, it does not use a ground plane. This is the secret of the excellent performance of the Hot Rod and its imitators. A rubber duck is typically matched like a quarter-wave antenna, requiring a ground plane or counterpoise to be an effective radiator. Your body capacitively couples to the HT when you hold it, making you part of the antenna system. The Pico-J is weather-sealed, though I would imagine that if you could install an outside antenna, you would be using something more substantial than this one. A short loop of nylon fish line is attached at the top of the antenna, and the package includes a suction cup and small hook for temporary window mounting. You can snag the loop over anything convenient. I have been testing the Pico-J hooked to a picture hanger where a battery-powered clock normally goes in the ham shack. A vinyl pouch is included so you can roll up the antenna, coax, and the accessory suction cup in there quickly. The sample Pico-J sent for my review very slightly outperforms the AEA Hot Rod for both receive sensitivity and reported transmit signal strength under most conditions. The Pico-J seems to be much less susceptible to proximity effects than the Hot Rod, a plus. While the Hot Rod can be maneuvered around to catch a 'hot spot,' this is not desirable while your are operating portable packet. You can't type and hold an HT at the same time. Walking around I would prefer the Hot Rod, naturally. In a semi-fixed position, such as in a hotel room, or at an emergency communications site, the Pico-J would be the wiser choice. It can take the abuse of someone or some thing accidentally knocking it around, while a telescoping antenna is either vulnerable to damage or as a potential weapon. The downside to the Pico-J is the short piece of coax. For my testing, I extended it with a length of RG-8X. Six feet just doesn't cut it. I tested it hooked up to a handheld and to a mobile rig cranked down to ten watts. In the shack, it created far less RFI than a mag-mount mobile antenna connected to the same transceiver. The antenna has a lifetime warranty. Price: $19.95 (includes shipping) AntennasWest P.O. Box 50062 Provo, UT 84605 Phone: (801) 373-8425 Fax: (810) 375-4664 ***************************************************************************** GRAPES Address Correction In the article "Equipment Options for Medium to High-Speed Packet" which appeared in issue #52 of PSR, we listed the old address for GRAPES, suppliers of the WA4DSY 56 Kbps modem. Bob Merritt, KA4BYP, is now handling kit and information requests, the new address is: GRAPES, Inc. PO Box 636 Griffin, GA 30224 internet: ka4byp@netcom.com packet: ka4byp@kd4nc.atl.ga.us ***************************************************************************** Error Correction Codes for Packet Radio Tom McDermott, N5EG Background - Error Free Packet Radio One of the significant advantages of packet radio is the ability to send packets error-free. This ability allows highly automated bulletin boards, automatic forwarding of messages, high speed packet networks that can perform switching, and it allows the use of advanced protocols, such as TCP/IP. Error-detection in AX.25 This error-free communication capability is provided through a technique known as the CRC - or Cyclic Redundancy Check, coupled with the protocol that utilizes it, AX.25. In AX.25, each complete packet may consist of up to 256 bytes of data (plus a couple bytes of header addresses). Your TNC adds 2 bytes to the end of each packet which contain the CRC, or error-detection byte. The CRC is computed within the SIO chip on your TNC but is basically a running 16-bit summation of all the bits within a complete packet. The summation is done in a manner that allows us to determine at the receiver if the bits are likely to be the same ones that were transmitted. That is, if we add up the received packet bits, and we get the same answer that the transmit SIO chip got, then we probably have received all the bits correctly. The actual algorithm is a little bit too complicated to discuss here, but it is capable of detecting any single-bit error in the packet (with a 0.0036% chance of a mistake). Error-correction in AX.25 So what happens if we detect a mistake in the received data? It would be desirable to correct the mistake, and this is the second function of the AX.25 protocol, packet sequencing. In AX.25, serial numbers are added to the front of each packet (they can range from 0 to 7 in value). The receiver has a simple policy: if it receives a packet with even a single bit error (detected via a defective CRC) then it 'throws away the packet'!! However, the situation does not go on for long. When the receiver notices that it has received a sequence of packets, and one of the serial numbers is missing (actually, they are called 'sequence numbers'), then it halts processing further packets after the missing one, and asks the transmitter to re-send all the packets, starting with the missing sequence number. For example, let's assume that we correctly received packets with sequence numbers 0, 1, and 2, and then packet 3 had a single bit error, and packet 4 was OK. The TNC would receive and decode packets 0,1, and 2, and send them to your terminal, but would discard #3 due to the bit error. Then it would discard packet #4, since it was received immediately after #2, and that means that packet #3 was missing. So, when it received #4, it would reject it, and ask for a repeat of all packets later than #2. This strategy of error correction is called 'Go-back-N.' We can get away with only using 8 values of sequence numbers because we only allow 7 (maximum) unacknowledged packets at one time (it gets complicated, but it does work). Packet efficiency The Go-back-N technique works very well, as anyone who has used AX.25 radio can attest - errors in received packets due to transmission impairments are rare (I've seen 2 in my 10 years on packet!). However, how efficient is this strategy? Let's take a look at an example. Suppose that we have a channel with a bit-error-rate of one bit in ten thousand (we will abbreviate this as 1.0x10E-4, or a one-in-ten-thousand chance of any particular bit being defective. Let's assume that our packets are absolutely full, ie: 256 bytes of data are in each packet. The packet will have a length of approximately 2000 bits (after adding the overhead, and AX.25 bits). So the packet has an approximate probability of one bit error = 2000 x 10E-4, or .2 chance (20%). System efficiency What does the 20% packet rejection rate mean to the throughput? Let's assume that we send a burst of 7 packets (each of 256 bytes) in each transmission. We find that to send 7 packets, we will, on average, have to transmit about 11 packets. So our channel efficiency would be about 63%. In fact, things get worse, since the receiving station has to send packets back to the sending station and sometimes those packets are lost due to errors. The thing that really kills the throughput, however, is that we have to wait for the receiving station's TNC to time-out before we recognize that we have lost some packets. This time-out delay is on the order of several seconds, and since we will have only a 0.20 (20%) chance of getting all 7 packets right the first time, we will have to transmit several times, and wait for several time outs before we have succeeded in getting our 7 packets across the radio link. We can see that the throughput drops to almost nothing very quickly. Improvements in bit error rate One method to improve things would be if we could tolerate occasional bit errors in our packets, without losing the packet. One method of doing this would be to add additional bits to each packet that were redundant - that is that did not convey additional information, but that allowed us to detect and correct any bits that are in error. Basically, we will group several bits together, say 16 bits, and add some redundant bits, say 5 bits, and send the combination of 21 bits. Then if any one bit is wrong, we can detect and CORRECT any bits in the packet that were in error (even a wrong correction bit). The logic behind this technique is more than we can discuss here, but it is similar to error-correcting memory used in mainframe computers. It's sort of like parity, except that we have enough additional bits to allow us to zero in on the defective bit. However, we cannot correct multiple bit errors with this scheme. For radio links, we typically have BURST errors, rather than isolated single bit errors (usually due to a rapid fade, or a noise pulse longer than one bit time). It would be desirable to tolerate several bit errors, and be able to correct them. A clever technique to do this is to inter-leave the data streams where each group of 21 bits is broken up so that no two adjacent bits belong to the same 21-bit grouping. For example, we could decide to have 10 groupings of 21-bits in process at any one time. We could transmit the 1st bit of group number 1, followed by the 1st bit of group number 2, followed by the 1st bit of group number 3, and so on to the 1st bit of group number 10, which would then be followed by the 2nd bit of group number one, the 2nd bit of group number 2, etc. Such a strategy would allow us to survive a BURST error length of 10 bits, since the BURST would then only destroy one bit in any particular 21-bit group. Of course, if the error burst were to be 11 bits long, then we would lose 2 bits in one of the 21-bit groupings, and we would be unable to correct the error in that group. Coding schemes known as interleaved block codes (or sometimes known as a Reed-Solomon code) are similar in many respects to this simple example, and can achieve significant performance improvements on radio channels that have significant probabilities of error. Note however, that collisions, due perhaps to the hidden-transmitter effect, or due to other reasons, are NOT corrected with this scheme, because the length of time when the collision occurs is very long, and it would obliterate more than 10 consecutive bits (in this example). Packet loss rate with coding Let's look at the effective error rate after we code the packet with the redundant error-correcting bits. In the example above, and assuming the 10E-4 Bit Error Rate (BER), the packet loss rate for the 2000-bit packet would be reduced from 20% packet error rate, to a loss rate of about 0.01%, certainly a substantial improvement! Effect of redundant bits One of the drawbacks with this strategy is that we have to send additional bits in order to communicate, so the efficiency of the channel is reduced or we have to increase the data rate to achieve the same throughput as an error-free channel. Of course, if we really don't have error free channels, then we probably get a net improvement in the channel usage since we don't suffer from having to send packets two and three times, and wait for the time-outs to occur like we do with AX.25. In order for our 1200 baud channel to support the example above, we would need to send at a data rate of 1575 baud to achieve the same throughput as an error-free channel. As we increase the data rate of a radio channel, we degrade the signal-to-noise ratio (assuming constant power) and so we have a trade-off to make regarding throughput. On some bands, such as high UHF frequencies, we probably do not have so much of a problem with bit error rates. However, if our modems are not properly designed, then we may have a problem even then. Generally, the problem with bit errors increases as we go down in frequency, becoming worst at HF. So an interleaved-block error-correction code would be very useful for HF packet radio, and perhaps useful at VHF, and even UHF, depending upon the circumstances. Improvement due to better retry strategy Another technique to improve packet throughput would be to save the subsequent good packets that we currently throw away after receiving the bad packet (this method is called selective-reject, and is utilized in IBM's SNA protocol). It would, however, require re-writing the AX.25 protocol, and would require TNC's to have knowledge about several different versions of the protocol, something not as likely to happen as the redundancy coding discussed previously. Summary Amateur packet radio throughput, particularly on HF, can probably be significantly improved with the use of error correction codes. At slow data rates of HF operation, this can even be accomplished in software on a computer. ***************************************************************************** HROUTE Forwarding - An Alternate Approach Mike Steup, KA2MSL [Reprinted from the NEDA Quarterly, vol. 4, no. 2, published by the North East Digital Association.] Purpose The purpose of this paper is to propose a different approach to BBS personal mail forwarding using the six character grid square locator. Background This method was developed to solve an ongoing problem encountered while forwarding using the R-header. History Since the beginning of message forwarding, political boundaries have been used. Forwarding by R-header became prevalent in the late 1980s. The accepted format being callsign.XX.YYY.ZZ where XX is the two character state code, YYY is the three character country code, and ZZ is the two character continent code, giving a string length of 10 (including the periods). Parsing could be done on either callsign, state, country or continent, in that order. So, the typical R-string would be: KA2MSL.NY.USA.NA As the number of bulletin board systems grew, it was found that the state designator was too large to be useful so an area field was added to the string in the format #WWWW. This field would contain a geographical location within the state and be used for intrastate forwarding. A typical format could be #MHV (Mid Hudson Valley). This describes the area of New York State north of the Westchester/Rockland counties and south of the greater Capitol District. This adds another five to six characters to the string. The string now is: KA2MSL.#MHV.NY.USA.NA There were now five sub strings to use to determine location. This has become an accepted standard by many BBS systems in the United States. There are those sysops who felt that the two character continent field was inadequate and expanded it to 4 characters. (e.g.: NOAM vs. NA for North America). This could give us a 25 character string. While useful in routing, this added information does increase the overhead in sending a message or bulletin over a long distance. Multiply this by the number of stations that handle this message and this will add kilobytes to the total send length. In fact, the R-header information exceeds in size the total length of the message in many instances. A Different Approach For years, contesters have been using the grid square as an exchange for location of the station worked. A grid square is a 2 x 1 box based upon the latitude and longitude of a station. This information is not only used to determine location but is also widely used to determine distance and beam heading between two points. The format is AAnn (two letters and two numbers). (e.g.:FN21). Because the size of the 2 x 1 box is quite large in the temperate zone, the box has been further divided into 5 x 2.5 sub squares in the format aa-zz. So, the format becomes AAnnBB (e.g.: my QTH is FN21XM). This gives a very precise location of a station. In fact the remote sysop for my system lives only a Few miles away and is in the FN21XN box. My proposal is to use the callsign and grid square as the R-header information in the format: Callsign.AAnnBB (a maximum of 13 characters). This provides each BBS with an identification string which not only provides location, but also direction from the originating BBS. Since most BBS systems allow wild cards and exceptions, parsing becomes a simple matter on a local and regional basis. Forwarding by callsign is unaffected. The following examples are given using the FBB format which is what I am using at my BBS and should be adapted for use with your individual system. Sending mail to a BBS located at FN21XM would look like this: H FN21XM Let's say that on a regional basis you wish to forward mail for stations in FN31 and FN21 but not FN21XY, your script might look like: ! H FN21XY H FM31* H FN21* In the FBB system the ! means 'with this exception' and always should appear before the command to be accepted. An asterisk is a wild card. Assuming that we service FN31, FN21, and FN20, the H-route portion might be: ! FN31* Don't send this ! FN21* Don't send this ! FN20* Don't send this H *.* Send all else Using this method of H commands and exceptions the sysop may parse over as wide or as fine an area that he wishes to define. Implementation To avoid confusion and make the transition easier, the implementation of this plan might be in three Phases. Phase One Replace the #WWWW regional subdesignator with the six character grid square. Pre Phase 1: KA2MSL.#MHV.NY.USA.NA Post Phase 1: KA2MSL.#FN21XM.NY.USA.NA Phase Two Following a sufficient period of time, the state designator could be removed along with the leading #, yielding the following: KA2MSL.FN21XM.USA.NA Phase Three The final phase could occur once this plan is implemented on a global basis, and the Country and Continental designators become redundant. We would arrive at the final form: KA2MSL.FN21XM Conclusion Using an existing standard we can: Define the global location of an individual BBS Reduce the size of R-Headers and forwarding overhead Simplify forwarding scripts by eliminating political (state) boundaries This method is being tested in the upper New York State area. So as not to upset those stations not participating in the study, the grid locator info was inserted before the regional sub string and preceded by a .# and followed by a period: KA2MSL.#FN21XM.#MHV.NY.USA.NA It was found that two regional strings caused some concern on the part of several sysops, therefore those of us in the test group have substituted the grid locator for the regional string, effectively implementing Phase One, on a test basis. ***************************************************************************** Using the G3RUH Modem at Higher Speeds James Miller, G3RUH [Reprinted from the October 1993 (No. 103) issue of Oscar News, published by AMSAT-UK.] I am frequently asked how to make my 9600 baud packet radio modem, as used by UOSAT and packet trunks, go faster (and slower!). The prospect of a 38,400 baud device on a new UOSAT prompts the following notes. That neither your TNCs go this fast, nor will your radios have the bandwidth necessary, is not my fault. Onward! Upward! Enjoy! The modem is capable of speeds up to 64,000 baud. This limit is set by the maximum rate that the D/A converter chips can operate. This note describes how to achieve rates from 4800 to 64,000 baud. The slowest speed is suitable for 12.5 KHz channelized radios. The highest speed suits radios that have broadcast FM bandwidth filters. To implement a higher speed, you need to: 1. Increase the TXData rate (not surprising really!). 2. Increase the associated 16X TXClock. 3. Change some analog filter components proportional to the speed change. It is not necessary to change either of the EPROMs. If you are going for a higher speed, it is likely that the radios involved are "specials" and you will already have wide bandwidth and flattish group delay, so the loopback selection 0 from the standard TXBETA1 EPROM will be OK. The table suggests the best component values for different speeds. These modifications have been tested in both Amateur and commercial service. All comments gratefully received, and added to the database. ***************************************************************************** Packet Software for the MAC: Savant George Dorner, W9ZSJ [Reprinted from the September 1993 issue (vol. 9, no.5) of The CAPRA Beacon, published by the Chicago Area Packet Radio Association.] Savant is a very Mac-like communications program made specifically for packet radio applications. Its use of scroll bars and its support of multiple windows, together with a menu bar equipped with a nice complement of standard Mac and packet specific functions will please almost any ham with a Mac. The program comes from Jim Van Peursem, KE0PH, and has recently been advertised in QST and elsewhere. Unlike Jim's other product, Virtuoso, this is not shareware and is distributed with a nice, clearly-written manual. Savant is like other good Mac software: usable without reading the manual. There is one notable difference between Savant and Virtuoso and most other terminal emulation software: Savant operates in KISS mode. This means that you need to turn on the KISS mode of your AX.25 TNC with the appropriate TNC commands before you double-click the Savant icon. Then Savant itself does the protocol work usually done by the AX.25 TNC. This also means that Savant doesn't look much like the typical command line TNC firmware. An annoyance to some may be the fact that Savant won't talk directly to your TNC in AX.25 mode, necessitating the use of other communications software to change your TNC to KISS mode initially. Of course, if you don't use an AX.25 TNC in the first place this is not a problem. I have used Savant with my MFJ 1270 and the KISS command on, but the better and cheaper way is to use the PacketMac (BAYCOM-like) modem board and the SoftKISS init which strips all the AX.25 stuff from the packets received. The software features of Savant are easy to discover by just checking the pull-downs on the menu bar for File, Edit, Network, Options, Format, or Window. Most of these have the expected functions, with Network and Options holding most of the packet features. These support making connections and setting parameters and filters. There is no built-in "personal BBS." Double-clicking the Savant icon opens a Monitor window which "shows all." Each subsequent connection has its own labelled window with a 32K buffer. As you would expect, all the incoming packets for a window may also be saved to disk. You may print all, or only the selected part, of any window, and you may edit new files for sending with a built-in Teach Talk-like editor. I like being able to Append to a file. You may also just Hide Savant from the Mac Menu Bar or point-and-click to another application window while using Savant, just like any other Mac program. You initiate a connection with a Command-K which opens a window in which you may enter the call of the station you wish to connect to and, in another line, the calls you wish to digipeat through. During the connect process, the hands of the familiar "working" watch spin until the connection is made. Then the watch is replaced by a moving "wave" between two icons for antennas and this "motion" remains until the connection is broken. A status bar at the top of the window displays Packets Acknowledged, Packets Outstanding, Retries, and Round Trip Time. Each window for a connection is split to separate what is received from what is to be sent. I like being able to switch to Courier or some other mono font from one of the proportional fonts and back, just like on my word processor. Another very nice feature is the optional Stations Heard window which shows the most recent time and the total number of packets for the last twenty stations heard. This is updated dynamically and is a busy window on a busy channel. How many of the parameters on your AX.25 TNC do you use? They're not all here in Savant, but all the important functions seem to be. Rather than description by code words (DWAIT, FRACK, TXDELAY) they are labelled to be understood: Probability of Transmitting, Packet Acknowledge Time, Push To Talk Delay. This is intelligible to beginners and even to others, even though it's "non-standard." Savant closes a connection if you use the Network pull-down or if you hit Command-D. All open connections may also be forced closed with a special command. This has become my standard packet software on both my SE-30 and on my Duo 230 when I am not using TCP/IP. Its convenience and gentle learning curve are what one would expect of good, useful Mac software. Though it has few bells and whistles, I think it is a fine bargain in the $50 range. I can't wait until the author and others in his circle bring us Mac-users an equally friendly interface to TCP/IP. ***************************************************************************** Interim Report of the ad hoc 219 MHz Committee Introduction This ad hoc Committee was created by direction of the Executive Committee of the ARRL Board at its October 30, 1993 meeting in Memphis, TN. The Committee is composed of four members selected from the ARRL Spectrum Committee, and a Chairman selected from the ARRL Directors. Two members of the ARRL staff were assigned as support. The members of the Committee are: J. Gordon Beattie, Jr., N2DSY Tod Olson, K0TO Chairman James Fortney, K6IYK Paul Rinaldo, W4RI Joel Kandel, KI4T Jon Bloom, KE3Z David Prestel, W8AJR This committee was asked to prepare an action plan for initiating Amateur activity on the 219-220 MHz band discussed in the FCC Notice of Proposed Rule Making (ET Docket 93-40/RM- 7747), issued by the FCC March 22, 1993. The comment period for the Docket ended July 15, 1993 and the expectation is that the FCC will issue a Report and Order sometime after March 1994. During the period November 15, 1993 through January 6, 1994, Committee members exchanged preliminary information via mail, FAX, MCI and telephone. On January 8 and 9, 1994, the Committee held an in-person meeting in Cleveland, OH This interim report is based upon the ideas developed during that period. Committee members were encouraged to discuss this topic with anyone they felt might contribute useful information. No attempt was made to restrict the flow of information to the Amateur community before or after the Cleveland meeting since it was the sense of the Committee that disclosure of such information would be not only useful, but essential to drafting a final recommendation. The interim report following is divided into two parts; a background section which summarizes information and a plan for utilization of the band. The background section summarizes the things requested in the ARRL petition for access to this band, the list of requirements for Amateurs as outlined by the FCC in their NPRM; the key expectations of the FCC and WaterCom (an AMTS user) for Amateur use of the band and the expectations for utilization of this frequency band from an Amateur point of view. The plan for utilization of the band includes specific ARRL actions and proposals for a band plan and a coordination procedure. Background The committee reviewed the original ARRL petition for access to the band, RM-7747, the FCC Notice of Proposed Rule Making(NPRM) Docket ET-93-40, the NewsRelease from the FCC at the time the NPRM was issued and comments to the NPRM made by other Amateur groups. The information developed by the Committee from these sources is summarized in the section following. The information is organized into that requested in the ARRL petition to the FCC, the specific Amateur requirements outlined in the NPRM, the expectations for Amateur use of the band as drawn from the NewsRelease and the NPRM, expectations of the primary AMTS organization, WaterCom; and Amateur expectations drawn from the petition, comments and Committee conversations. The ARRL petition for additional 1.25 meter frequencies On June 4, 1991, the ARRL petitioned the FCC for an Amateur service frequency allocation in the 216-220 MHz band. The basis for that petition was the loss of the 220-222 MHz segment by FCC action; which action had blocked evolving Amateur activity that was moving toward creating high-speed inter-city digital links. It had been a part of Amateur plans and expectations that the 220-222 MHz links would be interconnected to achieve a high-speed nationwide communications system funded and maintained by Amateurs. This network would serve Amateur interests in its daily operation, but its emergency preparedness and national defense capabilities would be available when required. In its petition for spectrum in the 216-220 MHz band the ARRL noted that Amateur use of that band would be on a secondary, non-interference basis and specifically for coordinated, high- speed digital point-to-point communication. For Amateurs to do this successfully, it will require not only the frequency coordination between Amateurs which is now a part of Amateur VHF-UHF operations, but will require coordination of frequency and direction of transmission with respect to existing, and future, Primary Users . Further, the ARRL felt it would not be advisable for Amateurs to be able to access the band without prior coordination by a spectrum manager (and)/or database administrator to assure that chances for interference to a Primary User of the band were minimized. The ARRL offered its services in this role and stated its willingness to provide advice to Amateurs wishing to initiate operation in the band as well as providing notice to Amateur users of the band when new, non-Amateur users initiated operation. The ARRL proposed the following changes to the Part 97 rules : Auxiliary station operation be permitted only in the 216-220 MHz, 431-433 MHz and 435-438 MHz band segments. In the 1.25 m band, the segment 216-220 MHz should be used only for point-to-point Amateur fixed operation, and 1. No Amateur station shall cause interference to maritime mobile, fixed stations or other mobile licenses operating in the band. 2. Prior to commencement of operation in the band, Amateur stations are cautioned to contact a database administrator for frequency recommendations. 3. The licensee of the Amateur station must make all necessary adjustments (including termination of transmission) if harmful interference is caused. Transmitter power must be limited to 25 watts PEP when the control operator is a Novice Class licensee and 50 watts PEP for higher license classes. Amateur requirements for operation as specified in the FCC NPRM Amateurs will be required to operate on a secondary basis in the frequency band of 219-220 MHz Operation will be Amateur auxiliary stations or as other Amateur fixed point-to-point operations. Maximum symbol rate of 56 Kilo Baud for codes specified in part 97.309(a) and a maximum of 100 KHz bandwidth for codes not specified in 97.309(a) Prior to initiation of operation, Amateurs within 50 miles of an AMTS station will be required to obtain written approval from the AMTS allowing them to operate. Prior to initiation of operation, Amateurs further than 50 miles but within 150 miles of an AMTS station must provide official notification of intention to begin operation at least 14 days prior to the start. Amateurs must operate in a fashion that does not interfere with US. Navy SPASUR no matter where the Amateur station is located. FCC expectations for Amateur operation in this band. Effective utilization of this band by Amateurs is anticipated to require technological innovation on the part of the Amateurs. New technology as it arrives may provide cause to consider amendment to the rules. WaterCom (and other AMTS licensees) are expected to develop procedures to effectively exchange data about their operations with Amateurs so that their operations may be adjusted to avoid interference to the AMTS. Frequencies will be used for inter-city wide band digital communication links. To avoid interference to Primary Users (and to each other), Amateur links will utilize highly directional antennas, will employ operational flexibility, and will be coordinated. As has been the case to this point, the FCC does not expect to mandate frequency coordination, but instead expects Amateurs to cooperate and coordinate on their own. WaterCom expectations for Amateur secondary use of this band. Amateurs are expected to perform the necessary "engineering" to assure non-interference prior to initiating operation in the band. A single point of contact will exist for WaterCom to communicate interference notices and information about WaterCom operations. Amateur expectations for utilization of this band. This band is probably the only band in which a terrestrial nationwide network is feasible. Two meter regulations do not permit wide band, high data rate transmissions, and 70 cm does not have as favorable propagation characteristics. The 219-220 MHz meter band has good mid-range propagation, has relatively little adjacent channel use, and there is no existing use by Amateurs. For these reasons, we can structure its use from the outset toward high speed digital point to point links which can be assembled into a nationwide network. At this point equipment for high speed digital links is not readily available to Amateurs. Some 56 Kilobit half- duplex modems are in use, but there are very few in operation at present. Some 19.2 Kilobit links on UHF are in place. Overall, equipment and other technology which would support data rates greater than 150 Kilobits/sec running full duplex remain to be developed for Amateur links. Achieving these high rates in a nationwide network would position amateurs to be able to send "snippets" of voice, audio and video as well as the person to person text messages, DX spotting information and data files that are common today. Proposed Plan for 219 MHz It is recommended that this band be used to establish a high speed nationwide digital data network by linking inter-city point-to-point Amateur stations. The Committee estimates that 700-800 individual links will be required to achieve a true, nationwide network and may take five to ten years to reach that stage. Use A proposal for a 219-220 MHz Band Plan has been prepared and is attached as Appendix A . It is expected that in populated areas, to compensate for the loss of 220-222 MHz, there may be a desire to utilize the 219- 220 MHz band immediately with whatever technology may be at hand. We believe this would be self-defeating. Strong encouragement on the part of Local Coordinating Bodies(LCB), the ARRL, and other groups of Amateurs to carefully coordinate the use of this band will pay big dividends. An effective, high-speed network will make handling of packet messages via local bulletin board and messaging systems more productive. An end result will be to reduce pressure on some of the 2 meter links now in use as a message network. Since it is very difficult to "adjust" the use of a band or portion of a band after use has begun, we recommend that a technical threshold be established for individual links, assuring the success of a high speed nationwide network. At this point, it means that no point-to-point links of 1200, 2400, 9600 or even 19,200 baud should be created. Point-to-point transmissions on this band should be a contiguous stream of bits with header frames for routing. The equipment associated with the transmission between links should not be required to be cognizant of any special attribute or content of the bits being transmitted. Data from all sources should be handled in a uniform manner, impartial as to source and content. Technology and protocol should be developed to manage data buffering to smoothly transition from the high-speed link to lower speed network nodes with eventual delivery of data to the individual Amateur. Coordination A proposed procedure for use by Local Coordinating Bodies is in Appendix B attached. [Editor's Note: Appendix B was removed for publication in PSR, due to space restrictions.] Coordination of stations that use this band is imperative. We will be a Secondary User. Our use will be dependent upon successfully engineering link installations to avoid interference to the Primary Users. More than that, coordination offers the best opportunity to effect orderly and efficient entry into the band in a way that enables Amateurs to link stations into a high-speed digital network. Having learned from the problems of growth of digital communications in heavily populated VHF bands, this untouched band affords an opportunity to employ our hard won knowledge as we plan our links. Role of the ARRL Administrative support The ARRL should develop and maintain a database of current assignments to other services in this band. This information may include information about users adjacent to the band as well as those operating directly in the band. The ARRL should develop a database of amateur links established in the band. This list will aid the coordination process for amateurs and provide a database for reference in the event of interference complaints. The ARRL should establish an operating relationship with WaterCom and other AMTS users so that a single point of contact to handle interference complaints can be created. Also, through this relationship, a database of AMTS users can be acquired to assist in the designing and coordination of Amateur links. The ARRL should prepare and distribute upon request, a procedure for engineering a link installation including handling the required AMTS approval or notification. Technical support The ARRL should develop worksheets to assist Amateurs in planning, engineering, and coordinating their links. A model will be required to investigate the interference potential of Amateur operation in a particular location. Power, antenna orientation, terrain and location of AMTS or other Primary Users will affect the outcome. The ARRL should assign staff and/or sponsor studies which will clarify the technical requirements for RF propagation performance and the technical requirements for modulation/bandwidth performance. The band plan in Appendix A and the Coordination Procedure outlined in Appendix B are predicated on several technical assumptions which require validation. The ARRL should spearhead the Identification of manufacturers of Amateur and/or commercial equipment which can meet the high performance requirements of this network. These manufacturers should be encouraged to develop systems and components which can be used by Amateurs to create the high speed links. The ARRL should stimulate and support the definition of new protocols for use in the high-speed network. This appears to be an appropriate task for the ARRL Future Systems Committee. Standards of all types will have to be defined and agreed to by members of the Amateur community. We need to be able to smoothly couple the existing BBS systems and links to the inter-city links. The ARRL Digital Committee should be asked to contribute to this effort. A network topology will need to be created which will support the integration of diverse existing local networks. It is not clear at this time just how this can be effectively supported by the ARRL. We will comment further in our final report. Information Support The task of assembling a nationwide network from a series of individually engineered and owned building blocks will require a great amount of information interchange. The ARRL should establish a newsletter directed toward information exchange with respect to equipment, software, coordination activity, protocols, network topology, etc. The emphasis here is not "professional product" but current information that can help others. The newsletter actually need not be published in the classic sense. We are able to utilize existing modes of dissemination, e.g. Internet, HIRAM, MCI, CompuServe, etc. The critical component is an information "gatekeeper" and/or editor assigned to receive, organize and perhaps index the information. The ARRL should provide copies of this interim report to existing coordinating groups, appropriate equipment manufacturers and other interested parties making inquiry. Copies of this report and such other information as may be available at that time should be offered at the ARRL Booth at the Dayton Hamvention next April. The ARRL should provide a session at the Digital Symposium this year devoted to discussion of the proposed nationwide network. Extension of 219 Committee Assignment The 219 Committee is an ad hoc Committee which will dissolve after it has prepared a plan for utilization of the 219-220 MHz and presented it for consideration by the ARRL Board. Under our current charter, we expect to issue a final report approximately 45 days after an FCC Report and Order creating the band. This interim report recommends that the ARRL encourage and support the creation of point-to-point high-speed digital links in this band in a form which permits them to be linked into a network. The multiplicity of tasks which are a part of providing the ARRL support and leadership in the establishment of the network, suggests some sort of "Project Management" would be beneficial. Monitoring the various ARRL support activities will help assure that everything is "fitting" together. When the time comes that adjustments to the current plan must be made, the existence of a monitoring group can facilitate those adjustments. We suggest that the Board authorize the existing 219 Committee to assume the role of "Project Manager", and to perform that function for at least one year following establishment of the 219-220 MHz band. APPENDIX A 219-220 MHz Band Plan Local Coordinating Bodies should coordinate this band such that ten 100-KHz Primary channels are created centered on the following frequencies: Channel A 219.050 Channel F 219.550 Channel B 219.150 Channel G 219.650 Channel C 219.250 Channel H 219.750 Channel D 219.350 Channel I 219.850 Channel E 219.450 Channel J 219.950 Use of two of these channels in combination to achieve a full duplex environment is desirable. Since the use of the band is for point-to-point fixed operation with a maximum of 50 watts PEP, and non-interference with Primary Users of the band is mandatory, highly directional antennas with horizontal polarization are recommended. Because the plan for this band is use for inter-city links which can be assembled into a nationwide high-speed digital network, allocation of channels to point-to-point pairs running less than 56 Kilobits duplex should be discouraged. No matter what the bandwidth of the transmissions coordinated into a channel, they should be centered in the channel. The long term objective for digital transmission on these channels is 100 KHz bandwidth. Local Coordinating Bodies should seek to avoid decisions which will limit the nationwide network. ***************************************************************************** Secretary's Report -- A year in review Gary Hauge, N4CHV TAPR Secretary TAPR was on the move during 1993, both figuratively and physically. At the Annual Meeting in March, Bob Neilsen stepped down as President and several new directors were elected to the Board. Greg Jones became the new President with Bob consenting to stay on as Vice President. Minor changes in the bylaws were made to enable decisions to be made at the Annual Meetings when not all the members are present. The TrakBox was reintroduced by popular demand (and availability of parts) in limited quantities. The Deviation meter was introduced at the TAPR Annual Meeting in 1993. The PSK modem was a big item with the satellite users in the past but has been discontinued due to the availability of similar products in the commercial market. The 9600 bps modem attracted many to the higher data rates within the digital community. The software library is constantly being updated with new programs and updates, and the TAPR file server was put on-line in 1993. One of the new agendas for TAPR is to attend more of the ham shows and increase the availability of our products, and the visibility of our organization. Plans are underway to attend the Orlando Hamcation on Feb 18, 19 and 20 of 1994. A campaign to increase the membership through advertisements in ham radio magazines is underway and to retain interest for more experienced members. After several years of dedicated service to TAPR, Heather and Lyle Johnson requested a reduction in their presence within the organization, as a result, the TAPR office was moved from the Johnsons' home to Denton, Texas. The official corporate office is still in Tucson, but the sales office is now located in Denton. Also, new software was installed to make office operations more efficient and more accurate. These improvements should speed up order entry and tracking, and improve inventory management. These changes will provide members with better service in the future, not to mention giving Lyle and Heather their house back. What lies on the horizon for TAPR? Well, the DSP effort is in progress and beta testing is about to get underway. We are also supporting AMSAT on the Phase 3D project which will be assembled in the Orlando, Florida area starting this Summer. Several other projects are just getting underway, and 1994 should be another good year for TAPR; we are looking forward to new challenges throughout the year. TAPR is a volunteer organization and many of the ideas for new projects come from its members, and in some cases non-members. Your support will determine how effective we will be within the digital community. We need your support. If you are a member, renew when your time is due, if not a member, join today! See you at the annual meeting in March. ***************************************************************************** *** Connect Request This column is where you can get in touch with other packeteers who may have similar needs or interests. If you have a question about packet radio, or are looking for a particular type of unusual hardware or software, this may be the place for you. Send your requests to TAPR at any of the usual addresses. Also, please help your fellow Amateurs by responding to requests that you know the answer to. Request: I use a TNC-2C (by Landolt, Germany) and 1.1.8. It is simple to switch to KISS mode, however I do not know the instruction which is needed to return to the normal packet mode. My emulation program is "Packet" -- can anyone there disclose how to switch to "Kiss Off" by the program? From: Dr. Alex Vilensky Haifa, Israel 4X1MH@4X4HF Fax: 04-533111 Response: [The following responses were collected from a discussion which took place in the HamNet forum on CompuServe. The main contributors were Paul Williamson, KB5MU, and Richard Clemens, KB8AOB.] If you are running KISS for NET or NOS, you can type "param ax0 255" to get out of KISS mode. If you're just running a terminal emulator, you need to generate two or three special codes: 192, 255, 192 decimal. The second 192 may or may not be necessary, depending on the details of how the firmware works. To generate these codes on an IBM keyboard, hold down the ALT key while typing all three digits on the numeric keypad. (If you're running under Windows, I think you may have to type them as ALT+0192 and ALT+0255.) You may want to put these three bytes in a file (use COPY CON FILENAME) and just send the file to the port when you want to exit KISS mode. My MFJ 1278 (not turbo) came with a sheet saying you need two commands: You must issue two lines under the "net# prompt" to switch from net# to AX.25 operation. Issue the following two lines: param ax0 255 param ax0 254 I suppose you replace ax0 with whatever you called your TNC. I call mine 'tnc' but you may have used another symbol. It takes two commands in the 1278 not one. I figured the same firmware would be in the 1274 but having bought a 1274 this weekend I find it is not. For the 1274 use: param xxx 255 where xxx is the name you called your TNC serial port connection in the attach statement. If in fact you changed that from 'ax0' to something such as 'tnc' then the command becomes: param tnc 255 and needs to be in lower case. 'ax0' or 'tnc' or 'xxx' is a logical name for a physical address that is specified in the attach command. ****************************************************************************** Tucson Amateur Packet Radio Corp -- Membership Application Name : ____________________________________ Call : _______________ Address : _________________________________ Apt : ________________ _________________________________ _________________________________ City/State : ______________________________ Zip : ________________ Home Phone : ( ) ________________ Work Phone : ( ) ________________ * Is this a renewal ? (Yes/No) ________ * Membership is $15 per year US. Number of years : ________________ $18 Canada/Mexico $25 else where Make Checks payable to Tucson Amateur Packet Radio Corp. Mail to the address below, fax to (817) 566-2544 or call (817-383-0000. Visa/MC accepted. ADDRESS : Tucson Amateur Packet Radio Corp 8987-309 E Tanque Verde Rd #337 Tucson, Az, 85749-2544 End of PSR #53