OVERVIEW: The DX cluster monitoring function in APRS is intended to provide a graphical tool for the regular DX cluster user and is NOT intended to bypass membership and support of your local DX cluster. Users of these facilities should be encouraged to support them. Unlike other monitoring programs which are totally passive, the DX cluster sysop can use APRS to monitor the channel and see what APRS users are out there.

BACKGROUND: Since APRS was designed to monitor a packet channel and to capture selected packets for display, it is an ideal tool for the DX enthusiast. The position reporting and operator-to-operator message capability of APRS using UI frames performs the same functions as the DX cluster, but at a significant improvement in channel efficiency. In addition, the DX spots appear on a map of the world instead of in text form! The efficiency improvement of APRS is due to the elimination of the need for a separate transmission and ACK from every DX cluster user for every spot report. APRS on the other hand, uses its decaying BEACON algorithm to transmit the spot quickly but redundantly enough to assure delivery. If there are 20 users logged on to a DX cluster, then under ideal conditions with NO collisions, then there are a minimum of 40 packets involved. APRS under IDEAL conditions only needs ONE packet. Even if APRS repeats the packet 3 times to assure that every station gets it, then there is still a fourteen- fold reduction in QRM by using APRS.

APRS MONITORING: Paul Evans, G4BKI, at PACCOMM, suggested using APRS to monitor existing DX cluster operations. In this DX mode, APRS captures spots and maintains lists of items captured:

• All DX spots are plotted on map and retained on the ALL SPOTS display
  
• Grid Squares are used if given as the 1st 4 letters of the comment field
  
• Accumulates a list of all DX cluster users currently logged on
  
• Grabs WX and WWV spots and ANNOUNCEMENTS
  
• Accumulates an ACTIVE MAIL LIST of all messages on the cluster
  
• Collects user-to-user TALKs on its TRAFFIC page
  
• Sounds out DX calls in CW
  
• Plots the location of any station in response to a SHOW/STATION

• DX mode turns off the normal APRS filter so that it will monitor all OTHER packets on frequency and not just APRS packets (see warning below). You will see the *DX* flag on the control panel where you usually see BCNS.

• It saves all DX SPOTS, announcements, WWV and WX reports on the ALL BEACONS list which can be displayed at any time using the A key. The ALL BCNS list will still get saved to the LOGS directory everytime the list gets greater than 50 entries if LOG is enabled.

• APRS will attempt to parse a grid square out of the DX spot comment field. (We should encourage DXers to always type the grid square as the first four characters, followed by a space!) If the grid square is absent or in the wrong format, APRS will use a table lookup of the callsign prefix to find the location of the station. So far, APRS does not parse 6 digit squares while in the DX mode.

• APRS captures the callsigns that the DX cluster is transmitting TO and adds them to the LATEST list. It also saves the latest packet from each station that it hears on the LATEST list, so that you can see what was the latest DX command issued by each connected user (that it can hear). These packets are NOT saved on the ALL page or LOGged.

• The DIGI USED screen is disabled and becomes the DX ACTIVE MAIL LIST. This page accumulates all listed mesages without duplication and sorts them in descending order just as if you had done a LIST command to the DX cluster; note that this MAIL list is NOT saved in any backup file, so it WILL BE LOST each time you run the program.

• All TALK traffic between DX cluster users is captured in the APRS TRAFFIC list.

• The CONTROLS-FILTERS-DX command permita selective filtering of the SPOTS you want to see, either HF, VHF or the default of ALL.

• The MAPS-PLOTS-CALLS command is activated which will plot the entire APRS data base of callsign prefixes on the map.

• The CONTROLS-CW menu allows you to set the CW speed and to enable the sending of the FREQUENCY in addition to the CALLS on all DX spots. The CW mode is always turned on in DXcluster mode, but can be silenced by selecting CONTROLS-cW-DISABLE, or setting alt-SETUP-OTHER-BEEPS to off.

WARNING: In order for APRS to keep up with the deluge of packets from a DX cluster, it is running wide-open with minimum filters and context checking. Sometimes it will make mistakes whenever a character string looks like a grid square report in just the right places. So take all plotted positions with a grain of salt... IE: do a sanity check...

IMPLEMENTATION: APRS users can immediately begin to use APRS to monitor DX cluster activity. For each conventional cluster user that drops his connection to the cluster and begins to use APRS in the monitor mode, there is a proportional reduction in the burden on the DX cluster. All users therefore see an overall improvement in channel capacity, while the cluster is still serving the same number of users! Of course, this improvement has a limit. If every single DX cluster user shifted to the monitor mode, then there would be no one still connected to assure that spots still got transmitted! The mimimum user number would probably be around 3. For Cluster SYSOPS, do not worry about losing your users. By running APRS, you will see eash station that is monitroing on APRS on your local map! In this respect, APRS is an improvement over other DX Cluster monitoring programs, because with its once every 15 minute POSIT report from each station, everyone sees everyone else that is monitoring! Just zoom in to the 64 mile range...

