try to prevent $myalias calls being set to nodes

[spider.git] / sgml / usermanual.sgml

<!doctype linuxdoc system>

<article>

<!-- Title information -->

<title>The DXSpider User Manual v1.51</title> 
<author>Ian Maude, G0VGS, (g0vgs@gb7mbc.net)</author>
<date>June 2004 revision 1</date>

<abstract>
A complete reference for users of the DXSpider DXCluster program.
</abstract>

<!-- Table of contents -->
<toc>

<!-- Begin the document -->

<sect>Introduction

<sect1>What is a DX Cluster?

<p>
A DX Cluster is a packet node where DX chasers on any band or mode can
post rare or interesting stations that they have worked or heard.  Of 
course other people are doing the same thing too, so you can find new 
DX as well as telling others about the stations you have worked.  
Clusters tend to be linked to each other so that the amount of people 
using them is increased, thereby increasing the amount of posted DX.  
Other information can be found on clusters such as on-line call books, 
mail etc.  You can talk to other stations connected to the cluster 
network too, in real time, whether at the node you are logged into or 
on another node connected to the network.  You can also use converse 
mode, where several stations can talk to each other in the same way.  
Of course, the DX is still posted to you all the while!
 
<sect1>So what is DXSpider?

<p>
PacketCluster nodes have been around since roughly 1985. The original 
PacketCluster idea came from Dick Newell, AK1A, and ran under DOS.
In about 1992 Dick stopped the development of the PacketCluster 
software for amateur radio. Many systems are still using this 
relatively old DOS software today.

There are several new compatible cluster programs around now, 
including DXSpider.  DXSpider is a clone of PacketCluster software that runs 
under several operating systems including Linux and Windows.  Linux is fast 
becoming the choice for amateur radio stations because of it's flexibility, 
reliability and the lack of the memory limitations of DOS.  Linux supports 
multitasking and is also multiuser. It has support for AX25, ROSE, 
NetROM and TCPIP built in, making it the ideal choice for amateur
radio.  It is also totally free!

DXSpider was conceived and begun in 1998 by Dirk Koopman, G1TLH as an
exercise in perl programming.  It has developed rapidly and today is a
very powerful cluster program.  It was designed to be totally compatible
with the AK1A program, although several commands have been extended to
improve functionality.

This manual is designed to help you become familiar with the commands
that DXSpider supports and to help you get the best from the program so 
you can enjoy working that rare DX!  As DXSpider is being improved all the 
time, commands will be added as time goes by, so make sure you have 
the most upto date version of this manual.  The latest version will
always be included with the cluster program so if you are unsure, simply
ask your sysop.  The manual will also be available on the wesite.


<sect>Logins and logouts.

<p>
You might not think that there is a lot of point of including a 
section on how to log in and out of DXSpider.  However, you would be 
suprised at the difficulties some people have in simply getting in 
and out of the cluster!

There are several ways a login might be achieved, dependant on how 
the sysop has DXSpider configured.  It is impossible for me to cover all 
variations but here are the basic ones.

<sect1>AX25 logins.

<p>
Simplicity itself.  The usual <bf>CONNECT</bf> command will log you straight
into the cluster and you will not have to do anything else.  
Obviously, you will have to connect to the correct callsign.  Some 
nodes use an SSID with their call so you would have to add that.

<bf>Examples:</bf>

<tscreen><verb>
connect GB7MBC
connect GB7MBC-1
</verb></tscreen>

<sect1>Netrom logins.

<p>
There are several possibilities here, dependant on how the sysop has
configured his system.  If you are connecting via netrom then you are
most probably connecting from another station.  Listing the nodes in
that station with the <bf>NODES</bf> command will tell you what callsign 
or netrom alias to connect to. Then just issue the connect command 
from there.  It is possible that the netrom alias may connect you to 
a node with an alias for the cluster, such as DXC.  Just type this 
and you will be connected.

<bf>Example:</bf>
<tscreen><verb>
connect MBCDX
</verb></tscreen>

<sect1>Telnet logins.

<p>
With telnet connections, the source callsign is not seen by DXSpider, so 
you will be asked to login with your callsign.  
To telnet to DXSpider, you would connect to a specific port.  There is no 
standard at the moment for a cluster telnet port but ask the sysop if 
you are unsure.

