html/filtering_en-4.html

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
   2 <HTML>
   3 <HEAD>
   4  <META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.16">
   5  <TITLE>The DXSpider User Filtering Primer v1.0: Types of spot filters used in DXSpider </TITLE>
   6  <LINK HREF="filtering_en-5.html" REL=next>
   7  <LINK HREF="filtering_en-3.html" REL=previous>
   8  <LINK HREF="filtering_en.html#toc4" REL=contents>
   9 <link rel=stylesheet href="style.css" type="text/css" title="default stylesheet">
  10 </HEAD>
  11 <BODY>
  12 <A HREF="filtering_en-5.html">Next</A>
  13 <A HREF="filtering_en-3.html">Previous</A>
  14 <A HREF="filtering_en.html#toc4">Contents</A>
  15 <HR>
  16 <H2><A NAME="s4">4.</A> <A HREF="filtering_en.html#toc4">Types of spot filters used in DXSpider </A></H2>
  17
  18 <P>Basic filter types are "accept", "reject", and "clear" where the following
  19 applies ...</P>
  20 <P>
  21 <BLOCKQUOTE><CODE>
  22 <PRE>
  23 Reject filters - any spots that match will be dumped, all others passed on.
  24 Accept filters - any spots that match are passed on, all others are dumped.
  25 Clear filters  - the filter slot(s) referenced will be cleared from the filter
  26                  repository
  27 </PRE>
  28 </CODE></BLOCKQUOTE>
  29 </P>
  30 <P>For the most part we will use only reject and accept filters. These are the main
  31 filter types. Basically, reject means dump it and accept means take it and pass
  32 it on to the user. By nature, accept filters are more powerful than reject
  33 filters. A user can generally do with a one line accept rule what it could take
  34 many lines of reject rules to accomplish. However, the flip-side of this
  35 statement is that a series of reject filters are usually easier to administer
  36 and change.</P>
  37
  38 <H2><A NAME="ss4.1">4.1</A> <A HREF="filtering_en.html#toc4.1">Numbering lines and slots </A>
  39 </H2>
  40
  41 <P>There are ten usable filter slots in DXSpider. Each slot holds one reject and
  42 one accept rule. Therefore, each type filter can have up to ten lines of rules
  43 contained in these ten slots. The filter rules must be numbered sequentially,
  44 that is, 0-9 lines of reject filter rules and 0-9 lines of accept filter rules
  45 to correspond to their respective slot position. If no number is used, every
  46 line is assumed to be in slot 1 and the addition of a second filter line of the
  47 same type without a number will just over-write the first that was previously
  48 written to slot 1. (Why not slot 0? I don't know. This is the way it works.)</P>
  49
  50 <P><EM>Important:</EM> The filter rules are applied in sequence, i.e., 0-9. If a
  51 line matches, action is taken on that line. The filter sequence acts on rules
  52 in the order listed.  It acts on the reject filter in each slot before acting
  53 on the accept filter contained in that slot. If the slot is completely blank or
  54 if a reject or accept filter line is missing in that slot it skips right over
  55 to the next filter rule in the sequence. A picture of a filter set might look
  56 like this ...</P>
  57 <P>
  58 <BLOCKQUOTE><CODE>
  59 <PRE>
  60 Execution Sequence      Slot Number     Filter Rule
  61         1                 Slot0         reject/spot 0 &lt;pattern>
  62         2                               accept/spot 0 &lt;pattern>
  63         3                 Slot1         reject/spot 1 &lt;pattern>
  64         4                               accept/spot 1 &lt;pattern>
  65         5                 Slot2         reject/spot 2 &lt;pattern>
  66         6                               accept/spot 2 &lt;pattern>
  67         .                 .
  68         19                Slot9         reject/spot 9 &lt;pattern>
  69         20                              accept/spot 9 &lt;pattern>
  70 </PRE>
  71 </CODE></BLOCKQUOTE>
  72 </P>
  73
  74
  75 <H2><A NAME="ss4.2">4.2</A> <A HREF="filtering_en.html#toc4.2">Reject before accept</A>
  76 </H2>
  77
  78 <P>This is not a good rule for life, but it makes sense for DXSpider filters. As
  79 a general rule, reject filter rules within a slot are always executed before
  80 accept filter rules.  There is a very good reason for this.  If a spot doesn't
  81 match a reject filter, the spot is passed to the next filter line in the set.
  82 However, if a spot matches an accept filter, it is sent immediately to the user.</P>
  83
  84 <H2><A NAME="ss4.3">4.3</A> <A HREF="filtering_en.html#toc4.3">Using Multiple Reject Filter Rules</A>
  85 </H2>
  86
  87 <P>Another important concept to know is that you can do everything you want to do
  88 with multiple reject filters AND NO ACCEPT FILTERS.  By default, if a spot
  89 doesn't match any of the reject filter definitions, then the system considers
  90 you want the spot and sends it to you.  For example, the following two filters
  91 perform exactly the same thing ...</P>
  92 <P>
  93 <BLOCKQUOTE><CODE>
  94 <PRE>
  95 accept/spots on contesthf
  96 reject/spots not on contesthf
  97 </PRE>
  98 </CODE></BLOCKQUOTE>
  99 </P>
 100 <P>So, why would we choose one rather than the other?  Using reject syntax allows
 101 you to add another filter line easily, without disturbing the first line.  A
 102 real example will show us how this works.  Let's say that there is a RTTY
 103 contest coming up and you don't wish to see the RTTY spots.  Simply add another
 104 reject filter like this ...</P>
 105 <P>
 106 <BLOCKQUOTE><CODE>
 107 <PRE>
 108 reject/spots 2 on hf/rtty
 109 </PRE>
 110 </CODE></BLOCKQUOTE>
 111 </P>
 112 <P>Note that we need to specify that this is the second line of reject filter
 113 definitions.  Also, the "RTTY" sub-band specification has to be associated with
 114 a range of bands; it can't be specified all by itself.  So, we just add it
 115 behind the range of bands defined by "HF".  So in our example, if the user does
 116 a show/filter, he will be told by the Spider that his current filters are ...</P>
 117 <P>
 118 <BLOCKQUOTE><CODE>
 119 <PRE>
 120 filter 1 reject not on contesthf
 121 filter 2 reject on hf/rtty
 122 </PRE>
 123 </CODE></BLOCKQUOTE>
 124 </P>
 125 <P>With these filters set up, if a spot comes through on 14085 kHz, the filter
 126 works like this ...</P>
 127 <P>
 128 <BLOCKQUOTE><CODE>
 129 <PRE>
 130 filter1:    Is spot NOT on the HF contest bands?  No.
 131             The spot doesn't match the filter definition, so pass it to
 132             next filter.
 133
 134 filter2:    Is spot within the frequency range defined for RTTY?  Yes.
 135             Since the spot matches the filter definition, the spot is rejected
 136             and the user never sees it.
 137 </PRE>
 138 </CODE></BLOCKQUOTE>
 139 </P>
 140 <P>Had the frequency of the spot been 14025, then the spot would have not matched
 141 the filter2 definition either, would have passed through all the filters, and
 142 would have been sent to the user at the end of the filter set.  Similarly, had
 143 the spot been on 10 MHz, it would have met the definition of filter1, been
 144 rejected immediately, and the filtering process would have stopped before
 145 processing
 146 filter2.</P>
 147
 148 <P>In addition, the filtering system has a rough time handling accept filters
 149 followed by reject filters and adds inefficiency to the processing.
 150 (Note: a reject as a "qualifier" to an accept rule in an accept filter line is
 151 okay as we will see below)</P>
 152
 153
 154 <H2><A NAME="ss4.4">4.4</A> <A HREF="filtering_en.html#toc4.4">A very useful command </A>
 155 </H2>
 156
 157 <P>To see all active filters in use at any time, just type the following command
 158 ...</P>
 159 <P>
 160 <BLOCKQUOTE><CODE>
 161 <PRE>
 162 show/filter
 163 </PRE>
 164 </CODE></BLOCKQUOTE>
 165 </P>
 166
 167 <H2><A NAME="ss4.5">4.5</A> <A HREF="filtering_en.html#toc4.5">Case does not matter</A>
 168 </H2>
 169
 170 <P>In entering any filter - case does not matter. Upper, lower, or mixed case
 171 will not effect how filters work or perform.</P>
 172
 173 <H2><A NAME="ss4.6">4.6</A> <A HREF="filtering_en.html#toc4.6">Qualifiers</A>
 174 </H2>
 175
 176 <P>Logical operands can be used in rule sets to combine multiple actions or
 177 qualify others. These are ...</P>
 178 <P>
 179 <BLOCKQUOTE><CODE>
 180 <PRE>
 181 and     a and b= action
 182 not     a not b= action
 183 or      a and not (c or b)= action
 184 </PRE>
 185 </CODE></BLOCKQUOTE>
 186 </P>
 187 <P>Note: as a general rule when or is used you must also use parentheses ().
 188 We will see how these can be used in examples later.</P>
 189
 190 <H2><A NAME="ss4.7">4.7</A> <A HREF="filtering_en.html#toc4.7">Comma Separation</A>
 191 </H2>
 192
 193 <P>Any command can have multiple pattern variables if commas separate them.
 194 For example ...</P>
 195 <P>
 196 <BLOCKQUOTE><CODE>
 197 <PRE>
 198 reject/spot call_state nj,ny,pa,de,md
 199 </PRE>
 200 </CODE></BLOCKQUOTE>
 201 </P>
 202
 203 <HR>
 204 <A HREF="filtering_en-5.html">Next</A>
 205 <A HREF="filtering_en-3.html">Previous</A>
 206 <A HREF="filtering_en.html#toc4">Contents</A>
 207 </BODY>
 208 </HTML>