INTERIM OPERATIONS: If using APRS catches on in your area, one way to assure that at least 2 packets get transmitted for each DX spot or announcement is to have at least one distant user permanently remain connected to the cluster VIA an intermediate neighbor. Then each DX spot to that user is transmitted by the cluster, and then digipeated by the intervening user. In a similar manner, two such users on opposite sides of the cluster could extend the range of the cluster out 50 miles or more in each direction. Normally, DIGIpeating is a disaster for DX clusters because of the gross innefficiency of operating in a CONNECTED mode via a digipeater. DIGI's are NOT bad, however, for UI frames where no ACKS are required! If all of the DX cluster users dropped back to APRS monitoring except for the two connected stations (via two other monitoring stations acting as digi's) the number of actual packets transmitted for each spot would be only 4 packets and 4 acks, NO MATTER HOW MANY OTHER STATIONS WERE MONITORING THE SPOTS! Compare that with 20 packets normally required to support only 10 connected stations. Users needing any of the special DX features can still log on to the DX cluster, do their business, and then drop back off to monitor mode.

DX CLUSTER SYSOP ENHANCEMENTS: To facilitate the communication among the cluster users that are using APRS and to minimize the hidden-transmitter problem, the DX cluster (or central node serving the cluster) should have DIGI ON. Secondly, to encourage members to fall back to APRS monitoring mode, and to only connect to the cluster for specific information, the SYSOP should minimize the LOGGON text for its supporting members. This will make it easy and effecient for users to log on and off rapidly.

CONCLUSION: If some of the casual DX cluster users switched to APRS monitoring instead of remaining connected to the DX cluster, the burden on the DX cluster would be reduced to the benefit of everyone in the net. If your DX cluster is serving more than a dozen users, then you should consider shifting most casual users over to APRS monitoring. This could result in a ten fold increase in the efficiency of distributing DX spots. Of course, the DX cluster offers a lot more capability than just DX spots, so APRS will not ever replace the database capability of the DX cluster... But similarly, APRS offers several other advantages such as object tracking that can be useful for Hurricanes and mobiles. AND as monitoring APRS stations, their presence is still known by all stations on the net!

DXcalls.DAT FILE: This file is a list of CALL prefix, LAT, and LONG. You may update or change this file with a text editor, just be sure that the total number of entries stays below 450. Note that the list is scanned alphabetically and only the last prefix less-than or equal-to is used. An exact match is not needed. This eliminates the need for every prefix but does mean that EVERY callsign will get plotted, right or wrong... For US and VE calls, I have a separate algorithm that converts all A,K,N and W and VE calls to #N and *N and then simply looks up the NUMERIC field. To test your file, just use the MAPS-PLOTS-CALLS command.

FULL TIME APRS CO-CLUSTER: Since DX clusters users can only accumulate DX spots while they are operating, this often results in a new user wanting to do a SHOW/DX command to get caught up on the latest DX spots. This un- necessarily adds clutter to the channel. If one APRS station were to remain on line 100% of the time, his station would have collected all recent DX spots and using the normal APRS protocol, his station could be configured to repeat the most recent N DX spots as UI frames about one every minute or so.. This 1 packet every minute would provide a continuum of information so that stations could come and go, but at least be assured that after monitoring the channel for N minutes, they would have accumulated the last N DX spots! These 1 packet-per-minute's refreshes would occupy only a little more than 1% of channel capacity, but would keep ALL stations current, AND WOULD EVEN ELIMINATE THE NEED FOR ANY DUPLICATED PACKETS. This mode of APRS operation is called NETCONTROL. It is an un-documented feature whereby one APRS station can take over reporting responsibility for all POSITIONS on frequency. This means, that remote stations only need to report the location of an object once, and from then on, the NET CONTROL station will continue to report the position of that object, and the original station can go offline. This feature is undocumented, because it could lead to a mess if more than one station had it on at a time. Since this DX cluster application is the first real application for this mode, I can tell you how to turn it on, if anyone wants to try it. Also, the one packet per minute refresh is user selectable.

*** Remember, that monitoring APRS stations do not disappear! They will *** still be known to the DX cluster by their appearance on the APRS maps via their once every 15 minute status/position packet. This is NOT a burden! Even if there are 10 APRS monitoring stations, their 10 status packets over 15 minutes is still FAR FEWER packets than the 20+ packets PER DX SPOT normally required to update 10 logged on users.