<bf>Example:</bf>

<tscreen><verb>
telnet gb7mbc 8000
</verb></tscreen>

All the above are possible ways of connecting to a DXSpider cluster.  You
may have some or all of these available to you.  There may be one or 
two additional ways to connect dependant on the network local to you.
However I am sure you get the idea.

<sect1>Logouts.

<p>
Logging out can be done by simply issuing the standard <bf>BYE</bf>
command.

You could also send a disconnect if you are using AX25, or a <bf>CLOSE</bf>
command if you are connected via telnet.
If you do not log out gracefully using one of the above commands, 
you may find you are unable to get a full connect next time.  This
may also happen if a netrom connection drops.  You may get connected, 
but nothing else will happen because the program thinks you are still 
connected and will not let you connect twice under the same call.  
However you could reconnect by adding a number to the end of your call,
for example G0YLM-2.  
This can be done by either altering your MYCALL setting in the TNC or 
by altering your program configuration.  


<sect>Setting your personal details.

<p>
Once logged in to the cluster, you should set your details so that 
anybody who wishes to contact you can find out who and where you are.
There are four items to set, your name, qth, location and home node.  
Setting these details also allows the use of the SHOW/HEADING and
SHOW/SUN commands from within the cluster.  Unless you set your QTH
and location, these commands cannot function.
Once you have set your name, DXSpider will greet you with it next time 
you login.  Your QTH setting is where you live and it is a good idea 
to add your locator to this as the location setting is converted to 
latitude and longitude once inputted.  You can actually set your location 
in latitude/longitude or as a locator.  Setting your home node will 
tell the program where you wish mail to be sent to you.

<bf>Examples:</bf>

<tscreen><verb>
set/name Ian
set/qth Morecambe, Lancashire IO84NB
set/location 48 34 n 12 12 e
set/qra IO84NB
set/home gb7mbc
</verb></tscreen>

<sect>Getting and posting DX.

<p>
When all is said and done, this is the main function of a DX cluster.
In its simplest form you can just connect to the node and you will 
start to receive DX spots almost immediately!  You can check on 
recent postings in either a general manner or on a particular band or
mode.  You can even check DX by callsign or a fragment of a callsign.
Of course, once you get the hang of things, it is expected that you 
start posting some yourself!  After all, there would be no clusters 
if people did not post DX and you get the added thrill of the hunt!

<sect1>Receiving DX.

<p>
As we have already said, it is possible just to connect to the 
cluster and you will receive spots automatically.  However, you may 
wish to check on spots just posted.  Maybe you wish to see if a 
particular band is open or if a certain callsign is active, perhaps a
DXpedition.  The command to do this is <bf>SHOW/DX</bf>.  Without any 
other arguments, this command will output the last 10 spots 
posted.  It is possible to look at more than this, for example the 
last 20 or 50 spots, by adding the number to the command.  You can 
make it even more specific by adding a band in either wavelength or 
frequency, and/or any additional information such as QSL details.

<bf>Examples:</bf>

<tscreen><verb>
show/dx
show/dx 5
show/dx 20
</verb></tscreen>

will show the last 10, 5 and 20 spots received by the cluster 
respectively.

<bf>Examples</bf>

<tscreen><verb>
show/dx on 20m
show/dx 10 on 20m
show/dx 20 on 20m
</verb></tscreen>

will show the last 5, 10 or 20 spots on 20 metres only.

It is also possible to check for certain callsigns, or fragments of 
callsigns in the same way.

<bf>Examples:</bf>

<tscreen><verb>
show/dx g0vgs
show/dx 10 g0vgs
</verb></tscreen>

would show the last 5 or 10 dx spots containing the callsign g0vgs.

<p>
You can check for DX by offset and also by specifying a comment to 
search for.

<bf>Examples:</bf>

<tscreen><verb>
show/dx 30-40
show/dx 14000-14033
show/dx iota
</verb></tscreen>

would show the spots that arrived between 30 and 40 spots ago and any 
spots with the word <em>iota</em> in the comment field.  The case of 
the comment is not important.
 
Checking DX posted on a certain day is possible too.  All you have
to do here is to specify how many days ago it was like this ...

