README.DX               USING APRS FOR MONITORING DX CLUSTERS



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.  Packet clusters,
like all packet networks cost a lot to build and maintain.  Users of these
facilities should be encouraged to support these assets.  I have been
involved in packet for 14 years and have operated a VHF/HF BBS and several
NODES for most of that time.  I had heard of DX clusters for years, but
ignored them, because I am NOT a DX hound.  But after logging on to the
PVDXSN DX cluster (my first time ever!) just two weeks ago, you can see how
I am hooked!  I joined immediately!  and APRS505 is the result.  I see more
action on my APRS map in an evening on the DX cluster than I usually saw in
a week on our rather broad area APRS network!  In addition, unlike other
monitoring programs which are totally passive, APRS users will see each
other, so you can tell who all is out there just monitoring the cluster


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 and maintains a list of all recent DX spots.  The user can review
these spots at will.  Secondly, the DX spot is plotted on the map either by
callsign prefix or by gridsquare if given as the first four letters of the
comment field.  Thirdly, since APRS observes all of the redundant spot
transmissions to all users, it can accumulate a list of DX cluster users
after hearing only one spot report!  In version 505e, additional monitoring
includes WX and WWV spots, plus ANNOUNCEMENTS, accumulation of an ACTIVE MAIL 
LIST, and collection of user-to-user TALKs, plus sounding out prefixes in CW
and plotting SHOW/STATION locations.


RELIABILITY:  Although the APRS user will probably capture the DX spot on the
very first transmission, it can be easily shown that he has an equal, if not
better, probabliily of GUARANTEED delivery as the connected users.  If there
are 10 users logged onto the DX cluster, then an APRS user monitoring the
channel sees 10 duplicate transmissions.  Similarly, a connected station
running typical TNC defaults only gets 10 attempts before he times out, so he
has no better chance than the APRS user to see the packet.  In fact, if there
are two connected stations having RF problems, then the APRS user could see
as many as 28 duplicate transmissions of the spot giving him an almost 3 to
one advantage over any connected station!


APRS DX OPERATIONS:  To operate APRS in the DX mode, simply select the DX
mode using the dX (X) command under the CONTROLS menu.  All APRS functions
continue to operate in the usual manner, but with the following exceptions.

   First, 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.

   Secondly, it saves all DX SPOTS 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.

   Third, the normal use of the ALL list is disabled so you will NOT accumulate
a log of APRS beacons. 

   Fourth, 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!)  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. 

   Fifth, 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). 

   Sixth, 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. 

   Seventh, all TALK traffic between DX cluster users is captured in the APRS
READ-MAIL list.

To exit DX mode and return to normal APRS BEACON or OTHER monitoring, simply
select one of these other modes under the CONTROLS menu.  The DX mode is
saved as part of the CONFIG file, so registered users can always start up in
the DX mode if desired.

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.
This is so that it can try to parse all packets for Position reports, grid
squares, mail, talkmode, etc.  The problem is, that it will make mistakes
whenever a character string looks like a grid square report in just the right
places; and worse, there are some fields that can cause CRASHABLE errors.  I
could have added a lot more filters to eliminate false parsing, but this
would slow processing down significantly and probably make slower machines
CHOKE on all the packets flying out of a DX cluster.  So take all plotted
positions with a grain of salt...  IE: do a sanity check...  In the APRS
portocol, only grid squares surrounded in brackets are used, but on DX
clusters, I had to assume that the brackets would not be there.  ALso, I
have not yet finished the full PREFIX data base, so many errors on prefix
plotting should be expected...


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!


CALLSIGN LOCATOR:  The first night that I monitored the DX cluster, I was so
excited about using the grid square plotter built into APRS because most of the
DX spots contained Grid numbers.  Two days later when I was ready to release
5.05 I noticed that all evening long, there were NO GS reports!  Seems that
only VHF'ers use GS, and I just happened to be listening that first day,
during some sporadic E...  Therefore, I had to quickly make a callsign prefix
table so that geographic location could be derived from callsign alone.  This
file is named DXCALLS.DAT and is just a list of CALL prefix, LAT, and LONG.
It was just a start, and only contained 120 entries in version 5.05.  In
505a, I increased the permissible array size to accommodate a list up to
350 entries long.  Keith Sproul, WU2Z (MacAPRS) , is now developing a more 
complete file and it should be ready by the next version after 505e.  Note 
that anyone can update or change this file with a DOS text editor, just be
sure that the total number of entries stays below 350.  Also note that
the list is scanned alphabetically, so an exact match is not required.  The 
last prefix less-than or equal-to is used.  This eliminates the need to have
separate entries for PP, PQ, PR etc.  But it does mean that EVERY callsign
will get plotted, and in the wrong place if there is not an appropriate
match.  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.

DEFAULT MAP:  Notice that when you select DX cluster mode, APRS automatically
sets the default map to the middle of the Atlantic to favor the East Coast
guys.  To customize the map to your favorite center, simply move the cursor
and hit HOME key.  Then save a CONFIG file which will remember that setting.


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.  Even if there are 10 APRS
monitoring stations, their 10 status packets spread over 15 minutes is still
FAR FEWER packets than the 20+ packets PER DX SPOT normally required to
update 10 logged on users.  Lets join forces!  Combining the power and 
resources of the DX cluster with the channel effeciency and graphics of APRS 
is a perfect marriage!


REVISIONS:  Version 505c added ACTIVE MAIL LIST capture, ANNOUNCEMENTS capture,
TALKS capture, and increased the callsign prefix data base size to 350 from
150 to accommodate the DXCC calls list. (Better plotting of stations based on
calls only).  I also improved the Grid Square reporting appearance on the map
and now sound out in CW the grid square or the callsign prefix on any new 
spots.  By just listening to the prefixes, you can decide whether you need to 
look over at the PC screen or not.  Talk about arm-chair operating!  505b had 
a bug that prevented normal APRS monitoring of beacons while in the DX mode.  
505c also added a DX spot filter so that you can select VHF, HF or ALL spots.  
Then I learned that AEA TNC's must have MON 2 or they will not see ANY DX 
cluster packets (connected).  That lead to 505d.  505e adds WWV and WX spots 
to the SPOT list and now captures the location of any station in a SHOW/STA
response.

