<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
- <META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.16">
+ <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>
<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 spots and sends it to you. For example, the following two filters
+you want the spot and sends it to you. For example, the following two filters
perform exactly the same thing ...</P>
<P>
<BLOCKQUOTE><CODE>
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.
+filter2: Is spot within the frequency range defined for RTTY? Yes.
Since the spot matches the filter definition, the spot is rejected
- and the users never see it.
+ 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. 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
+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
projects / spider.git / blobdiff