<bf>Example:</bf>

<tscreen><verb>
show/dx day 30 
</verb></tscreen>

It is of course possible to specify multiple arguments.

<bf>Example:</bf>

<tscreen><verb>
show/dx 20 prefix 9a on vhf day 30
</verb></tscreen>

This would show the last 20 spots posted by or about calls with the prefix
9a on vhf 30 days ago.

As you can see the <bf>SHOW/DX</bf> command is very flexible, so if you are
not sure whether something will work or not, try it and see!  More
information can be found in the Command Set section.

<sect1>Posting DX.

<p>
To post DX you use the <bf>DX</bf> command.  The syntax is shown below. 

<bf>Example:</bf>

<tscreen><verb>
dx (frequency) (callsign) (remarks)
</verb></tscreen>

Where frequency is in kilohertz and the callsign is the callsign of
the station you have worked or heard, (ie not your own callsign!).  
The remarks section allows you to add information like the operators 
name or perhaps a location.  Actually DXSpider will allow the frequency
and callsign fields to be entered in any order.

<bf>Example:</bf>

<tscreen><verb>
dx 14004 pa3ezl OP Aurelio 599
</verb></tscreen>

In fact, all the following will give the same result...

<tscreen><verb>
dx 14004 pa3ezl OP Aurelio 599
dx pa3ezl 14004 OP Aurelio 599
dx pa3ezl 14.004 OP Aurelio 599
</verb></tscreen>

This posting, or callout as it is known, will be forwarded to all 
other connected stations both at the cluster you are connected to and
other active clusters in the network.  The callout will also be sent 
to you as proof of receipt. 
 
<sect>Headings and propagation

<p>
There are three commands in DXSpider to help you get the best DX possible.
These are <bf>SHOW/SUN</bf>, <bf>SHOW/MOON</bf> and
<bf>SHOW/HEADING</bf>.  These commands will only work for you if you
have entered your personal details.  They use your entered location as
a reference, so if you have not entered it or have entered it incorrectly
they will not return the correct information.

<sect1>Sun

<p>
The <bf>SHOW/SUN</bf> command can be used in three different ways.  It
can be used to show sunrise and sunset times for your own station, a 
particular callsign or a prefix.  

<bf>Example:</bf>

<tscreen><verb>
show/sun
</verb></tscreen>

The output from this would look something like this ..

<tscreen><verb>
sh/sun
Location                              Rise   Set      Azim   Elev
G0VGS  Morecambe, Lancashire          07:08Z 17:39Z  205.3   24.1
</verb></tscreen>

<tscreen><verb>
sh/sun 5b4
</verb></tscreen>

would look like this ...

<tscreen><verb>
sh/sun 5b4
Location                              Rise   Set      Azim   Elev
5B     Cyprus-5B                      04:23Z 15:40Z  244.0   18.8  
</verb></tscreen>

You can also specify multiple arguments like this ...

<tscreen><verb>
sh/sun gw4veq 5b4ab zs
</verb></tscreen>

and then the output would look like this ...

<tscreen><verb>
sh/sun gw4veq 5b4ab zs
Location                              Rise   Set      Azim   Elev
GW4VEQ Brungwran, Isle of Anglesey IO 07:14Z 17:48Z  204.9   24.9
5B     Cyprus-5B                      04:23Z 15:40Z  244.5   18.3
ZS     So-Africa-ZS1-ZS               04:31Z 17:28Z  289.9   41.3
ZS     So-Africa-ZS5-ZS               03:44Z 16:34Z  278.5   32.0
ZS     So-Africa-ZS6-ZS               03:59Z 16:42Z  277.6   35.0 
</verb></tscreen>

<sect1>Moon

<p>
The <bf>SHOW/MOON</bf> command works in the same way as the 
<bf>SHOW/SUN</bf> command.  This program however, calculates the
rise and set times of the moon for a prefix or callsign, together
with the current azimuth and elevation of the sun at these
locations.

<bf>Example:</bf>

<tscreen><verb>
show/moon ea
</verb></tscreen>

The output from this command would look like this ..

