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 spot 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 frequency range defined for RTTY? Yes.
Since the spot matches the filter definition, the spot is rejected
and the user never sees 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. 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.
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