A Blow-By-Blow Account of the 1991 TAPR Annual Meeting ====================================================== The following is based on the notes I took during the TAPR annual meeting. Any mistakes are mine. On no account should you assume that this account represents the official position of TAPR or anybody else. But I hope you find it interesting. 73 -Paul Williamson, KB5MU The 1991 TAPR Annual Meeting was called to order by "Packet" Pete Eaton, WB9FLW, at 9:00AM at the Inn At the Airport in scenic Tucson. The attendees introduced themselves; the usual suspects were present from all over the country. Bob Nielsen, W6SWE, new President of TAPR, announced the new Directors and Officers: President Bob Nielsen, W6SWE - also new director Vice President Harold Price, NK6K Sec/Treasurer Greg Jones, WD5IVD - also new director new director Jerry Crawford, K7UPJ Greg Jones, WD5IVD, presented the proposed agenda for the meeting. Bob Nielsen, W6SWE, introduced Bob Hansen, the new editor of the PSR. Bob Hansen stated that, as always, he's looking for articles for the PSR. If you're doing something interesting locally, even if it seems like old hat to the local crew, it can make an interesting PSR article. Examples: database applications, video, 9600 bps interfacing, regional activities, networks with special features, DX nodes, WX nodes. Ghost writers can be provided if you're afraid your prose isn't ready for prime time. PSR also accepts would-like-to-get- in-touch-with and help-wanted notes. PSR would like to receive as many local newsletters as possible. Question: Would it be possible for PSR to routinely publish a list of local and regional groups? Answer: Sure. Everybody please tell me about your local and regional groups, and PSR will print it. The one and only Heather Johnson (TAPR office staff and "the Mother of all Johnsons") was introduced. She welcomed everyone to Tucson, and apologized for the weather (it was raining). She announced the hospitality suite in the hotel, where she'd be holding court to sell various merchandise and accept membership renewals. Kit prices may be going up, so she urged us to buy now. TAPR office hours will be more strictly observed: 10:00 AM to 3:00 PM Tuesday through Friday. The answering machine will take your message other times, but Heather would rather speak to you in person (and you'll enjoy it more too -Ed.). Pete Eaton, WB9FLW, presented a corsage to Heather, in appreciation for all the hard work. He described her as TAPR's biggest asset and Secret Weapon. ============================= Harold Price, NK6K - Microsat status report This is the first TAPR meeting since the Microsats became operational. Four microsats were launched; one was half funded by TAPR out of the proceedings of TNC-2 sales. The satellites were designed by AMSAT, but the funds came from various organizations around the world. Microsats serve as floating BBS stations, and they are optimized for that application. About 9 inches on a side, they weigh 22 lbs and carry 3 transmitters, 6 receivers, a NiCd battery pack, a computer with 8 megabytes of memory, serial ports, and a telemetry and control system. A slide of AMSAT OSCAR-16 was shown. These satellites are much simpler than AO-10 or AO-13, since the payload is basically a computer, and the orbit is low. They contain no moving parts. Attitude control is required to control thermal problems: hot on one side and cold on the other is only good for McDonald's BLT's. The attitude control system consists of magnets which tend to align the Z axis, a solar windmill which tends to spin the satellite faster and faster, and lossy hysteresis rods which regulate the spin rate by dissipating energy. The photovoltaic panels generate an orbit average of about 8 watts, and the battery pack levels the voltage over the orbit. The satellites were originally supposed to be stamped out like cookies from a cookie cutter, but it didn't work out that way. Every satellite was different in some way. A slide of WEBERSAT OSCAR-18 shows the penthouse (or attic, depending on who you ask) containing a Canon CCD-based video camera. The camera experiment samples the NTSC output from the hardened stock camera assembly. This permits color to be recovered from the sampled image. For example, Franklin Antonio, N6NKF, has written a program that extracts good quality color images from WEBERSAT pictures. Unfortunately, no good pictures have been taken since WO-18 was launched. A picture of DOVE OSCAR-17 is dominated by Junior De Castro, PY2BJO, a major benefactor of the Microsat program. DOVE transmits on 2 meters FM through its outsize downlink antennas. The primary mission is a digital voice encoder intended for educational uses. A picture of a partially assembled Microsat illustrates the stacked slice chassis concept. Another picture shows the wiring harness: a simple 25-pin ribbon cable. Various analog voltages from telemetry points are multiplexed onto just one of the wires, under the control of a serial local-area-network that logically interconnects the stacked modules. A picture of the AMSAT lab shows key workers Jan King and Jeff Zerr. Many other credits for work on design, flight integration, and software were recounted. A picture of preparations for thermal vacuum test illustrates the kind of special resources that can be obtained through connections. Some of the leading enthusiasts have been "doing satellites" since 1970, and in the meantime they have risen to positions of authority in their companies. Having a company bigwig fetching and toting cables makes a big impression on the other employees; this makes it easier to get cooperation from them! A picture of a Microsat with the hood open shows that the modular stacksat concept makes it relatively easy to service. (At least, that's the theory. -Ed.) A picture of UoSAT OSCAR-14 provides a contrast. It weighs 60 kg, about twice as big as a Microsat. The wiring harness contains more than 400 wires. It does contain more redundant subsystems than a Microsat; the Microsat strategy was to have redundancy through multiple independent satellites. More pictures: UoSAT OSCAR-15, which failed shortly after launch and hasn't been heard from since. The Microsat/UoSAT deployment mechanism: a spring, compressed with a bolt. The huge crowd of quality control people it takes to supervise the operation of tightening four bolts to mount a Microsat to the ASAP. Cleanroom equipment: just home PC's, and donated gear from Kenwood, Icom, MFJ, and TAPR. NK6K attaching the umbilical cord to a Microsat, for charging and monitoring on the ASAP. A spider found in the cleanroom. SPOT-2, the primary payload. SPOT-2 and the Microsats mounted for launch - boy is SPOT-2 big compared to the Microsats! The pacsat mission was written up in an interview published in the May 1984 issue of Byte. The original plan was a user interface similar to the familiar W0RLI-style BBS software. Later it was realized that an interface that permitted and encouraged off-line typing and automatic forwarding would be better; humans type too slowly. With a satellite audible to large areas simultaneously, it makes sense to implement a broadcast protocol that permits listeners to reconstruct transmitted files. This protocol is currently in use for AMSAT News Service bulletins, Keplerian element sets, and so forth. For non-broadcast messages, the goal was automatic store-and-forward operation. But it wouldn't do to put the routing intelligence in the spacecraft -- spacecraft software is hard to write, and forwarding schemes change all the time. So the satellite acts as a file server. The satellite software requires a special header on each file, which contains a description of the file's contents. One field of the file header contains a free-form routing designator. The BBS software can use the routing scheme du jour to decide which files to download and forward. Question: What equipment is needed to work the Microsats? Answer: 70cm SSB receiver, 2m FM transmitter, PSK modem. PSK was chosen for reasons of efficiency. Software for ground station use is available via CompuServe, TAPR, and others. The spacecraft can also be used as a simple digipeater for realtime QSOs. Question: What is the life expectancy of the Microsats? Answer: The orbit lifetime is estimated at 107 years. Radiation damage may become a problem after 3 to 7 years. The NiCd batteries have a relatively easy life, and are expected to last a long time. UOSAT OSCAR-11 celebrated its 7th birthday yesterday with the same batteries, and is going strong. Question: Do you still plan to implement the part of the broadcast protocol that permits ground stations to request fills for missed parts of a file? Answer: Yes. Question: What kind of NiCd batteries are used, and how are they managed? Answer: The charge level is managed by varying the transmitter power. The batteries are purchased commercially for $15 each, x-rayed, temperature tested, and grouped into sets matched for charge and discharge rates. From 200 batteries, 6 sets of 8 matched cells were obtained. Compare with the manufacturer-qualified price: $700 each. ======================= Lyle Johnson, WA7GXD, reading a letter from Tom Clark, W3IWI -- SAREX About 90% of the logs from WA4SIR's operation on the space shuttle have been processed. They amounted to 400K of data plus 4 inches of paper listings. The QSL cards will be ready soon; the Goddard ARC will distribute them. 238 "gold star" 2-way QSOs were logged by the GRiD laptop computer aboard the shuttle. 800 "silver star" QSLs will be awarded for stations heard by WA4SIR and awarded one of the 1700 QSO numbers. The QSO rate averaged about 20 per hour, peaking at 30 or 40 per hour. USA stations were greatly disadvantaged by interference, and by failure to run low modulation. 35 countries were logged, but no European stations were logged except a few SWL reports. It required over 200 pages of documentation to get authorization to carry the SAREX equipment on the flight. ==================== Bob Nielsen, W6SWE, described a message from Jerry Crawford. A company called Hadron (spelling?) has a packet radio controller product, the PRC6064A, which is based on licensed TAPR technology. These devices are being used by special forces in Operation Desert Storm. Al Dennis, who has some connection to the Department of Defense, spoke up about DoD use of amateur packet equipment. They've been using it since we started. It is used for man-carried single-threaded narrowband links. The packet controllers work naturally with the laptop computers and digital radios they already have in the field. The 18th Airborne Corps has been building up applications. Amateur-like packet is a de facto standard, because it's cheap and give interoperability. Packet is used both point-to-point and in networks. For logistic information transmission, packet replaces Jeep shuttles. Networking is coming, and interfaces to the DDN. They want to extend the DDN right into the jeeps in the field. Question: Are you aware of tactical front-line use of amateur packet gear in Desert Storm? Answer: Yes! It is being used between camps in the desert. Then as the frontline troops advance, they outrun the logistics people - and use the packet thin-links to keep in touch. Question: Can you *please* give this talk to the FCC? Answer: Not sure we can get involved. We did push for reciprocal licensing with Persian Gulf states. Question: Regulatory issues are getting to be a problem. Pointing out the benefits of amateur radio may help keep the regulators from getting out of control. Answer: We don't normally deal with the FCC, but I'll do what I can. Question: Does the enemy have any trace of this kind of capability? Answer: No specifics, but note that TNC-2's are available world-wide, and so are smart people. NK6K: Note that they aren't using the TNC-2's modem through a voice radio like we do. They connect digitally, through a Crypto unit. So the communications wouldn't be easy to monitor. Question: How well does it perform? It's not really optimized for this kind of work. Answer: It works well. Better than the other stuff they have. The amateur packet gear is the only error-correcting protocol they have that works on half-duplex radios. They even use it on UHF satellite links, which have just a few poor-quality channels available. NK6K: We have a cheap satellite design you might be interested in ... Answer: We're very interested, and we've had proposals for years, but haven't gotten very far. ============================== Lyle Johnson, WA7GXD --- TAPR/AMSAT DSP Project TAPR and AMSAT undertook a joint project, spearheaded by N4HY and W3IWI. The idea was to handle the proliferation of different modems for use on HF, Microsats, RUDAK, and so on. By digitizing the analog signals, a high-speed processor can be used to simulate filter, PLLs, and other modem components. When the next new modem is needed, all that's required is a new program for the DSP board - it's only bits. The original efforts used the Dalanco-Spry Modem 10, a PC plug-in board based on the TMS32010 first-generation DSP processor from Texas Instruments. In 1988, the DSP project proposed a standalone box with a TMS32015 (a slightly improved TMS32010), 4k words of 70ns memory, 8-bit analog I/O, provisions for a second DSP board in case extra horsepower is required, power supply, and V40-based controller board, all plugged into a back panel interface board. Boards were layed out, and some prototypes were built. Then the Microsat project got under way, and key project personnel were suddenly very busy. In January 1989, after the Microsat launch, the hardware team was freed up. The DSP project was revived at the 1990 TAPR meeting. After a few months, a new design evolved: a PC plug-in board, based on a newer TMS320C25 processor. By using a PC plug-in, the project can take advantage of cheap IBM PC development platforms, at least for the initial version. This is great except for Japan, where the popular PCs don't have the IBM PC bus. The TMS320C25 is much more capable than the TMS32010 or TMS32015. It was too expensive when the project started, but now there is a version in the high $20's range. The radio interface is still 8 bits wide. This gives about 40dB useful dynamic range. This is thought to be enough; the beta test will tell. Miscellaneous I/O like up/down tuning buttons are provided for. A sample clock phase-shifting circuit makes it possible to use lower sample rates. A watchdog timer is included. The DSP board has no ROM; it is booted from the PC. It takes up just 16 addresses from the PC's I/O space, and no memory addresses at all. The PC can access DSP memory without disturbing the DSP processor, by inserting just 1 wait state per access. An 8530 serial communications chip is included on the DSP board so it can handle the TNC functions easily. It should be especially easy to interface to the KA9Q TCP/IP software, since that software already supports the 8530. A 6-layer beta test board was displayed. It's fully functional, with just a few white wires. The 4th of a planned 10 beta test boards is currently under construction. The beta test goal is to get some applications running to verify the applicability of the hardware. Then the production phase will begin. There was a discussion in the TAPR Board meeting about whether the DSP board should be sold as a kit or fully assembled, or something in between. Construction of the DSP board requires 10 to 20 hours of careful work with a suitable temperature-controlled soldering iron. Beta test results will indicate if a kit is practical. A quick poll of the audience indicated that many people would be interested in a kit. Most of those liked the idea of having the soldering done for them, even if the soldered boards were untested. It has been claimed that assembled and tested boards would only cost $35 to $50 more. A poll showed that nobody would be interested in building the kit if the A&T version only cost $50 more. Question: When can I buy one? Answer: Depends on how the beta test goes. Definitely not by Dayton this year, but very confidently before Dayton 92. Question: What software will be included? Answer: We intend to provide a monitor/debugger, assembler, and applications, hopefully including source code. The intention is to provide the tools required for code hackers, AND at least a minimal set of modems and packet applications for operators. One member of the software team is into images, so expect an SSTV application. Another member proposes to create a spectrum analyzer. Question: How much compatibility will there be between this board and the other platforms announced by vendors? Answer: Not much. There are significant differences, such as a different DSP processor. The algorithms will be the same, but the code will have to be rewritten. There is a European group that has a small board based on the DSP56001 used by the other vendors; they have implemented a bit-banging HDLC driver on the DSP chip. Question: I want to plug in my scanner and receive 9600 bps broadcasts. How do I get this done by a certain date? Answer: mumble mumble. Question: What baud rates will the DSP board be able to support? Answer: It should be able to handle FSK up to 9600 bps with no problem. Nobody's quite sure if it'll handle something fancy like a V.29 modem at 9600 bps. Comment: Telebit Trailblazers use this processor, and they do V.29. Question: Can the board be sped up? Answer: Yes. It's designed to go 40 MHz. You just need to plug in faster parts. The limit will probably be the PALs, which need to be 7ns parts to go 40MHz. N3EUA: With faster DSP you may be able to get a 2X speedup, but you'll never get another order of magnitude speedup. You have to choose a performance class and build the best solution for that class. Question: What range of sampling rates can it handle? Answer: Up to about 400 kHz. A fast sample rate like this is useful for non-modem applications, like spectrum analyzers. That was one reason for choosing 8-bit I/O instead of more precise, slower converters. Question: How much power does it require? Answer: No measurements have been made yet, but only two chips on the board get noticeably warm. Guess: less that 5 watts. Question: Other than DSP software gurus, are volunteers needed to help with the DSP project. Answer: No. At this point the crowd got a much-needed 10-minute break. ========================== Dave Toth, VE3GYQ -- BBS Issues Recent FCC citations (involving a bulletin soliciting support for a political group via a 900 telephone number) have led to a high level of paranoia among BBS sysops. Message traffic may be delayed. Many sysops are killing or at least screening bulletin traffic. The HF forwarding network doesn't handle bulletins anyway, so there is little effect there. 20 meters carries most of the load, followed by 30 meters. 15, 10, and 40 also carry some. All channels are essentially saturated. Retiring BBS stations are not being replaced, in hopes of limiting contention. VHF paths are being substituted where possible, for example between VE3GYQ and W3IWI. 8 to 10 BBS stations per channel might be a reasonable target. Meanwhile, BBS software developers are working on adding compression of forwarded message data. Some standardization is needed. W0RLI is proposing LHARC, sent in binary form through the G8BPQ software interface. Question: Is forwarding run on a schedule, with beams pointed at the target station? Answer: Not really. The antenna is usually left fixed at a compromise heading. This is workable since each station only tries to forward to a few specific destinations. Forwarding times are theoretically slotted, but typically BBSs overrun their forwarding slots. Question (self-asked): Have things changed in the last year? Answer: More system are running multiple connections via the G8BPQ software. Question: Some people seem to agree with the FCC that the content of bulletins is out of control. What do sysops thing? Answer: I hold ALLBBS and AMSAT message for manual review. I'm not impressed by the intelligence level exhibited by message posters OR by sysops, and I sympathize with complaints about the noise level on ALLBBS. But I think the issue should be handled within the BBS community. Local sysops should take some control. It's worth noting that the originator of the 900-number message was a repeat offender. ============================ Dewayne Hendricks, WA8DZP - Packet in Northern California The Northern California Packet Association (NCPA) will host the next Computer Networking Conference, September 27-28, 1991, somewhere in Silicon Valley. There were complaints about the format at the last Conference in London, so format changes (undetermined) are planned. NCPA was formed 3 years ago to control frequency wars. It is an umbrella organization over northern CA packet groups. It is tasked with frequency coordination, and is recognized as packet frequency coordinator by NARC, the repeater coordinator for that area. There are currently no high-speed (>1200 bps) links in regular use in northern CA. This has been tolerable because of the organization imposed on the network by NCPA. Frequencies are allocated for higher speed, but everything is operating at 1200 bps. Nationally, NCPA serves as an educational and information distribution service. It publishes a very nice quarterly newsletter. Expect to see more publications from NCPA. The newsletter is available for $10/year. Question: What exactly do you mean by "coordination"? Answer: Exactly the same thing meant by "coordination" of repeaters. So far we've had no disputes that weren't resolved. ======================== Paul Newland, AD7I - METCON project Packet is an ideal way to transmit low-tech telemetry data. He has developed a simple telemetry monitor program for an 8051 microcontroller. A block diagram shows the 8751 microcontroller (with lots of goodies all integrated onto the microcontroller chip), up to 6 relay outputs, and current loop inputs for switch closures or outboard voltage-to-frequency (VTF) converters for measuring analog voltages. A multiplexer selects from several VTF inputs. The VTF approach was chosen because it is less susceptible to noise, and can be opto-isolated if necessary. A serial EEPROM is provided to store default values or passwords. There's support for a conventional 8-channel A/D converter. An RS-232 port connects the board to a TNC for remote control and sensing. The TNC can automatically collect periodic sensor readings, and can transmit a message when a reading changes. There's a line oriented command structure by which the remote user can control the board. TAPR has adopted the METCON board as an official project. Pete Eaton is in charge of the development group. Lyle Johnson and Paul Newland on hardware. Kits just might be available by Dayton. Source code for the software is expected to be available, even though that will weaken the user authentication scheme and possibly embarrass Paul by revealing his coding style to the world. New software is welcome. A prototype METCON board was shown around. A prototype VTF board was also shown. The VTF board can measure temperature directly with the addition of two components. The A/D board is not done yet. A power manager board for battery-powered sites is under consideration. Another possible improvement would be to switch to a Signetics version of the 8051 with more I/O and more code space. Question: would the Signetics part be code-compatible? Answer: Yes. Question: What temperature range? Answer: The device will operate over the commercial temperature range, -20 to +85C. The sensor range is -50 to +70 or +80 C. Question: Does it fit inside a TNC? Answer: No. But it does run on 12VDC, 100 to 150 ma. The device can be used for a remote weather station, or as a very elaborate repeater control system. If everybody used it for repeater control, every repeater control link could be on the same frequency! At this point, everybody adjourned to the Garden Room for lunch (except a few who can't eat rye bread). =================================== After lunch, videotape clips from the early years of packet radio (1982 to 1984) were shown. Chuck Green, N0ADI, is shown giving a talk describing an early version of the packet protocol. It featured single- byte station addresses with a couple of bits reserved, for a maximum of 64 stations in an area. There was going to be a network control station that dynamically allocated addresses to stations entering the network. The control station would periodically broadcast the mapping from network address to station callsign. CW ID was required in those days, and there was a scheme to reduce the network overhead by having every station transmit their CW IDs simultaneously. Another video clip showed Lyle Johnson, WA7GXD, describing the rationale for the TAPR TNC (now known as the TNC-1). Compared to the existing Vancouver VADCG TNC, it was designed to be cheaper, easier to use, and more operator-oriented. Power supply and modem were on-board, and a transmitter watchdog was provided. An alpha-test TNC was shown transmitting a packet. This was a 6502-based board running a FORTH system. A third video clip discussed the possible applications of packet radio. Sharing an expensive computer resource (like, say, a TRS-80 Model I) was an important potential application. HF operations at 300 bps and 10 meter operation at 1200 bps were mentioned. AMTOR was proposed as a possible linking mechanism for poor HF paths. Packet operations via satellite, possibly even by portable stations, were envisioned. And an exciting blue-sky possibility was described: linking together different areas using VHF links. One last video clip was a cautionary piece about computer viruses, that looked and sounded like something produced by the Civil Defense authorities during the '50s. ============================ Lyle Johnson, WA7GXD, presented a plaque to Harold Price, NK6K, for his contributions to packet radio since 1982. In accepting the award, NK6K said that he sees himself as a link between the experimenters on the forefront of technology and the users of the technology. ============================ Jon Bloom, KE3Z -- League issues As an aside, Jon started by mentioning that NK6K's QST article entitled "What's All This Racket About Packet?" is always held up as an example of the kind of explanatory article that QST needs. There has been little progress on the proposed version 2.1 of the AX.25 Level 2 protocol spec. The update is still waiting for the specification in "state description language" to be completed. At the Computer Networking Conference in Colorado Springs in 1989, the community agreed that there was a need for work on HF packet: modems, protocols, diversity reception, and spectrum management. A grant from FEMA was obtained to work on some of these issues. The terms of the grant included a provision that the government would own any intellectual property that arose from the research, and this discouraged people from working under the grant. Since then, FEMA has relented, and participants in the program will now retain all intellectual property rights. $9500 is available for HF experiments; proposals may be submitted informally to Paul Rinaldo or Jon Bloom at HQ. One possibility is to develop a new protocol for HF work, being something like a hybrid of AMTOR and AX.25. CCIR study group 8 (amateur and maritime) could be approached to make a new protocol a CCIR Recommendation. The FCC citations against BBS sysops for relaying a message with apparent commercial content has received a lot of attention, which seems to have been what the FCC wanted. It is hoped and expected that these particular people will escape any fines. ARRL believes the FCC is taking an inconsistent position. FCC has stated officially that every station is responsible for the content of all traffic passing through it. But in the automatic control docket, FCC acknowledged that it is impossible to screen all the traffic. FCC seems to be resolving the conflict in favor of full responsibility for all stations. Perhaps they would relent if we could provide an audit trail by which the originating station alone could be held responsible. Notice the implicit double standard, as compared to voice repeaters. Of course, if it came down to it the FCC could decide that voice repeater operators are responsible for content as well. Or, they can maintain a double standard if they wish. Question: there are technical solutions, involving authentication schemes. Answer: the FCC just wants somebody to be responsible, and they want the amateur community to solve the problem. How we solve it is up to us, as long as we can convince the FCC that we have solved it. Question: No matter what we do, we won't be able to stop infractions before or even while they happen. Answer: We can avoid that problem by finding a way to hold the originating station responsible. Question: How is the audit trail in the BBS headers, apparently used by the FCC to write citations, any better evidence than the old tape recordings and DF fixes that the FCC has always refused to accept for prosecution? Question: It looks like an overzealous engineer-in-charge got carried away on this one. Answer: Maybe so, but the issue would have come up sooner or later. The head of the Private Radio Bureau intends to come out with a policy statement or rulemaking on this subject. We have some opportunity to influence this process if we act now. Question: Does this mean that the FCC no longer considers a callsign to be meaningful? Answer: There is no ARRL position on this. KE3Z's opinion is that the callsign is useful in enforcement, but is not sufficient evidence of guilt. Question: Is this a one-time problem? Answer: This case was just a catalyst. Question: It's time to relicense the Microsats under some other country's authority. NK6K: It's not clear that that is possible. Even if it were, it would make it very difficult to get the next satellite license. Also, most other countries have worse rules, not better. KE3Z: On the other hand, the US is the only country that defines 3rd party traffic to include ham-to-ham relay traffic. Comment: The UK prohibits ALL 3rd party traffic. KE3Z: It is in our best interest to prevent intruders using the network. We want some control over who uses the network for what purposes. Question: How does this differ from some ham dialing up a 976 number on an autopatch and ... Question: How much time will the FCC give us to resolve this issue? Answer: If we are visibly trying to implement a technical solution, we can probably have whatever time we need. If we're planning to stonewall, the deadline may be late summer or early autumn. Question: If we come up with a solution, who will tell the FCC? Answer: Everybody. I don't know. ARRL will certainly be working on the problem. W6SWE: TAPR has set up a committee to study the problem. KE3Z: TAPR should contact Dave Sumner at HQ to coordinate efforts. Question: Can we just ask the FCC to give us a ROM with a coded password in it? Answer: Yes, but they won't do it. They don't see this as a problem: they can just continue the current policy and cite us for violations. Notice that the FCC doesn't see any distinction between ALLBBS and any other transmission. Question: What about the issue of the right to due process? Answer: The cited stations have that right. There is an appeal procedure. Everyone who was cited is believed to have filed an appeal. NK6K: We have to look beyond the details of this case. Their easiest defense is that the network audit trail doesn't prove they did it. That claim contradicts our claim that the network is a "pipe" and can be treated as such. This is a very dangerous regulatory position. Question: How long ago was version 2.1 of AX.25 first discussed? Answer: Uh... about three years ago? Question: Why do we need to change the protocol? Answer: There were various issues; channel access was one. Question: Maybe we should just disband the committee. Answer: Getting protocols down on paper has always been slow work. Question: What is the status of the HF unattended operation proposal? Answer: I'm not aware of any proposal. The STA was extended again to run through the end of this year. It'd probably be a good idea to get this whole issue resolved before the STA comes up for renewal again. Question: There have been complaints from RTTY operators on 20 meters that packet BBS stations are encroaching on RTTY frequencies. Some claim it's a conspiracy by the STA operators. VE3GYQ: It's not STA operators, but there has been some encroachment. ============================ Mel Whitten, K0PFX - Radios for 9600 bps Operation Hams in Missouri are trying to build a 9600 bps network on 440 MHz. They obtained a number of Mitrek radios from a water company. They initially looked good for data, but experience shows that they are too narrow-banded for data. Widening the IF (following Mike Schroeder's article) has been a struggle, but it helped somewhat. Three links are up and running now, giving about 2400 bps thruput. These are 30-mile links; 5 to 6 mile links work a bit better. A company called TEKK makes a very small 2-watt data transceiver that seems ideal for this application. They currently come for commercial frequencies around 461 MHz, but a ham band version is possible. With G3RUH modems, interfacing is easy and bit error rate tests give good results. They run all day without retries. Mike Chepponis, K3MC, has moved a couple of the commercial-band TEKK radios into the amateur band. ======================== Dewayne Hendricks, WA8DZP - K3MC proxy report One of the TEKK radios, mounted in a chassis with a Kantronics G3RUH modem, was passed around. The TEKK radio costs only $150 in single unit quantities! The radio is tiny. Recovery time less than 8ms. Sensitivity 0.3 microvolts for 12dB SINAD. Crystal controlled, single channel. He is also working with K3MC on 900 MHz Part 15 spread spectrum devices. A tiny 121kbps 1W 900MHz data transceiver was passed around. It costs about $150. There was a session on wireless networking at the recent Hacker's Conference. They discussed the new no-code amateur license, but weren't very excited about it: the content restrictions imposed on the amateur service are too onerous. They'd rather stick with the Part 15 devices, which may be used to transmit any kind of messages. Most of the commercial units are direct sequence spread spectrum. One recent unit is frequency hopped instead. Chips sets are becoming available for spread spectrum. More information will be presented at the next Computer Networking Conference. K3MC has left Apple Computer. Apple Computer filed a petition with the FCC a month ago, seeking to create a personal data communications service. The comments deadline is March 11. They don't think Part 15 devices are suitable. They want 1 watt, 1 Mbps, at 1.8 GHz. They want some different tradeoffs between power and antenna directionality. They propose a phase-in of frequencies. The IEEE has formed a committee for wireless LAN issues. WA8DZP (and soon K3MC) is a member of the committee. ========================== Chuck Green, N0ADI - TAPR Production Did you ever wonder about how all the parts in your TAPR kits got there? N0ADI's wife does all the kitting. His spare room (which was going to be the hamshack...) is the TAPR warehouse. In the early days of the TNC2, the warehouse took over the family room and part of the living room, as well. 2700 TNC-1 kits and 1200 TNC-2 kits were packaged, and countless smaller kits. 2500 kits, all small, were shipped last year. Question: How many K9NG modems? Answer: A few hundred. When a production run ends, TAPR retains a quantity of spare parts. If you need a spare part, they probably have it. Full kits of parts for boards are not available, though. N0ADI also has possession of a computer owned by TAPR for PC board layout using ProCAD software. It was on display in the meeting room, with the very complex layout of the DSP board on the screen. The DSP board holds 67 ICs. Notice that the bottom rear corner of the board is shaved off to permit insertion from the top of the PC chassis. Question: How many hours did it take to lay out the DSP-1? Answer: A couple hundred. Question: We have 8 K9NG modems unbuilt; can we get kits of parts without boards to fill them? Answer: The theory was that the parts not included in the partial kit were easy to obtain. So no, we don't plan to issue a parts-only kit. ========================= Don Lemley, N4PCR - the PackeTen Switch [Editor's Note - this talk contained a lot of detail given at lightning speed. I couldn't begin to write it all down. The following is some of what I did catch.] Why the PackeTen switch? Overloaded networks. Advanced applications are not practical at the low bandwidths currently available. There were political problems. He decided to focus on the digital side of the problem, since that is where his expertise lies. He wanted to provide an off-the-shelf solution that would support the fastest modems and radios available, up to 56 kbps, and future platforms to 1 Mbps. It provides backwards compatibility to the existing users. And at lower cost than the usual configuration of many TNCs. The PackeTen features a MC68302 special-purpose processor running at 16 or 20 MHz. 3 high-speed synchronous or asynchronous channels, with an aggregate thruput of 2 Mbps. Clocking is software configurable. EEPROM memory stores configuration info. CMOS is used for low power. 2 megabytes each of RAM and ROM can be installed. The card comes in two versions: standalone and PC plugin. The PC plugin card has a very fast dualport memory interface to the PC. It can use an 8 or 16-bit interface to the PC bus. The PackeTen runs a customized version of the KA9Q NOS networking software ("NOSINABOX"). This version supports NET/ROM for backwards compatibility with NET/ROM networks and users. And of course, TCP/IP users can use its more sophisticated features. Pictures of the Chicago area network before and after upgrades using the PackeTen were shown. After the upgrade, the network had fewer nodes, was more organized, and supported higher data rates. Question: What's the name and address of the company? Answer: Catch me after the meeting. Question: If the Chicago group was like most, the original network resources were owned by a variety of clubs and individuals. How did you deal with this when upgrading the network? Answer: The IP users group put together the funds to build the new network. When it was up and working better than the old network, the other stuff just faded away and the users switched to the new network. Question: Does the Chicago network use the PC plugin card or the standalone version? Answer: Both. The PC version is used in the nameserver, and the standalone version is used in the switches. Question: Does the diskless node require a custom BIOS, or what? Answer: NOSINABOX takes care of all that. Question: What frequency is all this networking done on? Answer: 70 cm. Question: What's the price? Answer: $700 for the standalone version, $800 for the PC version. Question: What's this 4800 bps landline link shown in your diagram? Answer: That's really a 1.2 GHz link to a tower that hosts the wormhole to California. ========================== Bdale Garbee, N3EUA - Colorado report Welcome to ex-members of the former Rocky Mountain Packet Radio Association. As RMPRA disbanded, a group of new faces formed COPA, the Colorado Packet Association. Bdale ended up chairman of the Technical Standards Committee of COPA. The network just didn't work. Now they are focussing on east-west linking across the mountains, instead of the former emphasis on north-south linking along the front range. A new backbone is planned for this summer. The current network works so poorly that backwards compatibility isn't much of an issue. Lack of organization has been a problem. Not everyone understands the distinction between an occasional path and a reliable path. Many of the paths currently in use rely on knife-edge propagation, which is not suitable for high-speed data links. Site selection and service goals were the main issues. It was necessary to use point-to-point line-of-sight links of less than 50 miles. 300-mile links between 14000 foot peaks were the wrong answer. The plan is to put 10GHz links at 6 nodes, arranged in a linear backbone. With two backbone links and two user access ports at each node, they needed 4-port controllers. Given that, the cost differential between the usual low-performance multi-TNC implementation and the PackeTen was small. They bought 3 PackeTen standalone units, with 3 more to be obtained soon. A working group is trying to make the 10 GHz 1 Mbps modems designed by N6GN and others mountainworthy. They want to make use of full duplex to conquer the hidden terminal problem that tall mountains produce. They have permission for a duplex machine on Pikes Peak. A crossband duplex machine is already in operation near N3EUA. It is hoped that by the time of the Computer Networking Conference, bare PCBs or perhaps even kits will be available. They are still investigating interface issues for 10 GHz modems. The current theory is to add the circuitry to the modem, so they can be connected directly to the PackeTen. There is some thought of varying the data rate as conditions change. =========================== Phil Anderson, W0XI - Kantronics Last year, the market was depressed, but since September volume has been up surprisingly. Commercial customers are buying TNCs for HF and VHF, and even some 2400 bps QPSK units. Amoco and Tennessee Gas are using TNCs for sending data to operators in mobile units. The latest product from Kantronics is the TelemetryUnit. A front panel was passed around. The TU hooks up between instruments and a TNC to relay telemetry. It features screw terminals on the back panel to ease field installation. Firmware is available that supports an anemometer, wind direction sensor, ratiometric A/D converter, temperature sensor, and rain gauge. They're still looking for a suitable pressure sensor. This firmware gives a text-based human interface on the data port. The operator specifies the sample rate, and it automatically collects the data. You then ask it for a report, and it dumps the data to you. Sampling everything every 5 minutes, there's room for a few days info. Sampling just temperature every 30 minutes, it'll go a year before it fills up. Another firmware version is available that provides a general units-translation feature, with user-specified units. Kantronics is developing the D4-10 data transceiver. They will be seeking FCC Part 15 approval soon. It has microphone, analog data, and digital data interfaces. Two channels, crystal controlled. They have some tricks to make TX/RX switching fast. The receiver filtration scheme and major parts choices were discussed. The built-in slicer can tolerate up to 4 kHz of frequency error. Spectrum analyzer displays for various tests were shown. They hope to have the D4-10 available by Dayton. Pricing is not yet determined, but it will probably be around $300. Question: Do commercial band users have trouble getting licensed to use data transmission on shared voice channels? Answer: We've found that most 2-way radio shops don't understand data. They estimate that 50 shops in the country can really handle it. On a shared voice repeater, data is secondary to voice. There is some movement toward data in trunked SMR. Nobody seems to know where the data market is. There's more data on HF, in ship-to-shore, governmental, and utility applications. Question: What about public safety services? Answer: Riverside County, CA is very enthusiastic about data communications. But each user needs custom software, and that's not practical. For example, Amoco cut its 30-man communications staff to 2 after the oil embargo. In that kind of situation, companies need turnkey solutions. Question: Have you tested against radar QRM? Answer: No. The radio was tested in Chicago. Pagers have been something of a problem. In an earlier model, aircraft frequencies fell on an IF image and caused problems. ============================ Gwyn Ready, W1BEL -- PacComm PacComm's EM-NB96 9600 bps data communications line is growing. The modem has a new feature: the modem disconnect is brought out so that other modems can be chained onto the same TNC. The NB96 modem can be connected directly to the TEKK radio; PacComm worked with TEKK as a beta tester for data applications. They work very well on good RF paths. In commercial service, they specify the modems to work with a path of a certain quieting, and the user can't complain if they don't work on crummy links. The TEKK radio *will* be available on amateur frequencies. They'll be tunable from 420 to 440 MHz, crystal controlled. Some should be available at Dayton. They're looking for input as to what frequencies should be made available. The TINY-2 PLUS is an add-in board for the TINY-2 TNC. It's aimed at experimenters, with other features intended to encourage volume sales. It has open squelch DCD, a hardware clock, room for 512K of extra RAM, and 3 extra EPROM sockets. The ROMs can be selected by software. You can put RAM in the EPROM sockets and download code to it. The serial ports have LEDs for debugging. A mini-BBS and remote commanding are supported by the standard firmware. A monitor EPROM is available. The add-in board draws about 40 ma. There's also a smaller, cheaper add-in board that just expands the memory. It plugs into the Z80 socket, and gives 128K of RAM expansion. One of the first PacComm HandiPacket TNCs was recently delivered to the Soviet space station Mir. There seems to be a bit of a problem with user training; the cosmonauts don't understand all of the features. =============================== TAPR Annual Business Meeting President Bob Nielsen, W6SWE, called the TAPR Annual Meeting to order at 4:23 PM. He introduced the new board members and officers. Bob Hansen, N2GDE, is the new editor of PSR. Greg Jones, WD5IVD, is now the manager of the packetRadio project. Boards have been prototyped and debugged, but still need some work. No date is promised. A more complete report is expected later this year. The METCON and DSP projects were discussed in the board meeting. A Guide to Operating Packet is to be published in time for sales at Dayton. The packet video featuring Pete Eaton, WB9FLW, is to be updated this year. A Committee to develop a TAPR position on the current regulatory issues was appointed: NK6K, N3EUA, VE3GYQ. METCON is the only new project that was officially adopted, but some other ideas are cooking in the back room. New ideas and project proposals are solicited; you don't need to be a member of the inner circle (or even a member of TAPR) to propose a project. Prices for software and kits will probably be increased before Dayton. Greg Jones, WD5IVD, gave the financial report. Total assets are around $103,000. Revenue this year was about $79,000, mostly from the sales of small kits. OEM licensing revenues from TNC-2 sales have all expired. The membership has increased from 700 to 1200 members. This year's net is $2000. Quite a bit was spent on R&D. Question: What liabilities are there? Answer: The liabilities sheet was shown. One liability is a member services reserve. This reserve covers the cost of quarterly PSRs for the duration of all paid-up memberships, so that the Board can't spend the money that's already promised to members. In August, the bookkeeping switched to a new, more automated service in Austin, TX. The new arrangement gives more services for the same price. Question: Do dues cover costs? Answer: About 80% of dues pays for PSR. The rest depends on what assumptions you make about how Heather's time is spent. NK6K: Notice that there are no engineering salaries in the budget. We only pay for services that engineers won't do. Question: Why are Board meetings closed? Maybe a Member At Large would be a good idea. Answer (NK6K): Some issues are too volatile to discuss in a large group. Some Board members think the Board is too large anyway. Board meetings aren't usually officially closed, but sometimes they have to be. N3EUA: Note that the Board does meeting continuously via Compu$erve. You can bring issues or proposals before the Board at any time of year. Question (joking): Where the Version 4.0 of the TNC-1 software? Answer (NK6K): Nowhere. The meeting was adjourned - dinner ensued. ========================== Steve Hall, WM6P -- HF Diversity Reception Experiments with diversity reception for HF packet have been carried out. The scheme used two separate antennas, receivers, and modems. Software provided by Kantronics was used to keep statistics on packets copied by both TNCs and packets copied by one but not the other. The receivers were mostly listening to the 20 meter BBS forwarding channel. This provided a variety of locations, signal strengths, and angles of arrival. The results were surprisingly consistent: A second receiver gave about 50% improvement in packets received. For instance, if the A channel receives 4000 packets correctly, typically the B channel would receive an additional 2000 packets that A didn't copy. This performance level was largely independent of the quality of equipment used on the B channel. Even relatively inferior equipment (R390 and R388 surplus receivers with random wire antennas) provided about 50% additional packets, even when relatively first-class equipment (TS940S receiver on a monoband beam) was used on the first channel. The results were also largely independent of the antenna configuration used. The only pair of antennas that didn't exhibit good diversity was a pair of horizontal dipoles at right angles with colocated feedpoints. Parallel dipoles spaced a half wave apart gave good results. Comparative tests were difficult, since ionospheric conditions changed performance more radically that antenna selection. In light fading, diversity improvement fell to about 20% additional packets. When fading was heavy, diversity improvement was larger, since the two channels tend to fade independently. Another test configuration using a dual-port DRSI PC*PA board with software provided by Andy DiMartini gave similar results. So far, the diversity combining tests have been a laboratory curiosity. The next step is to make a combiner box that will allow two TNCs to handshake and do diversity receiving automagically. He has talked to manufacturers, with lukewarm results. Jon Bloom, KE3Z, is interested, and they plan to move ahead with a prototype that will interconnect two KISS TNCs. Question: What spatial separation was required to get space diversity? Answer: A half wave gave nearly full diversity. Question: When you watched the S meters on the two receivers, did you observe fading that was too fast for packet-level combining to cover? Answer: Yes, there was some fast fading. It was hard to sort out the effects of collisions from those of fading. We tried some tests with a lower baud rate (100 bps), which seemed to indicate that the long packet durations overwhelmed any advantage. Question: Did you try diversity combining using analog voting? Answer: No. That scheme would assume that the stronger packet is the good one. Observations show that sometimes it's the weaker one that (a) can be demodulated successfully and (b) is the packet you want. Question: Did you try polarization diversity? Answer: Yes. But with the ionosphere changing faster than the antenna configurations, it was hard to draw any conclusions. Question: In the old RTTY days, we sometimes ran two receivers with a common AGC so that the strong signal would overwhelm a weaker one. Answer: Again, that would assume that strong equals good. I didn't do it that way. Question: What packet length was used? Answer: All lengths. Whatever was on the channel. Question: This would work better with shorter packets, wouldn't it? Answer: It seemed to work OK with random lengths. Question: Did you ever see better than 50% improvement? Answer: Yes, we saw 60% sometimes. But there were also times when there was little fading, and both receivers were copying nearly every packet. Question: How many packets were missed? Answer: Many packets were lost to collisions. Sometimes one channel would see a collision, but the other channel would copy one of the packets. Tests were run near the MUF and well below it. It didn't seem to matter. Question: Will the results be published? Answer: Yes, in some ARRL publication or other. Question: A local company, Dovetron, has done diversity work. Your results correlate with their claims. This technique has been around a long time for RTTY. Answer: Yes, I did play with RTTY some. It worked there as well. Also on AMTOR. Not discarding entire packets gave better improvements, but it required human intelligence to determine which receiver had the right data. With packet, that process is automated by the CRC. Question: Could you explain how a strong signal could be worse than a weak signal? Answer: There are only two kinds of packets: perfect and useless. Any packet you can demodulate is good. Comment: Assume a flat earth, and fixed ionosphere height, and raytrace a few angles. You'll quickly see the interference pattern, resulting in areas with no signal, and areas with strong signal. Question: Can you propose a model for a strong, bad signal? Answer: Sure. Two signals colliding makes a big signal. Comment: Bit smearing by multipath can ruin a packet, too. Answer: Another case is when the weaker signal is the one you want. Tests were also performed on military signals that were strong and had a clear channel. Signals were still observed that could not be copied even though they were loud. Question: How did you perform the low baud rate tests? Answer: With a cooperating connected station. Question: At low baud rates, did you use a correspondingly narrow filter? Answer: No, we used the same 500Hz filters for all speeds. Question: Did you see frames with no detectable fading that you still didn't copy? Answer: Yes, and I can't really explain them. ======================================= Phil Karn, KA9Q - NET/NOS status Anders Klemets, SM0RGV, has evolved the simple mailbox is NOS into a fullscale BBS. The RSPF (Radio Shortest-Path-First) protocol has been added to NOS. It's more stable than algorithms like the one NET/ROM uses when paths go up and down. Each node only keeps track of the routes to his neighbors. The information is distributed by flooding, and each node is able to compute a map of the network. RSPF mirrors OSPF, an Internet protocol. PPP, the Point-to-Point Protocol, has been implemented by Katy Stevens. This serves as a replacement for SLIP (like KISS) on wired links. She has also implemented TCP header compression, which replaces the usual 40 bytes of header overhead with 3 bytes. This is especially interesting when sending a lot of single-character packets, as when doing remote keyboard echoing. Anders has ported the compression to the AX.25 module, but it's not as exciting there because of the AX.25 header and keyup delay overhead. Anders has implemented stream compression based on the LZW algorithm. This scheme is transparent to applications. It works reasonably well for large file transfers, but isn't very useful for small files like mail messages. NOTE: A lot of work on NET/NOS has been done by others, but KA9Q gets lots of gripes and questions about parts of the software he didn't write and may never even have seen. Please don't call him unless you're sure it's his part of the code that's a problem. He's been trying to get the code running with some faster modems. He's been running a 56kbps WA4DSY modem on 220 MHz for a long time, but the host interface is a problem. His HS driver uses a PC plug-in card with a 8530 chip without DMA support. Since the machine can't service an interrupt per character, the HS driver has to sit in a spin loop while receiving a packet. This causes the machine to freeze up. In the last few months, two new cards have appeared that support DMA: the Ottawa Packet Interface (PI) board, and the DMASYNC card by WA6FXT and N6XJJ. The DMASYNC uses a WD1950 instead of an 8530, so it has only one channel. Since there's only one DMA channel available in a PC anyway, that's no big loss. Question: Doesn't anybody make a card with a shared-memory interface? Answer: The PackeTen is the only one, and it's pretty expensive. Both of these DMA-supporting cards are cheap. You don't need a fast machine to run NET as a gateway or switch. Last year KA9Q described a collision avoidance algorithm, and he's still working on that. He now has an idea to modify P-persistence dynamically. The TNC would be slow to take the channel after hearing a packet that needs to be acknowledged by someone else, and fast to take the channel to acknowledge a packet for itself. This might help mitigate the hidden terminal problem. It might also be useful to enhance the MHEARD feature to keep track of hidden terminals, so as to try to avoid transmitting when a hidden terminal is probably transmitting. This kind of enhancement can even help on a point to point link, by reducing the collisions between data frames and acknowledgement frames. With the HS driver, back-to-back data frames had a short gap between them, just long enough for the other station to jump in and collide with the next data frame. Question: What about your work with authentication schemes? Answer: I'm working on several schemes. Some are weak against an active attacker, and some aren't. Question: If we have a good system of authentication, there may be problems with export restrictions. Answer: My understanding is that authentication systems (unlike crypto systems) are not a problem. Control of export of authentication systems has been transferred from the State Department to the Commerce Department. KA9Q has implemented a scheme for transmitting passwords over the air. The method is misnamed MINK, for Master InterNet Key. It's based on the idea of a one-way function: a mathematical function that is relatively easy to compute, but whose inverse function is very difficult to compute. The standard crypto system DES is an example of a one-way function. Aside: Shamir (the S in "RSA") has found an attack that breaks many simple variations of DES. Under this attack, DES is exactly as difficult to analyze as under the brute force approach. If this attack is the best possible, this shows that the choice of key-size (56 bits) was exactly right. If so, charges that the NSA reduced DES's key-size in order to weaken its security are ill-founded. MINK uses a one-way function called MD4. MD4 produces a 128-bit output from any size input. The scheme is to take your (secret) key, and apply MD4 to it many times, say N times. Call this result F[N](x), where x is your password. Since the inverse of MD4 is hard to compute, it will be hard to compute F[N-1](x) given only F[N](x). So it's safe to transmit F[N](x) over the air, provided that in the next session you use F[N-1](x), and F[N-2](x) in the one after that, and so on. Since MD4 itself is easy to compute, the server you're logging into can easily verify that the password you're using now, F[N-1](x), corresponds correctly to the one you used last time, F[N](x), by simply computing F[1](F[N-1](x)). This scheme is secure (to the extent MD4 is really hard to compute) against passive eavesdroppers, who only try to learn your password by listening to what you transmit. It is not at all secure against an active attacker, who may transmit messages of his own in an attempt to gain access to your account. Also note that the computer itself doesn't have your current password; it only has your previous password. MD4 is used instead of DES, which is probably much more secure, because DES is too hard to compute in the forward direction. Since MINK involves computing many iterations of the crypto algorithm every time a new password is needed, a difficult-to-compute function is impractical. Question: Doesn't this assume that the users have local computers that can compute the encrypted passwords? Answer: Yes, that is a potential problem. Perhaps the users could be asked to have smart cards to compute passwords. For the user who does have a computer, he needn't worry about MINK at all. The telnet program he uses to log into the remote computer can easily respond to the MINK password prompt automatically. Question: If you have a password with many bits, don't you have a problem with users mistyping a long numerical password? Answer: A standard way around this problem is to use mnemonic words. You assign a list of, say, 2048 standard common words. Each word can then be assigned a unique 6-bit number. So if your password is 66 bits long, you just have to remember (and type in) a sequence of 11 common words. Question: Doesn't this system demand that you always log in from the same place? Answer: No. The server computer maintains all the state information. When you try to log in, it tells you what N it expects you to use. For example, a login dialog might look like this: login: karn MINK 99 KA9Q1 Password:_ So you have N, and the input to the function. You just run MD4 with your secret key N times on the seed "KA9Q1" and type the result back to the computer. If you're on a secure link instead of a radio link, you can also type your regular (plaintext) password. Also notice that if you don't trust the computer you're using to log in from, you can't let it do the password computation for you. That would involve telling it your secret password. The only secure alternative is to carry your own password computer with you. We use Atari Portfolios. Question: Is MD4 available? Answer: I will be releasing a package soon. Question: What are the relative advantages and disadvantages of Unix vs. DOS for a TCP/IP server? Answer: The most important thing is to get a recent version of TCP/IP with the Van Jacobson enhancements. I recommend that the best way to put a Unix box on the air is to use a dumb PC as an ethernet to radio TCP/IP gateway. The gateway PC can handle your dialup link to work, too. Question: Can't I just connect a TNC to a TTY port? Answer: Yes, you can, but that only handles one interactive user. With a TCP/IP port you can support more users and get more functionality. With BSD Unix for the '386 coming out, the art of hacking TCP/IP support into Unix will become obsolete. Besides, putting NOS into Unix or even putting all sorts of features into NOS is counter to the original spirit of NOS: to introduce TCP/IP to amateur radio, for cheap. Question: What flavors does NET/NOS come in, and where can we get them? Answer: If you have Internet access, ftp to thumper.bellcore.com ([128.96.41.1]) and log in with username anonymous and password your name. Look in /pub/ka9q; there are different subdirectories for different versions. If you wish to contribute something, put it in /pub/ka9q/incoming. I can't handle any other distribution mechanism. The code is also available on several dialup BBS systems. Question: What about the TAPR library? N3EUA: I have given up on packaging the KA9Q code for releases. It was just too time-consuming. We've been at this project for 5 years! Question: What are the difficulties of configuration control? What works and what doesn't for a widely-distributed group effort like NOS? Answer: Everything works fine if people are working in separate areas. For instance, Anders work on the mailbox code was easily integrated back into the standard release. If two people are working on the same module, there's a problem. In a volunteer project, you can't use someone's promise to do a task as a locking mechanism. For example, two different people fixed the domain name system simultaneously, and now I have to choose one and snub the other. N3EUA: the 890421 release of NET was a big integration problem, with many different sets of conflicting changes. One developer made wholesale changes (some of which were unnecessary), and that code is still a separate branch that will probably never be integrated. ======================= Ron Bates, AG7H, works at NRAO with the radio telescopes on Kitt Peak. He invited interested parties to go on a tour of the telescopes after the meeting. Provided the road isn't blocked by a rockslide! Lyle Johnson, WA7GXD, thanked everyone for coming to the meeting. See you next year!