AFOSD is a tool for distributing selected AFOS products via various packet radio channels. AFOSD supports several forms of packet channels and allows selective products to be sent out specific single or subsets of channels. AFOSD supports direct connected packet equipment as well as packet systems accessable via wired networks. AFOSD takes the form of a "daemon" that running on Linux (IBM-PC/AT compatibles with 386/486/586 processors) systems.
AFOSD provides a means of distributing National Weather Service data products via the Amateur Radio Service's packet (digital) radio network. The National Weather Service (in the US) utilized Amateur Radio Operators (hams) in its role of tracking severe weather. Hams trained in severe weather spotting relay first hand reports of severe weather to the NWS via radio.
In its efforts to increase the effectiveness of these spotters in the field, the NWS has now made available some of its data products for use by these weather-spotter / hams. An "AFOS" data line at the NWS office is made available to the amateur station on site. The amateur station is then allowed to transmit this data to spotters via packet radio.
AFOSD is intended to sort through the various products coming from the AFOS line, sending specified products to the various radio channels as well as the local display or printer. This allows the amateurs to limit product transmission to urgent and locale-pertinant information.
While the AFOS configuration at the NWS allows the AFOS line to be "scheduled" with specific products, the filtering provided by this AFOSD software provides real-time fine-tuning to the amateur operators, as well as the ability to route locale-specific products to appropriate radio channels.
Another goal of AFOSD is to provide AFOS data to a heterogenous packet network. In the initial installation environment, the hams in the area immediate to the NWS office utilize the APRS system. The amateurs in an area 70 miles away utilize TCP/IP and standard BBS systems. This type of compatibility requires some special coding considerations.
Finally, AFOSD is network-aware. In its initial installation, it will communicate with an internet/packet-radio gateway via the internet. This remote gateway will then distribute products via packet radio channels. This means that the Internet is used to transport the data to the ham system at the remote site. The AFOS data is never accessable from the internet at large, but is only available to amateur radio operators via packet radio systems.
AFOSD provides the following functions:
The port configuration file defines the various channels available for AFOS product distribution. For example, if there is a local TNC that the AFOS data should be sent to, that radio channel will be defined in this file.
There are three types of configuration lines in this file: comments, port definitions and special port designations. Comments allow the maintainer to document the configuration file with explanations. Comments are ignored by AFOSD. Port definitions cause AFOSD to associate a channel name with the specified channel. The port definition provides all the details that AFOSD needs to establish the channel. Channels can then be designated for "special" functions with Port designation lines. Not all channels with have special designations, some channels will be utilized only for filter output, and will have no special designation in the port configuration file.
This entry would be used to define a generic serial channel. This would be useful for a serial printer, dumb terminal, or TNC in transparent or converse modes. The only data sent out the port is the AFOS data, there are NO TNC configuration commands or data formatting or framing performed.
USAGE: port <CHANNEL NAME> <DEVICE NAME> [BAUDRATE],[BITS(7|8)],[PARITY(O|E|N)],[STOPBITS(1|2)]
Where:
Example: A serial printer that communicates at 4800 baud with 7 data bits, odd parity and 2 stop bits is connected to the PC's COM2. COM2 is known as /dev/ttyS1 in Linux-speak. We will call the channel 'teletype'.
port teletype /dev/ttyS1 4800,7,O,2
Example 2: A "dumb terminal" is set up near the net control station so that he can see severe weather statements. It talks 19200 baud with 8 data bits, no parity and 1 stop bit. Its connected to COM1. COM1 is known as /dev/ttyS0 in Linux speak. We will call this channel 'net-control'.
port net-control /dev/ttyS0 9600,8,N,1
Example 3: A TNC is pre-configured to run in transparent mode, never requiring commands, even after power interruptions (not a very likely scenario, but hey, its an example). The TNC communicates at 2400 baud with 7 bit data, even parity and 1 stop bit. Its connected to COM3 (/dev/cua2 or /dev/ttyS2 in Linux-speak). We will name its channel 'slow-packet'.
port slow-packet /dev/cua2 2400,7,E,1
Example 4: A printer is dedicated to the AFOS application. It is connected to the parallel-port PRT1. PRT1 is known as /dev/lp1 in Linux-speak. We will call this channel 'dotmatrix'.
port dotmatrix /dev/lp1
(Since there are no options to configure on the port, the baudrate and other options can be omitted.)
Network channels communicate with remote AFOSD systems. The network channel can be wired or wireless, such matters are transparent to this application. This option can be used to transfer AFOS products to a remote AFOSD system across the internet or across packet systems. The TCP protocol is used for the channel.
An example of the utility of a network channel: While some slow, unreliable packet channels exist between the NWS office and a city 70 miles away, a packet radio / internet gateway exists in the remote city. Sending the AFOS data across the internet to the remote gateway will provides more reliable transmission of the data. The only end-user access to the data remains the packet radio system.
USAGE:
tcp <CHANNEL NAME> <REMOTE HOST> [TCP SOCKET NUMBER]
Where:
Example: A remote system is to receive AFOS products across the network. The remote system name is wx.kb0tyf.ampr.org. The channel name is to be 'cedar'.
tcp cedar wx.kb0tyf.ampr.org
Example: A remote system is to receive AFOS products across the network. Its to use a specified TCP port to get around some networking er... difficulties. The system name is skywarn.amrad.org, and the port it will listen on is 119. The channel name will be 'remote'.
tcp remote skywarn.amrad.org 119
The file channel will create or over-write an existing file with the AFOS product. This entry allows filter entries to maintain the latest copy of a product in a file. When a new product is received, it replaces the old product in the file.
USAGE:
file <CHANNEL NAME> <FILE NAME>
Where:
Example: This facility would be useful for maintaining a local copy of RCM's on disk. If the file was accessable via ftp, remote packet systems could always pull the latest product by downloading a specific file. A channel called ftp-rcm is created that maintains the latest copy of an rcm in the ftp area of the system. The file is called /home/ftp/chircmdvn.bin The ftp area on your system may differ from this example. For more complete information on how to set up an anonymous ftp site, read the Linux Network Administration Guide or check out the ftp daemon man pages.
file ftp-rcm /home/ftp/chircmdvn
Example: Another useful facility would be to allow users to read the 'SPS' products (significant weather outlook and watch products). Assuming that a customized finger daemon is installed, and that it expects files to be in the directory /home/fingerd, we will set up a channel that will put products in /home/fingerd/sps.txt. The channel name will be finger-sps.
file finger-sps /home/fingerd/sps.txt
This type of channel appends specified products to the file. This differs from the file channel since it never truncates the file - new products are always appended to the end of the file. This provides for one or several products to be logged to a file, allowing a history to be maintained.
Example: A log of all surface forecasts for a terminal is to be maintained. (A mechanism external to AFOSD, such as cron, could truncate the file daily.) The file will be called 'sao.log' and the channel will be called 'surface-file'.
log surface-file sao.log
Example: A log of all products is to be maintained to help diagnose some problems with the system. The channel will be called debug-file and the file is to be '/tmp/afosd.dump'.
log debug-file /tmp/afosd.dump
A process line defines a channel that will launch a process for every product that it receives, feeding the product to the standard input of the child process.
USAGE:
process <CHANNEL NAME> <APPLICATION NAME> [OPTIONS]
Where:
Example: Severe weather warnings are to be emailed via the packet network. Since the email recipient is accessable via TCP/IP, Linux's native email utility, 'mail', can be used. The channel name is 'warning-email' and the email address of the recipient is 'ares@w0gq.ampr.org'
process warning-email mail -s "Weather Warning" ares@w0gq.ampr.org
Explanation: When an AFOS product is sent down this channel, the Linux command 'mail' will be launched. The command will execute as if the command:
mail -s "Weather Warning" ares@w0gq.ampr.org
had been typed on the command line. In Linux-speak, this tells linux to send a mail message with the subject "Weather Warning" to the email address ares@w0gq.ampr.org. The mail command will see the AFOS product on its standard input, then see an end-of-file. Mail takes this "standard input" as the body of the message and sends it off.
Example: Certain products are to be spooled to a printer. This is not a dedicated printer, but a printer shared with other users. The channel report-printer is defined to spawn print jobs on the shared printer by using the Linux command 'lpr'.
process report-printer lpr
A pipe channel defines a channel that will launch a child process and feed it products as they are received. This child process is launched once at AFOSD startup. The pipe is left open between product receptions. This differs from the process channels that launch one child process for every product (message) received. The child of a pipe channel will see its standard input remain open, and will receive multiple AFOS products as they are received by AFOSD.
USAGE:
pipe <CHANNEL NAME> <APPLICATION NAME> [OPTIONS]
Where:
Example: A hypothetical utility 'afos-to-news' will post afos products as separate news articles to the packet newsgroup 'ampr.ia.wx.warnings'. The channel will be called 'warning-news'.
pipe warning-news afos-to-news ampr.ia.wx.warnings
The afos-in designation line must specify a valid channel definition. There must be one afos-in designation in the port configuration file.
afos-in <CHANNEL NAME>
Example: A port command in the configuration defines a channel called "feed". It happens to be a 9600 baud serial channel on COM1, but all that is defined on the port line. With the afos-in designation, the only specification is the channel name.
afos-in feed
Example: A tcp command in the configuration file defines a network channel called nws-remote. This happens to be a system accessable over the internet that feeds us afos data. None of the network details are pertinent in the afos-in designation. All of the nitty-gritty is handled on the tcp channel definition line.
afos-in nws-remote
This optional designator allows the linux system running AFOSD to share a TNC with an APRS computer. The computer running APRS is plugged into the AFOSD port designated as the afos-computer port, while the TNC is plugged into the AFOSD port designated as the afos-tnc port. AFOSD then relays data between the TNC and the APRS computer, acting as a "bent pipe".
AFOS products sent to either of the specified channel will be sent to accordingly the local APRS system or the TNC. This allows local APRS operations on the local APRS computer while distributing also making AFOS products available to APRS users.
USAGE:
aprs-thru <APRS COMPUTER CHANNEL NAME> <APRS TNC CHANNEL NAME>