Basic filter types are "accept", "reject", and "clear" where the following +applies ...
++
+
+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
+
+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.
+ +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.)
+ +Important: 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 ...
++
+
+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>
+
+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.
+ +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 spots and sends it to you. For example, the following two filters +perform exactly the same thing ...
++
+
+accept/spots on contesthf
+reject/spots not on contesthf
+
+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 ...
++
+
+reject/spots 2 on hf/rtty
+
+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 ...
++
+
+filter 1 reject not on contesthf
+filter 2 reject on hf/rtty
+
+With these filters set up, if a spot comes through on 14085 kHz, the filter +works like this ...
++
+
+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 freq. Range defined for RTTY? Yes.
+ Since the spot matches the filter definition, the spot is rejected
+ and the users never see it.
+
+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. Also, 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.
+ +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)
+ + +To see all active filters in use at any time, just type the following command +...
++
+
+show/filter
+
+In entering any filter - case does not matter. Upper, lower, or mixed case +will not effect how filters work or perform.
+ +Logical operands can be used in rule sets to combine multiple actions or +qualify others. These are ...
++
+
+and a and b= action
+not a not b= action
+or a and not (c or b)= action
+
+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.
+ +Any command can have multiple pattern variables if commas separate them. +For example ...
++
+
+reject/spot call_state nj,ny,pa,de,md
+
+