X-Git-Url: http://scm.dxcluster.org/gitweb/gitweb.cgi?a=blobdiff_plain;ds=inline;f=html%2Ffiltering_en-4.html;h=d6a70339f1a7822ccbbf49a1f387409bf28dc881;hb=d8b9ca222a816c470dfd9455e09b1a861f8624a1;hp=2e8719758aadeb7d1ec5fdb71221968375217074;hpb=3d66b51182cb1939154d96def02efb45784958c0;p=spider.git diff --git a/html/filtering_en-4.html b/html/filtering_en-4.html index 2e871975..d6a70339 100644 --- a/html/filtering_en-4.html +++ b/html/filtering_en-4.html @@ -1,7 +1,7 @@
- +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 ...
@@ -131,17 +131,18 @@ 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.
+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.
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.
In addition, the filtering system has a rough time handling accept filters