<tscreen><verb>
sh/moon ea
Location                              Rise   Set      Azim   Elev  RGain dB
EA     Spain-EA                       08:15Z 20:09Z  257.2    9.5      -0.6  
</verb></tscreen>
 
You can see that the output is similar to the <bf>SHOW/SUN</bf>
command, with slightly different fields.

<sect1>Heading

<p>
The <bf>SHOW/HEADING</bf> command works in the same way as the 
<bf>SHOW/SUN</bf> and <bf>SHOW/MOON</bf> commands but outputs beam 
headings for a specified callsign or prefix.  Reciprocal beam headings 
are also calculated.

<bf>Example</bf>

<tscreen><verb>
show/heading zl
</verb></tscreen>

The output from this command would look like this ..

<tscreen><verb>
sh/heading zl
ZL New-Zealand-ZL1-ZL: 7 degs - dist: 11238 mi, 18087 km Reciprocal heading: 355 degs
ZL New-Zealand-ZL2-ZL: 9 degs - dist: 11540 mi, 18574 km Reciprocal heading: 353 degs
ZL New-Zealand-ZL3-ZL: 19 degs - dist: 11634 mi, 18724 km Reciprocal heading: 345 degs
ZL New-Zealand-ZL4-ZL: 34 degs - dist: 11783 mi, 18963 km Reciprocal heading: 332 degs
</verb></tscreen>

<sect>Announcements.

<sect1>Making announcements.

<p>
Occasionally, you may wish to post something that does not fall into 
the normal parameters for a DX callout.  You may wish to tell 
everybody connected that 10 FM is open for example, or ask if anyone 
knows the QSL manager for a certain callsign etc.  You can do this 
using the <bf>ANNOUNCE</bf> command.

<bf>Example:</bf>

<tscreen><verb>
announce 10 FM is open in IO84NB to europe.
</verb></tscreen>

That would let everyone know locally that this was the case, however
it would not be forwarded to other nodes connected.  To send
announcements to other connected nodes as well, you would use the
<bf>FULL</bf> extension.

<bf>Example:</bf>

<tscreen><verb>
announce full Anyone seen EA7WA today?
</verb></tscreen>

Be cautious in your use of announce full.  There are many other tools
available to get the information you require and the judicious use of
this command is frowned upon as it creates a great deal of traffic
across the network.

<sect1>Listing announcements.

<p>
You can list previous announcements in the standard format with the 
<bf>SHOW</bf> command.  As before you can list just the last 5 or as 
many as you wish.

<bf>Example:</bf>

<tscreen><verb>
show/announcements
show/announcements 10
</verb></tscreen>

<sect>Nodes and users.

<p>
You can check which nodes are connected in the network, who is 
logged on locally, who is logged on at all the nodes or even 
just one node in particular. This is handy if you wish to see whether
a friend is connected at the node they use.  To see who is connected 
to the nodes, the <bf>SHOW/CONFIGURATION</bf> command is used.

<bf>Example:</bf>

<tscreen><verb>
show/configuration
show/configuration/nodes
show/configuration (node_call)
show/configuration (prefix)
</verb></tscreen>

The first of our three examples would output something like this,

<tscreen><verb>
sh/c
Node         Callsigns
EI5TCR       (7 users)
GB7ADX
GB7BAA       G4FPV        G8TIC
GB7BIG       (GD0TEP)     GD3UMW
GB7BPQ       (G0INA)      G0RCI        G3AKU        G3OCA
(GB7CDX)     G3JNB        G4ALR
GB7DJK       G0FYD        G0REK        G1TLH        G4PEL        G4SOZ
             G4TVR        G7SQW        K8AZ         M0CTQ-1      MM1CXE-10
             ON7WP
GB7DXA       G0RDI        G8SJP
GB7DXC       (G0HDB)      G0WFK        (G1FYC)      G3KWK        G3LME
             G3OIL        G4BGW        G4FUJ        (G4PDQ)      GW7SMV
GB7DXE       G1NNB
(GB7DXG)     GU6EFB       GU7DHI
GB7DXK       G1NTW        G3IBI        G3NSM        G3XAQ        G4CUS
             G4XQY        G7GAN
GB7DXM       G1EUC        G3GAF        G3LAS        G4ZTR        G8WXU
             M0BCT        M1EMF
</verb></tscreen>

