by Andy Nemec, KB9ALN
Hello again to all in the month of Halloween. Fall's crisp air is advancing, and the outdoor projects will soon be coming to an end. Hope you are set for the winter.
As was mentioned here last month, the WAPR meeting took place in Green Bay. You will find the meeting minutes here on this page.
There are two developments that I talked about last month and that were also mentioned at the WAPR meeting. That would be the proposed node system in Waupaca, and the recent addition of a BBS in Sheboygan. There is some news on both of these developments that is newer than what was written in the meeting minutes.
First, Waupaca. Aaron, KB9QWC has been trying to get a node stack up and running in Waupaca county for some time now, and we reported that he now has his radio and has made some trials from his home in Clintonville.
Unfortunately, the setup that Aaron has does not provide all that is necessary to connect to Rudolph, or to the East. However, some recent developments concerning ARES in Waupaca county may present an opportunity to obtain use of a very good site for a nodestack. Aaron has bee able to do some testing at this site, and reports that he has monitored not only the Rudolph node with no problem, but also nodes to the West. As of this writing. I do not have all of the details as to how the stack will be configured, call-sign, and frequency. As I hear more. I'll let you know about these and other details.
The other story that needs updating is the linkage to Sheboygan. Red, N9GHE has aimed the beam toward Josh, KG9BQ who has a BBS and LAN node setup in Sheboygan. So far the link seems to be solid, and after Josh gets done "tweaking" all of the operating parameters, it should be all set for regular use. One of the tweaking points is TCP/IP routing. As of now, regular AX.25 and Net/Rom node connects can be made. But a lack of IP routing means that one can't connect to the BBS using telnet. I'll report here when all the details have been ironed out.
In other news. I have received word of a new TNC coming from Europe. Jim Romelfanger was amongst those who sent me info on the new unit, and it does indeed look interesting.
This unit is designed to make life easier for those who want to try TCP/IP, but don't want to invest time configuring one of the traditional TCP/IP NOS programs that were designed for ham radio. It uses a novel approach to achieve this, it behaves just like your conventional modem does. This allows your existing web browser, telnet, E-Mail and ftp programs to operate over packet radio. They think they're talking to a telephone modem, but they are really talking to a TNC. It makes TCP/IP over ham radio very nearly identical to the internet surfing via a phone line. Of course, it is slower than what you will see on the internet, of course.
It sounds fairly fasy to set up, with the TNC commands sent as a "modem initialization string". This means that a long list of commands that you normally would have to set up is now gone. Just a few to set TNC parameters, and you are on the road.
The TNC is also capable of operating in the KISS mode, and the terminal mode. So it is not exclusive to TCP/IP - it can operate conventionally in the event that you need it to. This new TNC will be the subject of a report to appear on this page in the December issue, took for it then.
That is all we have time and space for this month, until next time, 73 from Andy.
Meeting Minutes: August, 1999
The Wisconsin Amateur Packet Radio Association held its quarterly meeting on August 21, 1999 at the Old Country Buffet in Green Bay. The meeting started late; it was called to order at 12:24 p.m. In attendance were N0GMJ, N9NCQ, N9BQM, N9CFN, KB9QWC, KB9MWR and KB9ALN.
The first order of business was a treasurer's report given by Al, N0GMJ. Al had only recently received all of the treasurer's materials, and was able to discern that we had, as of this date, $2001.16 in the checking account. There are no other accounts held by WAPR, so this represents our total monetary assets.
As far as can be determined, the only known outlay that needs to be addressed is an invoice from the Badger State Smoke Signals for $340.00 for member subscriptions. This will be paid as soon as the new checks arrive.
Some of the dues checks that were added to the balance were quite old and may need to be replaced, it was noted. Al is working to determine which checks can clear, and which checks may have been canceled by members who thought they had been lost. He will contact those members who may have canceled payment on checks that were not promptly deposited.
Al also noted that his review of the membership rolls reflected a substantial drop in membership. 1996 figures showed 45 members ,1997 showed 13 members, and so far in 1999 we had 13 members. Figures for 1998 were not available.
Al will carefully inspect the membership list and cross check it with the list of people he has who receive the Badger State Smoke Signals. He will also compare the current list to the list of past members and send out "reminder cards" to people who have been past members.
Al also observed that the cost of the Badger State Smoke Signals subscriptions is more than double the amount that WAPR charges its members for the magazine. He suggested that we consider raising membership dues to cover this shortfall.
Comment from KB9ALN: With the small membership we, currently show, and the fact that we have enough operating funds in the treasury to carry us through the year, it might be unwise to consider this right now. It was agreed that we should discuss this next year, rather than now, for the reasons cited.
Question from N9BQM: Can we change our fiscal year to start in August? This would give members who have paid for, but not received the Badger State Smoke Signals, 13 months of membership instead of 12. This would be offered as some kind of remedy for those members. Al made a quick check of the number of Badger State Smoke Signals subscriptions vs. the number of paid memberships for the time period in question, and determined that this should not necessary. However, Al will check into this much more thoroughly and report on it later.
Next, Joel N9BQM, made complimentary comments to KB9ALN concerning the Wisconsin Packeteer page that appears in the Badger State Smoke Signals. KB9ALN asked for more input on topics for the feature article section of the page. (BSSS editor's note: One of Andy's 1998 columns was reprinted in CQ VHF magazine earlier this year, and with some nice compliments from the staff of the magazine about Andy's writings and about BSSS.)
The next order of business concerned offices and the people holding them. There were no persons volunteering to run for office, so there was no need for an election. As a result, the current slate of officers will remain, and they are:
Joel, N9BQM - Chairperson
Ron, N9CFN - Vice Chair
Al, N0GMJ - Treasurer
Andy, KB9ALN - Secretary
Guy, KF9XX - Director
Larry, WD9ESU - Director
In addition to this, the appointed position of Frequency Coordinator is
still held by Walt, AA9AW.
The next item up for discussion was meeting sites. Joel noted that the last few meetings, have been held in the east-central and northeastern parts of the state. He expressed a desire to have meetings in other parts of the state to better serve members who may not be able to travel very far out of their home area. One suggestion was to have a meeting in the Milwaukee area, as it has been quite some time since we have had a meeting in that part of the state. We will make an attempt to have a meeting in that area, as well as the southwestern and northwestern parts of the state soon.
Next up was a report on the IP Coordination status. This is technically not a WAPR function, but it is fortunate that the IP Coordinator is also a WAPR officer. Ron, N9CFN is the IP coordinator and reports that he has gotten updates from his area coordinators and has also "cleaned up" the state domain list. Formerly, non-amateur addresses had appeared on the list, which is not what the amateur IP domain list supposed to reflect.
He also noted that there have been some operators who have simply made up addresses and gone on the air. This is not only operating against the grain of the system, but totally, unnecessary. Ron is readily reachable by postal, packet, and electronic mail. He also attempts to make a very fast turnaround on the requests for IP addresses. All were puzzled that this situation (the self-selection of IP addresses) exists. There was speculation that some people may not realize there are "area" IP address coordinators that assist Ron in the assignment of IP addresses and that there might me confusion there. (See the attached information concerning state and area IP coordination).
Up for discussion next was network expansion KB9ALN reported that Josh, KG9BO, in Sheboygan, has configured a BBS and also has a UHF Backbone port on it. Currently he has established a good, solid link with the N9PBY node stack in Port Washington. In order to link with the network to the north, Red, N9GHE, in Manitowoc will re-aim his beam that was pointed at the former Sheboygan site. As soon as Red can line up a tower climber, this will be done.
This brought up a question of IP routing through Sheboygan. Currently, there is no routing set up to go through Josh, and this will be corrected when the beam is re-aimed, if not sooner.
The Other network extension will go West from Neenah. Aaron, KB9QWC, picked up his Motorola Mitrek from Al N0GMJ who had performed modifications on it for 9600 bps service. Bob, KA9JAC, in Neenah has aimed another antenna toward Aaron's location in Clintonville, and testing on the link will begin when Aaron installs the radio, which should be very soon. This linkage will allow mail forwarding to Bob, and should link the Fox Valley with points West.
Next we had a short discussion concerning the history of WAPR, its various incarnations, and its future. The discussion was too detailed to recount here, although interesting and informative.
The last order of business was a technical discussion fostered by Al, N0GMJ's, experiments with the various TNCs he had has access to while setting up nodes in the western part of the state. He has observed that the MFJ arid Kantronics 9600 bps will effectively operate with almost any decodeable signal level, weak or strong. The Paccomm Sprint and Spirit II models seem to suffer from an inability to decode very strong signals. A phone call to Paccomm Tech Support revealed that this is due to the filtering characteristics of the Paccomm modem. They are biased toward weak signals. It seems that when stronger signals have total capture of an FM receiver, the low-frequency components of the audio appear at an increased level in the audio recovered by the receiver's discriminator.
In the Paccomm TNCs, this appears to disrupt the higher frequency audio signals to such a degree that the TNC has difficulty decoding the packet audio.
There appear to be two primary methods ways to help minimize this effect.
One way is to have Paccomm burn a custom ROM for the TNC. The modem's frequency response characteristics are burned in ROM on the TNC, unlike the modem offered for sale for the Tiny-2 TNC. On that modem, the filter is jumper-configured.
Another way is to limit the transmission of low-frequency components in the transmitter that the TNC is trying to hear. One can add a high-pass filter between the TNC and the radio as one solution. Another is to choose a different place to inject the transmitted audio, relying on the circuit's natural high-pass characteristics. Al has chosen this method so that the receiving TNC has better decode performance under strong-signal conditions. It will also negate a need to construct low-pass filters for existing installations.
KB9ALN suggested we experiment with pre-emphasis on the transmitting units and de-emphasis on the receiving units, and Al agreed, though there was no firm plans for such experimentation.
After additional discussion concerning this matter, we adjourned.
Submitted by Andy Nemec, KB9ALN
Linux and Packet Radio - Part 2 by Andy Nemec, KB9ALN
Last month, in the spirit of doing something completely different, we began a 3-part series about using Linux in ham radio, specifically packet radio. This month we continue our series with a closer look at Linux to give you a feel for it, and tell you about the various methods that application programs use to "talk packet" ?
How does it look and work?
You may remember from last month that Linux is a multi-user, multi-tasking system. The term "multi-user" is pretty self explanatory. Several people can be using a given computer at the same time. Multi-tasking means that the computer can do several things at apparently the same time.
A word about Users. All users have a section of the hard drive reserved for them. This is called their "home" directory, and these are unique to each machine's user. Each user also has access to his of her own home directory only.
Certain users have more privileges than others. A regular user has access to some of the functions and services available on the computer. He or she cannot, for example, shut the machine down, or make vital changes to the system files. These tasks are only permitted to be done by a specially privileged user called a "superuser". This is the person responsible for configuring and maintaining the system.
The User Interface (what does the screen look like?)
Linux can be configured to operate in one of two basic user, interfaces, the shell and a Graphical User Environment, or GUI.
The shell resembles the familiar DOS command-line prompt, with some special differences. First of all, you are required to log in with a user name and a password. Linux is a multiuser system, and the machine needs to know who you are.
Once a user is logged in and is placed in their proper home directory, not too much exciting appears on the screen when you are using the shell interface, All you will see is a command prompt with the user's name, the @ - symbol, the computer's name, and the directory name. On my Linux computer, my prompt looks like this:
[kb9aln@kb9aln-l kb9aln] $
Any commands that I type appear after the $. The shell is the most common user interface for people who log on to a computer remotely.
The interesting thing about the shell is that you can log in more than once. This holds true whether you are at the computer's console, or if you are remotely accessing the computer through a network. When you are at the keyboard, holding the ALT key while pressing the F2 key will transfer you to another log-in prompt. ALT and F3 is still another, and so on. Most Linux systems are set up for six of these "virtual consoles", and you can use all of them, if you like.
The Graphical User Interface appears to be something like Microsoft Windows...only different. It is a point-and-click user environment that you manipulate with a mouse. Of course, a log-in box is provided for you to enter your usemame and password. The GUI interface is most often used by someone at the local console. It is worth mentioning here that a local user can be using either the shell or GUI user interface, while remote users can use the shell or GUI interfaces. They are completely independent of one another.
Packet Radio Usage
There are a couple of different way* to use packet radio with Linux. One method is "kernel "based, the other is "application based".
Of course, we use AX.25 in packet radio, so we need to have Linux talk that language. As was said test month, Linux has networking built right into the operating system. This is TCP/IP networking, just as is used on the Internet and amongst some ham packet radio stations. However, we still need AX.25 to talk to other amateur packet stations.
In kernel based AX.25, the support for AX.25 is built into the operating system in a manner similar to the way that TCP/IP in built into the system. You can connect to other packet stations with AX.25 built into the system, but you can't get too fancy. Fancier functions, like a mailbox, are left to other programs running on the system (remember, Linux can do several things at the same time). You can also find Linux packet radio programs that give you a nice split screen.
Back to the WAPR Home Page and Index