Gateway: The ARRL Packet Radio Newsletter is published by the American Radio Relay League Stan Horzepa, WA1LOU 225 Main Street Editor Newington, CT 06111 Larry E. Price, W4RA David Sumner, K1ZZ President Executive Vice President Vol. 4, No. 23 August 5, 1988 AMSAT ANNOUNCES 1989 LAUNCH OF PACSATS On July 30, AMSAT-NA President Vern Riportella, WA2LQQ announced plans to launch four "microsatellites" from a single European Space Agency Ariane launch vehicle. Of the four satellites, two would be store-and-forward packet satellites (PACSATs). One of the PACSATs will be operated by AMSAT-NA, the other by AMSAT-LU (Argentina). The current Ariane launch schedule would result in a June, 1989 launch of the AMSAT satellites. The other two satellites will be special-purpose amateur satellites. One is being sponsored by Brazil AMSAT (BRAMSAT), and will carry Project DOVE (Digital Orbiting Voice Encoder). This satellite will carry a synthesized voice transmitter. The final satellite is sponsored by the Center for Aerospace Technology (CAST) at Weber State College, of Ogden, Utah and will carry a low-resolution camera. The startling thing about these satellites is their truly tiny size: a 23-cm (9-inch) cube of less than 10 kg (22 lb) mass. Other organizations involved in the project are Tucson Amateur Packet Radio (TAPR), which is providing some funding, and ARRL, which is assisting with design and construction of the satellites. from AMSAT-NA News Service TEXNET SOFTWARE UPDATE A number of new features have been incorporated into the new code now being tested. This code should be in full release to all TexNet nodes in the next few months. The following new features are included. o Connect CQ @ NODE allows the user to transmit a CQ at the requested node. At the Cmd?> prompt, the user issues C CQ @ XYZ and XYZ would then transmit a UI frame stating that the user is calling CQ from whatever node. o Help contains more information on how to use commands. o When you issue BYE from a PMS or WMS, drops you to the network prompt. The last version of the software would drop the connection and you would have to reconnect for another session. To leave the network, issue BYE at the network prompt and the network will disconnect. o The ***LINKED TO message has been changed so that the node will wait until an acknowledgment has been received from the station. Then, the node will send the ***LINKED TO message. This was changed to increase connectivity to PBBSs that were having problems seeing the ***LINKED TO message, primarily from stations that are unable to buffer what they see being received. o M @ NODE allows the network to support multiple PMS systems on the network. o W @ NODE allows the network to support multiple WMS (Weather Message System) systems on the network. o LS and LW within the PMS will now indicate, when used on a non-WMS system, that they are not available as commands. Issuing LS on a PMS that does not have weather results in a message indicating that you can not use that function. from The TPRS Quarterly Report PS-186 PROGRESS CONTINUES (This story provides additional information to the PS-186 status report published in Gateway, Volume 4, Number 21.) What is it? The PS-186 is a high-speed, four-port packet switch designed by Mike Brock, WB6HHV, Tom Lafluer, KA6IQA, and Franklin Antonio, N6NKF. It is described in detail in the Sixth ARRL Computer Networking Conference Proceedings. Status? In late May, we shipped one of the PS-186 prototypes to Gordon Beattie, N2DSY, of the RATS ROSE project. We applaud the progress the ROSE software project has had in the last year and look forward to a version of the ROSE software that will run on the PS-186. If you will recall, we originally built a run of eleven of the prototype PC boards (Rev X). These were assembled and distributed to several software developers. During the beta test, several small design errors were discovered, resulting in six cuts and jumps on the PC board. These were incorporated into the PC board design and a UART was added for a control port to eliminate using one of the four high-speed ports for control. This revised design is known as "Rev A" (please ignore the past erroneous references to "Rev B"). The first (evaluation) run of the new Rev A PC boards arrived June 29. We quickly assembled one and are happy to report that the design changes appear to be completely successful. The first Rev A board passes all the diagnostic tests. We had a total of five boards built for this evaluation run and we now have #1 running, and #2, #3 and #4 almost completely assembled. Now that the changes are checked out, the path is clear to production of larger quantities of the Rev A boards. These will be built by AEA. As described in Gateway, Volume 4, Number 17, TAPR is organizing a group purchase of PS-186 boards, which they intend to sell in the form of skeleton kits. TAPR needs an indication of interest from you if you would like to participate in the group purchase. Send TAPR a post card! Finally, this last step has taken a little longer than expected and I would like to emphasize that we take responsibility for these delays. They are not due to any action (or inaction) by either AEA or TAPR. from Franklin Antonio, N6NKF, for N6NKF, KA6IQA and WB6HHV via CompuServe's HamNet DIGITAL COMMITTEE AX.25 WORKING GROUP MEETS On July 16, Gordon Beattie, N2DSY; Terry Fox, WB4JFI; Phil Karn, KA9Q; Tom Moulton, W2VY; Paul Rinaldo, W4RI; and Eric Scace, K3NA met to review AX.25 level 2, version 2.0. The homework prior to the meeting was a digest of comments and suggestions from various implementers by Terry Fox and SDL (state description language) diagrams by Eric Scace. Indeed, we found a few bugs in some of the branches and twigs of the protocol, also some areas of improvement. After discussing these topics one by one, we came up with a set of changes that could be applied to a version 2.1. By definition, a version 2.N would be compatible with 2.0, so versions 2.1 and 2.0 could be working together in the field. In addition to the (many) minor fixes, we had to face a knotty problem which was not adequately allowed for in AX.25, that of reciprocal call signs. That is, AX.25 permits call signs up to 6 characters in length, thus call-sign structures such as VP2M/WB4JFI cannot be accommodated, giving us a problem in certain countries. In addition, AX.25 has become the lingua franca of packet-radio link-layer protocols in the commercial and governmental worlds, and other users use call signs as long as 11 characters. After struggling with this problem for several months, the working group came up with a virtually backwards- compatible call-sign extension scheme--a bit quilty, perhaps, but we think it will work. These ideas relating to a possible version 2.1 will be detailled in a paper by Terry Fox listing the reported problems and our proposed fixes and in another paper giving SDL diagrams by Eric Scace with these fixes in place. These papers are to be presented at the Seventh ARRL Amateur Radio Computer Networking Conference on October 1. The Digital Committee does not take protocol changes lightly, and certainly we don't want packeteers to panic. Don't pop your ROMs out, point your .45 at them and say "BYE, old code." It's not that drastic a change. Protocol stability has been one of the reasons why amateur packet radio has grown and why others have adopted it. The plan is to make public disclosure of these ideas and allow sufficient time for comment before recommending implementation of version 2.1. At the same meeting, we talked about a version 3.0. If you think we ought to be cautious about public comment and enough lead time for implementation of a version 2.1, then a version 3.0 should be approached even more gingerly. By definition, a version 3.0 is not interoperable with version 2.0. But then again, link-level protocols are strictly between consenting adults, meaning that they can be used between two stations if the owners agree to do so. Theoretically, they shouldn't bother anyone with whom they're not connected. Unfortunately, this applies only to point-to-point links with no intermediary stations, some of which could be using an older protocol. So, the easiest place to try out a new version 3.0 would be on high-speed (56-kbit/s) point- to-point links, and the worst on 2-meter or HF packet nets where incompatibilities could cause a crash. Nevertheless, packeteers rush in where fools and wise men won't. After dealing with version 2.1, we went on to dreamineer a version 3.0 that wouldn't have serpentine call-sign extensions and would have some additional desirable features. Phil Karn kicked off that discussion, and his description follows this article. In addition, we talked about having not just one but a suite of three link-layer protocols (eg, high-speed VHF/UHF, robust HF, and meteor-scatter). There will be at least one paper on version 3.0 at the 7th Computer Networking Conference. Co- Jerseyites Gordon Beattie and Tom Moulton agreed to prepare a paper. from Paul Rinaldo, W4RI NEW LINK LEVEL PROTOCOL MUSINGS In addition to upward-compatible changes to the existing protocol, the ARRL Digital Committee has been talking about brand new link protocols. I've been working on the preliminary design of one with the following properties: 1. Be much simpler and easier than AX.25 to implement, mainly to make high-speed DMA operation easier. In particular, it will not be necessary to scan every address field in a digipeater string to see if you need to handle the packet or not. 2. Handle completely arbitrary, variable length addresses, including those longer than 6 characters, eg, G0/WA8DED. The ISO "address extension bit" convention would disappear. 3. Take advantage of the address filtering feature in most HDLC chips (this will be useful on busy high-speed channels). 4. Make a clean separation between the datagram addressing layer (the portion with call signs and digipeaters) and the logical link control (LLC) layer. There would be a "link level PID" between the two layers to allow use of multiple LLCs. LAPB could still be used at the LLC layer, but it would have no special status. If it is used, though, it would begin with its own "address" byte of 01 or 03 to signal "command" or "response"; that crude C-bit kludge of mine would go away. 5. The addressing layer would have a header checksum and control bits so a user could say that he's willing to tolerate errors in the remainder of the packet. This is useful for real-time error tolerant applications like packet voice. Frames would look something like this (I haven't decided on field sizes yet): [FLAG] hash_id version flags lpid data_len addr_ptr hdr_cksum address#1address#n data [CRC] [FLAG] The hash_id is a hash function of the address pointed to by addr_ptr. This allows stations to use the HDLC controller's address filter function to screen out 255/256 of the traffic on the channel addressed to others while still seeing all of their own. Broadcasts are handled by the special value 0xff, which the chips can recognize in addition to their own code. The flag bits include ALLOW_DAMAGE and IS_DAMAGED. The checksum is used only if ALLOW_DAMAGE is set, since frames received with a CRC error and ALLOW_DAMAGE off are always ignored. If a frame with a CRC error has ALLOW_DAMAGE set, the header checksum is verified. If it is correct, the IS_DAMAGED bit is set and the frame is processed; otherwise it is discarded. Each address entry consists of a length field followed by the specified number of bytes. They are scanned from left to right; the first entry is always the source and the last is the destination. The data_len field points to the beginning of the data field and the addr_ptr field points to the next address in the chain. When you get a frame, you simply look at the field pointed to by addr_ptr and see if it's you. Move the pointer past the field and see if it equals data_len; if so, you're the final destination, so kick it upstairs to the LLC protocol specified in lpid. Otherwise, you're being asked to digipeat it, so recompute the hash_id from the next address, recompute the checksum if necessary, and retransmit the packet. Comments are welcome. from Phil Karn, KA9Q, via CompuServe's HamNet COMMODORE 64 LIBRARY ACCESS There is an extensive library of files, currently numbering 68, for the Commodore 64 computer and its users on the WB2MNF PBBS in Southern New Jersey. All are available for the asking by using the following commands. 1. To receive a complete listing and full explanation of all files, send the following message: S REQFIL @ WB2MNF Title: C64DIR.15A @ (your PBBS) (No message content) 2. To receive a listing of file names and their length, send the following message: S REQDIR @ WB2MNF Title: C64 @ (your PBBS) (No message content) 3. Once you have decided which files you want, you may request an individual file by sending the following message: S REQFIL @ WB2MNF Title: C64/(file name) @ (your PBBS) (No message content) To recapitulate: do not send messages to SYSOP WB2MNF or me (K2UK). The addressee is REQFIL or REQDIR as specified above. When your PBBS prompts you for a title, enter the name of the file you want as specified above [C64DIR.15A, C64 or C64/(file name)] followed by "@" and the call sign of your home PBBS. When your PBBS prompts you for the message contents, enter nothing except a Control-Z or /EX (whatever you normally use to end a message). Send the message exactly as outlined above including spaces and the call sign of your home PBBS as indicated. If you follow these directions to the letter, the WB2MNF PBBS will know what to do when it receives your message and to whom and where to send the file automatically. Note that the above instructions differ from those published earlier (Gateway, Vol. 4, No. 18). Several errors have been noted in recent requests, notably the use of REQDIR instead of REQFIL for the C64DIR.15A files and the apparent use of C64 as the home PBBS. The former will simply tell you that the C64DIR.15A files exist and how long it is, while the latter will result in a message addressed to @ C64 and not to your home PBBS and is, thus, undeliverable. Please request only one or two files per day so as not to overload the system. I strongly urge you to get the user files first and print them for reference. If you have never requested any files from WB2MNF, it is a good idea to send a message to WB2MNF to let him know where your home PBBS is located. There are a lot of REQFILs and REQDIRs coming in that are addressed to PBBSs that are unknown and Jon has no option but to kill those messages because they are undeliverable. Once you have received any message from the WB2MNF PBBS, you know that the forwarding route is in place. If you have any problems or questions, do not hesitate to ask me. from Ed Ludin, K2UK NETWORKING CONFERENCE REGISTRATION ADDRESS The address for registration for the Seventh ARRL Networking Conference mentioned in the last issue of Gateway is as follows: Don Bennett, K4NGC PO Box 1944 Woodbridge, VA 22193 If you plan to attend the conference, you are asked to register early. A registration fee of $20 will provide a copy of the conference proceedings, buffet luncheon and defray the costs of putting on the meeting. If your registration is received after Sept. 25, the fee will be $30. Make your checks payable to Don Bennett. Registrants will be sent a list of suggested hotels/motels in the area, maps, etc. GATEWAY CONTRIBUTIONS Submissions for publication in Gateway are welcome. You may submit material via the U.S. mail to: Gateway Stan Horzepa, WA1LOU 75 Kreger Drive Wolcott, CT 06716-2702 or electronically, via CompuServe to user i.d. 70645,247. Via telephone, your editor can be reached at 203-879-1348 on evenings and weekends, and he can switch a modem on line to receive text at 300, 1200, or 2400 bauds.