mirror of
git://scm.dxcluster.org/scm/spider
synced 2024-09-21 15:57:12 +00:00
209 lines
8.0 KiB
HTML
209 lines
8.0 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
|
|
<HTML>
|
|
<HEAD>
|
|
<META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.21">
|
|
<TITLE>The DXSpider User Filtering Primer v1.0: Types of spot filters used in DXSpider </TITLE>
|
|
<LINK HREF="filtering_en-5.html" REL=next>
|
|
<LINK HREF="filtering_en-3.html" REL=previous>
|
|
<LINK HREF="filtering_en.html#toc4" REL=contents>
|
|
<link rel=stylesheet href="style.css" type="text/css" title="default stylesheet">
|
|
</HEAD>
|
|
<BODY>
|
|
<A HREF="filtering_en-5.html">Next</A>
|
|
<A HREF="filtering_en-3.html">Previous</A>
|
|
<A HREF="filtering_en.html#toc4">Contents</A>
|
|
<HR>
|
|
<H2><A NAME="s4">4.</A> <A HREF="filtering_en.html#toc4">Types of spot filters used in DXSpider </A></H2>
|
|
|
|
<P>Basic filter types are "accept", "reject", and "clear" where the following
|
|
applies ...</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
Reject filters - any spots that match will be dumped, all others passed on.
|
|
Accept filters - any spots that match are passed on, all others are dumped.
|
|
Clear filters - the filter slot(s) referenced will be cleared from the filter
|
|
repository
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
<P>For the most part we will use only reject and accept filters. These are the main
|
|
filter types. Basically, reject means dump it and accept means take it and pass
|
|
it on to the user. By nature, accept filters are more powerful than reject
|
|
filters. A user can generally do with a one line accept rule what it could take
|
|
many lines of reject rules to accomplish. However, the flip-side of this
|
|
statement is that a series of reject filters are usually easier to administer
|
|
and change.</P>
|
|
|
|
<H2><A NAME="ss4.1">4.1</A> <A HREF="filtering_en.html#toc4.1">Numbering lines and slots </A>
|
|
</H2>
|
|
|
|
<P>There are ten usable filter slots in DXSpider. Each slot holds one reject and
|
|
one accept rule. Therefore, each type filter can have up to ten lines of rules
|
|
contained in these ten slots. The filter rules must be numbered sequentially,
|
|
that is, 0-9 lines of reject filter rules and 0-9 lines of accept filter rules
|
|
to correspond to their respective slot position. If no number is used, every
|
|
line is assumed to be in slot 1 and the addition of a second filter line of the
|
|
same type without a number will just over-write the first that was previously
|
|
written to slot 1. (Why not slot 0? I don't know. This is the way it works.)</P>
|
|
|
|
<P><EM>Important:</EM> The filter rules are applied in sequence, i.e., 0-9. If a
|
|
line matches, action is taken on that line. The filter sequence acts on rules
|
|
in the order listed. It acts on the reject filter in each slot before acting
|
|
on the accept filter contained in that slot. If the slot is completely blank or
|
|
if a reject or accept filter line is missing in that slot it skips right over
|
|
to the next filter rule in the sequence. A picture of a filter set might look
|
|
like this ...</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
Execution Sequence Slot Number Filter Rule
|
|
1 Slot0 reject/spot 0 <pattern>
|
|
2 accept/spot 0 <pattern>
|
|
3 Slot1 reject/spot 1 <pattern>
|
|
4 accept/spot 1 <pattern>
|
|
5 Slot2 reject/spot 2 <pattern>
|
|
6 accept/spot 2 <pattern>
|
|
. .
|
|
19 Slot9 reject/spot 9 <pattern>
|
|
20 accept/spot 9 <pattern>
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="ss4.2">4.2</A> <A HREF="filtering_en.html#toc4.2">Reject before accept</A>
|
|
</H2>
|
|
|
|
<P>This is not a good rule for life, but it makes sense for DXSpider filters. As
|
|
a general rule, reject filter rules within a slot are always executed before
|
|
accept filter rules. There is a very good reason for this. If a spot doesn't
|
|
match a reject filter, the spot is passed to the next filter line in the set.
|
|
However, if a spot matches an accept filter, it is sent immediately to the user.</P>
|
|
|
|
<H2><A NAME="ss4.3">4.3</A> <A HREF="filtering_en.html#toc4.3">Using Multiple Reject Filter Rules</A>
|
|
</H2>
|
|
|
|
<P>Another important concept to know is that you can do everything you want to do
|
|
with multiple reject filters AND NO ACCEPT FILTERS. By default, if a spot
|
|
doesn't match any of the reject filter definitions, then the system considers
|
|
you want the spot and sends it to you. For example, the following two filters
|
|
perform exactly the same thing ...</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
accept/spots on contesthf
|
|
reject/spots not on contesthf
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
<P>So, why would we choose one rather than the other? Using reject syntax allows
|
|
you to add another filter line easily, without disturbing the first line. A
|
|
real example will show us how this works. Let's say that there is a RTTY
|
|
contest coming up and you don't wish to see the RTTY spots. Simply add another
|
|
reject filter like this ...</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
reject/spots 2 on hf/rtty
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
<P>Note that we need to specify that this is the second line of reject filter
|
|
definitions. Also, the "RTTY" sub-band specification has to be associated with
|
|
a range of bands; it can't be specified all by itself. So, we just add it
|
|
behind the range of bands defined by "HF". So in our example, if the user does
|
|
a show/filter, he will be told by the Spider that his current filters are ...</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
filter 1 reject not on contesthf
|
|
filter 2 reject on hf/rtty
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
<P>With these filters set up, if a spot comes through on 14085 kHz, the filter
|
|
works like this ...</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
filter1: Is spot NOT on the HF contest bands? No.
|
|
The spot doesn't match the filter definition, so pass it to
|
|
next filter.
|
|
|
|
filter2: Is spot within the frequency range defined for RTTY? Yes.
|
|
Since the spot matches the filter definition, the spot is rejected
|
|
and the user never sees it.
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
<P>Had the frequency of the spot been 14025, then the spot would have not matched
|
|
the filter2 definition either, would have passed through all the filters, and
|
|
would have been sent to the user at the end of the filter set. Similarly, had
|
|
the spot been on 10 MHz, it would have met the definition of filter1, been
|
|
rejected immediately, and the filtering process would have stopped before
|
|
processing
|
|
filter2.</P>
|
|
|
|
<P>In addition, the filtering system has a rough time handling accept filters
|
|
followed by reject filters and adds inefficiency to the processing.
|
|
(Note: a reject as a "qualifier" to an accept rule in an accept filter line is
|
|
okay as we will see below)</P>
|
|
|
|
|
|
<H2><A NAME="ss4.4">4.4</A> <A HREF="filtering_en.html#toc4.4">A very useful command </A>
|
|
</H2>
|
|
|
|
<P>To see all active filters in use at any time, just type the following command
|
|
...</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
show/filter
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
|
|
<H2><A NAME="ss4.5">4.5</A> <A HREF="filtering_en.html#toc4.5">Case does not matter</A>
|
|
</H2>
|
|
|
|
<P>In entering any filter - case does not matter. Upper, lower, or mixed case
|
|
will not effect how filters work or perform.</P>
|
|
|
|
<H2><A NAME="ss4.6">4.6</A> <A HREF="filtering_en.html#toc4.6">Qualifiers</A>
|
|
</H2>
|
|
|
|
<P>Logical operands can be used in rule sets to combine multiple actions or
|
|
qualify others. These are ...</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
and a and b= action
|
|
not a not b= action
|
|
or a and not (c or b)= action
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
<P>Note: as a general rule when or is used you must also use parentheses ().
|
|
We will see how these can be used in examples later.</P>
|
|
|
|
<H2><A NAME="ss4.7">4.7</A> <A HREF="filtering_en.html#toc4.7">Comma Separation</A>
|
|
</H2>
|
|
|
|
<P>Any command can have multiple pattern variables if commas separate them.
|
|
For example ...</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
reject/spot call_state nj,ny,pa,de,md
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
|
|
<HR>
|
|
<A HREF="filtering_en-5.html">Next</A>
|
|
<A HREF="filtering_en-3.html">Previous</A>
|
|
<A HREF="filtering_en.html#toc4">Contents</A>
|
|
</BODY>
|
|
</HTML>
|