hamradio/spider
1
0
Fork 0
mirror of git://scm.dxcluster.org/scm/spider synced 2024-09-21 15:57:12 +00:00
Code Issues Packages Projects Releases Wiki Activity
b91c265007
spider/sgml/usermanual.sgml

1012 lines
33 KiB
Plaintext
Raw Normal View History

minor corrections to manuals
2003-03-28 16:43:25 +00:00
<!doctype linuxdoc system>
<article>
<!-- Title information -->
<title>The DXSpider User Manual v1.50</title>
<author>Ian Maude, G0VGS, (g0vgs@gb7mbc.net)</author>
<date>March 2003 revision 0.3</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.
<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.
Reference in New Issue Copy Permalink