You will notice that EI5TCR is showing only that it has 7 users and not
giving the actual callsigns.  This means that this node is on a limited
protocol of some kind, probably because of a contest situation where
slow radio links can block up and fail if too much information is sent
between nodes.

The second example would just show the nodes connected in the
network, like this,

<tscreen><verb>
sh/c/n
Node         Callsigns
GB7BAA       GB7BAA       GB7BPQ       (GB7CDX)     GB7DJK       GB7DXA      
             GB7DXC       GB7DXE       (GB7DXG)     GB7DXK       GB7DXL      
             GB7DXM       GB7DXS       GB7IPT       GB7MRS       GB7UJS      
             GB7YDX       KL7G         N2TLY        (ON0DXK)                 
GB7BIG       EI5TCR       GB7ADX       GB7BIG       GB7UDX                   
GB7MBC                                                                       
PA4AB-14     PA4AB-14                                                        
PI4TUE-8     PI4TUE-8    
</verb></tscreen>

If we insert the node_call pi4tue-8 into the third example, then
this would be the output,

<tscreen><verb>
Node         Callsigns
PI4TUE-8     9A1CMA-6     DF6PW        DL4FAY       DL4KAK       DL4WF-2     
             F5NOD-2      F5PAC        IZ0CSR       N6CR         OH2BLD      
             ON1LVL-13    ON4CBT       ON4CJP       ON5DXL-14    ON7NQ       
             PA0RCT       PA3DYS       PA3FDO       PA5KW-4      PI4TUE-9    
             YT1XX        
</verb></tscreen>

As you can see, only the users of the requested node are shown.

You can also use a prefix to show only a group of nodes.  For example
you may only wish to see who is connected to the nodes in the UK.  To
do this simply use a prefix like this ...

<verb>
show/configuration gb7
</verb>

To show the locally connected users, the <bf>SHOW/USERS</bf> command is
used

<bf>Example:</bf>

<tscreen><verb>
show/users
</verb></tscreen>

The output of this command would look like this,

<tscreen><verb>
Callsigns connected to GB7MBC
G0JHC        G0NEI        G0VGS        G0VGS-2      G0YLM                    
G3JAG        G3OWO        G3UEU
</verb></tscreen>

<sect>Talk mode.

<p>
You can send a single comment or start a dedicated talk session to 
another user by using the <bf>TALK</bf> command. 

<p>
Talk mode is used to send a one line comment or greeting to a 
specific user connected either at your node or another in the 
network.  You can also enter into a dedicated talk session with 
another user.  Talks will be automatically forwarded to other nodes 
if the station you are talking to is not connected locally. 
You can find out who is connected by using the 
<bf>SHOW/CONFIGURATION</bf> command, (described earlier).

<bf>Examples:</bf>

<tscreen><verb> 
talk g0rdi Having a good day Iain?
</verb></tscreen>

This example would send the line "Having a good day Iain?" to the
user g0rdi but would leave you in normal mode.  

<tscreen><verb>
talk g0rdi
Entering Talkmode, /EX to end, /<cmd> to run a command
Talk (G0RDI)>
</verb></tscreen>

As you can see, you can still run commands whilst in talk mode.
Simply prefix the command with a / like /sh/dx and you will get
the expected output.
If the user is connected to another node, you may have to use a 
slightly extended version of the <bf>TALK</bf> command.

<tscreen><verb>
talk g0rdi > gb7djk
</verb></tscreen>

To exit talk mode, you issue the command <bf>/ex</bf>. 

Whilst in talk mode you will still receive DX spots.  This means that
you can chat to a friend whilst working DX.  

<sect>Mail.

<p>
You can send and receive both personal mail and bulletins with DXSpider 
quite easily.

<sect1>The "directory" command.

<p>
To list mail you would use the <bf>DIRECTORY</bf> command.  On its 
own, this command will output the last ten messages received by the 
node, either to or from yourself or bulletins such as "DX" and "ALL".
As with other commands you can display more by specifying a number 
with the command.  You should be aware that Spider will accept
these commands by separating with either a slash or a space, so
<em>dir new</em> and <em>dir/new</em> work in the same way.

<bf>Example:</bf>

<tscreen><verb>
directory
directory/20
directory 20
</verb></tscreen>

Of course most of the time you will only want to list new mail sent 
to you personally since your last login.  However you might also like 
to check for general mail received by the node.  In fact if there is 
new mail for you, the cluster will tell you when you login. You will 
also be informed if new mail arrives for you during the time you are 
logged in.
Mail is not only sent to callsigns though.  Mail can also be sent to 
subjects like "all" or "local" or "dx" etc.  You can treat these 
bulletins in the same way as personal mail with the directory 
command.

<bf>Examples:</bf>

<tscreen><verb>
directory/new
directory/own
directory/own/10
directory/all
directory/from <call>
</verb></tscreen>  

The last option will only show mail from a callsign if it was sent to
you personally or was sent as a bulletin.  There are some additional
commands and these can be found in the DXSpider Command Reference section.

<sect1>Reading mail.

<p>
The output of the <bf>DIRECTORY</bf> command could be something like 
this.

<tscreen><verb>
dir
 20735      2      ALL   GW7SMV 21-Feb 1204Z REC 9E1S QSL TDY 50Mhz....    
 20823    308       UK    G0HDB 22-Feb 2334Z Help - which district code?   
 20824    105      ALL     W9AE 23-Feb 0349Z S0NY QSL address?             
 20825      2       UK    G0LRJ 23-Feb 0806Z QSL REC LZ2CJ/1.CARD NO-750.  
 20858      2      ALL   GW7SMV 24-Feb 0905Z REC S92DX QSL CARD TDY 50Mhz  
 20921    200      ALL   GM4FDM 27-Feb 2203Z Trip to VP8                   
 20949    375      ALL     K0MN 27-Feb 0428Z ST0P cards are gd @ ARRL      
 20950      2       UK    G0LRJ 28-Feb 0835Z QSL REC SV9/IZ0CKJ/P EU-187.  
 20987    569      ALL   GD0TEP  1-Mar 1733Z Portable contests             
 21076      2      ALL    G4AFJ  3-Mar 1743Z kh6nd/kh5 qsl received
 21184-p  599   GW4HAT    G0VGS  4-Mar 1518Z Re: Time 
</verb></tscreen>

The first column is the actual message number.  If the message is a
personal one to you, you will see a letter 'p' after this number.  If
the message has been read, there will be a '-' between the message
number and the 'p'.  This only works for personal messages.  The next
column shows the file size of the message.  The third column shows the
address the message was sent to and the next column shows who sent it.
The rest is fairly self-explanatory.

Reading a message is as simple as typing read, followed by the 
message number that you wish to read.

<bf>Example:</bf>

<tscreen><verb>
read 25
</verb></tscreen>

will read message number 25.  However the mail will be displayed in it's
entirety unless you specify a page length. You can set your page length
to any number you like and when the message reaches that number of lines
you will get a prompt giving you options.

<bf>Example:</bf>

<tscreen><verb>
set/page 20
</verb></tscreen>


<sect1>Sending mail.

<p>
Sending mail is done in the time honoured way.  First you specify
a recipient for the message, then you will be prompted for a subject.
Once you have done this you will be asked to type your message.
Please remember that there is no automatic word wrap, so unless you
are using a client that wraps lines automatically, remember to hit
return at the end of each line.

<bf>Example:</bf>

<tscreen><verb>
send m0azm
Enter Subject (30 characters):
See you Thursday
Enter Message /EX to send or /ABORT to exit
Hi Ian,            
Just a quick note to say that I can make Thursday after all.  The
appointment I had has cancelled so we are go!
Cheers
Ian
</verb></tscreen>

At this point you can either hit return and enter /ex to send the
message or use /abort at any time to abort it.  You can now display
the message in the normal way.  There are several send options and 
these are listed in the Command Set section.  These include sending
mail to several recipients and asking for a return receipt.


<sect1>Replying to mail.

<p>
If mail is addressed to you or to a bulletin address, you can use the
<bf>REPLY</bf> command to reply to it.  Using this command, the 
subject will be automatically set for you as "Re: subject", whatever 
the subject was. 
 
<bf>Example:</bf>

<tscreen><verb>
reply 2500
</verb></tscreen>

<sect1>Deleting mail

<P>
To delete a message, you use the <em>delete</em> command.
You can only delete messages sent to or received by yourself.  
Bulletins are dealt with automatically or by the sysop.

<sect>Filtering (From version 1.45)

<sect1>General filter rules

<P>
Upto v1.44 it was not possible for the user to set their own filters.  From 
v1.45 though that has all changed.  It is now possible to set filters for just 
about anything you wish.  If you have just updated from an older version of 
DXSpider you will need to update your new filters.  You do not need to do 
anything with your old filters, they will be renamed as you update.

<P>
There are 3 basic commands involved in setting and manipulating filters.  These 
are <em>accept</em>, <em>reject</em> and <em>clear</em>.  First we will look
generally at filtering. There are a number of things you can filter in the 
DXSpider system. They all use the same general mechanism.

<P>
In general terms you can create a 'reject' or an 'accept' filter which can have 
up to 10 lines in it. You do this using, for example ... 

<tscreen><verb> 
accept/spots .....
reject/spots .....
</verb></tscreen>

where ..... are the specific commands for that type of filter. There are
filters for spots, wwv, announce, wcy and (for sysops) connects. See each 
different accept or reject command reference for more details.

There is also a command to clear out one or more lines in a filter. They are ...

<tscreen><verb>
clear/spots 1
clear/spots all
</verb></tscreen>

There is clear/xxxx command for each type of filter.

<P>
and you can check that your filters have worked by the command ... 

<tscreen><verb>  
show/filter
</verb></tscreen>

<P>
For now we are going to use spots for the examples, but you can apply the same
principles to all types of filter.

<sect1>Types of filter

<P>
There are two main types of filter, <em>accept</em> or <em>reject</em>.  You 
can use either to achieve the result you want dependent on your own preference 
and which is more simple to do.  It is pointless writing 8 lines of reject 
filters when 1 accept filter would do the same thing!  Each filter has 10 
lines (of any length) which are tried in order.  If a line matches then the 
action you have specified is taken (ie reject means ignore it and accept 
means take it)

<P>
If you specify reject filters, then any lines that arrive that match the filter 
will be dumped but all else will be accepted.  If you use an accept filter, 
then ONLY the lines in the filter will be accepted and all else will be dumped.
For example if you have a single line <em>accept</em> filter ...

<tscreen><verb>
accept/spots on vhf and (by_zone 14,15,16 or call_zone 14,15,16)
</verb></tscreen>

then you will <em>ONLY</em> get VHF spots <em>from</em> or <em>to</em> CQ zones 
14, 15 and 16.

<P>
If you set a reject filter like this ...

<tscreen><verb>
reject/spots on hf/cw
</verb></tscreen>

Then you will get everything <em>EXCEPT</em> HF CW spots.  You could make this 
single filter even more flexible.  For example, if you are interested in IOTA 
and will work it even on CW even though normally you are not interested in 
CW, then you could say ...

<tscreen><verb>
reject/spots on hf/cw and not info iota
</verb></tscreen>

But in that case you might only be interested in iota and say:-

<tscreen><verb>
accept/spots not on hf/cw or info iota
</verb></tscreen>

which achieves exactly the same thing. You should choose one or the other 
until you are comfortable with the way it works. You can mix them if you 
wish (actually you can have an accept AND a reject on the same line) but 
don't attempt this until you are sure you know what you are doing!

<P>
You can arrange your filter lines into logical units, either for your own
understanding or simply convenience. Here is an example ...

<tscreen><verb>
reject/spots 1 on hf/cw
reject/spots 2 on 50000/1400000 not (by_zone 14,15,16 or call_zone 14,15,16)  
</verb></tscreen>

What this does is to ignore all HF CW spots and also rejects any spots on VHF 
which don't either originate or spot someone in Europe. 

<P>
This is an example where you would use a line number (1 and 2 in this case), if 
you leave the digit out, the system assumes '1'. Digits '0'-'9' are available.  
This make it easier to see just what filters you have set.  It also makes it 
more simple to remove individual filters, during a contest for example.

<P>
You will notice in the above example that the second line has brackets.  Look 
at the line logically.  You can see there are 2 separate sections to it.  We 
are saying reject spots that are VHF or above <em>APART</em> from those in 
zones 14, 15 and 16 (either spotted there or originated there).  If you did 
not have the brackets to separate the 2 sections, then Spider would read it 
logically from the front and see a different expression entirely ...

<tscreen><verb>
(on 50000/1400000 and by_zone 14,15,16) or call_zone 14,15,16 
</verb></tscreen>

The simple way to remember this is, if you use OR - use brackets. Whilst we are 
here CASE is not important. 'And BY_Zone' is just the same as 'and by_zone'.

As mentioned earlier, setting several filters can be more flexible than 
simply setting one complex one.  Doing it in this way means that if you want 
to alter your filter you can just redefine or remove one or more lines of it or 
one line. For example ...

<tscreen><verb>
reject/spots 1 on hf/ssb
</verb></tscreen>

would redefine our earlier example, or 

<tscreen><verb>
clear/spots 1
</verb></tscreen>

To remove all the filter lines in the spot filter ...

<tscreen><verb>
clear/spots all
</verb></tscreen>

<sect1>Filter options

<P>
You can filter in several different ways.  The options are listed in the
various helpfiles for accept, reject and filter.

<sect1>Advanced filtering

<P>
Once you are happy with the results you get, you may like to experiment. 

<P>
The previous example that filters hf/cw spots and accepts vhf/uhf spots from EU 
can be written with a mixed filter, for example ... 

<tscreen><verb>
rej/spot on hf/cw
acc/spot on 0/30000
acc/spot 2 on 50000/1400000 and (by_zone 14,15,16 or call_zone 14,15,16)
</verb></tscreen>

Note that the first filter has not been specified with a number.  This 
will automatically be assumed to be number 1.  In this case, we have 
said <em>reject all HF spots in the CW section of the bands but accept 
all others at HF.  Also accept anything in VHF and above spotted in or 
by operators in the zones 14, 15 and 16</em>.  Each filter slot actually 
has a 'reject' slot and an 'accept' slot. The reject slot is executed 
BEFORE the accept slot.

<P>
It was mentioned earlier that after a reject test that doesn't match, the 
default for following tests is 'accept', the reverse is true for 'accept'. 
In the example what happens is that the reject is executed first, any non 
hf/cw spot is passed to the accept line, which lets through everything 
else on HF.  The next filter line lets through just VHF/UHF spots from EU.

<sect1>A Filtering Tutorial

<P>
There is now an excellent primer/tutorial on filtering written by Jim
Samuels, W3BG with an introduction by Dave Hawes N3RD that I strongly
suggest you read.  You can read it here
<htmlurl url="filtering_en.html" name="The DXSpider User Filtering Primer">

<sect>Hints, tips and common questions.

<p>
<bf/Q./These commands seem very long!  Can I shorten them?

<bf/A./Of course you can and the usual abbreviations work.  If you
are unsure, try it. 

<bf/Q./I am not sure if this command is correct.  Can I cause any
harm if I try it?

<bf/A./Do not be afraid to try a command to see if it will work,
at the worst you will get an error message.  If you require any
help on a command, just type help followed by the command you
want help on.  Look at the "DXSpider Command Reference" section to see 
what help can be found.

<bf/Q./How should I use the announce command?

<bf/A./With respect.  Use the command by all means, but please
only use the "full" extension if absolutely necessary.  It can 
create a LOT of messages passing between clusters.

<bf/Q./I like to be working in the shack while logged into the
cluster but I can't be looking at the screen all the time. How
can I be alerted when anything happens?

<bf/A./Use the <bf>SET/BEEP</bf> command.  You can find information 
on this in the "DXSpider Command Reference" section.

<bf/Q./I got disconnected from the cluster and now I can't log
back in again.  What is wrong?

<bf/A./Probably the cluster thinks you are still logged on and
will not let you reconnect using the same call to prevent loops.
Try logging on again adding an ssid to your callsign as DXSpider
treats G0YLM and G0YLM-1 as different users.

<bf/Q./How do I know if I have got the latest version of this
user manual?

<bf/A./The latest and greatest will always be on the Website.  It will
also be included with every release of DXSpider.  As always, if unsure,
ask your sysop what version number is the latest. 

<sect>The DXSpider Command Reference