Global Position Reporting
There is currently a nationwide effort to provide the information received by local APRS LANs to the Internet. This is done using APRS servers which provide live APRS traffic to the Internet. By using a simple TELNET client, one can connect to a server and see the information that is being collected throughout the United States. Several APRS servers are available for different operating systems. For Linux users, there are presently two APRS servers available: aprsmon and aprsd.
The aprsmon server can be found at http://www.cloud9.net/~alan/ham/aprs/; aprsd can be found at http://www.wa4dsy.radio.org/Files/aprsd.beta101.tar.gz. APRS servers allow users to connect and examine remote APRS networks located in several metropolitan areas. The nationwide network of servers is expanding with the ultimate goal of allowing one to locate mobile trackers anywhere in the U.S. To better understand the information provided by these servers, try a TELNET session to any of the addresses listed below. The numeric value after the host name is the port number and is required.
kb2ear.aprs.net 14579 (Northern NJ)
kb2ear.aprs.net 6261 (USA)
kb2ear.aprs.net 14580 (Composite of above)
www.wa4dsy.radio.org 14579 (Atlanta, GA)
socal.aprs.net 14579 (Southern CA)
www.aprs.net 10151 (USA Composite)
www.aprs.net 14579 (Southeast FL)
sboyle.slip.netcom.com 14579 (San Francisco, CA)
The information returned from these TELNET sessions is real-time raw data that is broadcast by amateur radio operators at intervals from 1 to 30 minutes. The short duration broadcasts (e.g., one minute) are intended for mobile (tracker) applications where there is movement and therefore a need for frequent updates. The longer duration broadcasts (e.g., 30 minutes) are intended for fixed stations (homes) broadcasting their locations. These servers provide packets which include the position of the transmitting station's latitude, longitude and often a brief message about the station. Listing 1 is the output from a typical APRS TELNET session.
Each line of text in Listing 1 is a packet that contains the amateur radio call sign of the source station, the destination address and any repeaters used in the path. For example, in the first packet shown after the login message, W4DUF is broadcasting to all stations in the APRS network. Due to distance limitations (typically a few miles), other local stations along the route, called digipeaters (digital repeaters), are used to extend the distance by repeating the packet. In the example, stations N4TKT-2, WIDE and N4NEQ-2 are being used to repeat the packet. In this way, distances can be extended to a large metropolitan area (i.e., a 20 mile radius), as well as across the nation by using special high frequency (HF) digipeaters called GATEs. Due to limited RF bandwidth, broadcasting positions nationally is typically limited to special events such as tracking the Olympic torch as it traveled across the U.S.
With the development of a nationwide APRS backbone using the Internet, transmitting local APRS traffic can bypass the constraints of limited HF bandwidth. An APRS TELNET session as shown in Listing 1 is interesting, but difficult to understand due to the raw format of the information. To better understand the data being presented, graphically formatted web pages are used. These web sites take the raw information and overlay the location of the stations on a map. Figure 3 is an example of a typical APRS web page. The list of web sites below shows real-time or near real-time (delayed 15 minutes) APRS traffic and requires a Java-enabled Net browser.
http://www.wa4dsy.radio.org/aprs/usa.html (Entire US)
http://www.wa4dsy.radio.org/aprs/soeast.html (Southeastern US)
http://www.wa4dsy.radio.org/aprs/ga-atl.html (Atlanta, GA)
http://www.aprs.net/sfl.html (Southern Florida)
http://sboyle.slip.netcom.com/LIDSAPRS.html (San Francisco, CA)
As we have seen, APRS servers provide raw data, and web browsers can show the information in a graphically interesting and informative manner. However, both are passive applications that require a user.
For many applications, it would be nice to automate the system to perform a specified task automatically. For example, you might wish to be informed by e-mail that the lead float in the Rose Bowl Parade has reached a specific point in the route. Or perhaps you have a mobile tracker and wish to sound an alarm when the tracker reaches a specific location. For this application, you need a program that will examine the raw APRS data and execute a command based on user-specified criteria. This is exactly what PerlAPRS does, and Linux is the perfect platform for this type of application since it supports multitasking so well.
PerlAPRS examines incoming packets and executes a command when a call sign and location match the criteria specified by the user. Location criteria is specified using grid squares, a rectangular area measuring approximately 2.5 by 5 miles.
The best way to understand how PerlAPRS works is to look at an example. The line numbers shown in the left-hand column below are provided for illustrative purposes and are not part of the normal output. Line 1 shows an example packet. PerlAPRS parses the packet and extracts the call sign, latitude and longitude. Line 2 displays the call sign as KD6AZU, the latitude as 3243.700 (32 degrees, 43.700 minutes North) and the longitude as 11707.700 (117 degrees, 7.700 minutes West). Next, PerlAPRS searches a call sign file, previously customized by the user, looking for a match. The first two attempts at a match shown on lines 3 and 4 fail. The third comparison shown on lines 5 and 6 is successful. This match causes the command, cmd3.sh, to be executed. The command may be any UNIX-style command; however, simple shell scripts are used for most applications.
1. Packet= KD6AZU>APRS,KD4DLT-7,N4NEQ-2,WIDE*: @042327/3243.70N/11707.70W/0 2. KD6AZU 3243.700 11707.700 3. - KI6MP-10 DM12JV 4. - KC6VVT-9 DM12IT 5. * KD6AZU DM12KR Sun Aug 10 15:56:13 1997 3 6. Sun Aug 10 15:57:13 1997 1 cmd3.sh
This brief discussion of PerlAPRS is intended to provide a simple overview. The program provides several additional features intended for real time applications. PerlAPRS is distributed under the GNU licensing agreement. The source code and further information on the program can be found at http://people.qualcomm.com/rparry/perlAPRS/.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Stunnel Security for Oracle
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SourceClear Open
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide