mirror of
git://scm.dxcluster.org/scm/spider
synced 2024-09-21 07:47:10 +00:00
60 lines
2.8 KiB
HTML
60 lines
2.8 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
|
|
<HTML>
|
|
<HEAD>
|
|
<META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.21">
|
|
<TITLE>The DXSpider User Filtering Primer v1.0: Configuring Spot Filters</TITLE>
|
|
<LINK HREF="filtering_en-4.html" REL=next>
|
|
<LINK HREF="filtering_en-2.html" REL=previous>
|
|
<LINK HREF="filtering_en.html#toc3" REL=contents>
|
|
<link rel=stylesheet href="style.css" type="text/css" title="default stylesheet">
|
|
</HEAD>
|
|
<BODY>
|
|
<A HREF="filtering_en-4.html">Next</A>
|
|
<A HREF="filtering_en-2.html">Previous</A>
|
|
<A HREF="filtering_en.html#toc3">Contents</A>
|
|
<HR>
|
|
<H2><A NAME="s3">3.</A> <A HREF="filtering_en.html#toc3">Configuring Spot Filters</A></H2>
|
|
|
|
<H2><A NAME="ss3.1">3.1</A> <A HREF="filtering_en.html#toc3.1">What is a spot filter?</A>
|
|
</H2>
|
|
|
|
<P>A spot filter is one rule (a one line spot filter) or multiple rules (multiple
|
|
line spot filters) that a user can setup within DXSpider to control which
|
|
specific spot(s) are received at the shack console. These configurable
|
|
filters/rules reside on the DXSpider node and are stored along with the user's
|
|
other information. Filters can be likened to a car wash . . . . . like cars,
|
|
information goes in one end dirty, gets washed and comes out the other end
|
|
cleaned.</P>
|
|
|
|
<P>All spots received from other users on the cluster, or those received from other
|
|
nodes, start out life destined for each and every connected user's console. If
|
|
spot filtering has been configured, all spots headed for that user first go into
|
|
the filter input, are processed and sent out the other end of these filters
|
|
before being sent to the user's console. Like a car wash, each spot goes through
|
|
one or many stages depending on whether the user wanted a simple or a
|
|
super-duper filtering job. Along the way, the spot gets scrubbed, unwanted
|
|
information removed or wanted information passed on and finally the wanted spots
|
|
only are spit out the other end - nice and clean with all unwanted "stuff" sent
|
|
down the drain to the infamous "bit-bucket." </P>
|
|
|
|
|
|
<H2><A NAME="ss3.2">3.2</A> <A HREF="filtering_en.html#toc3.2">How can filters be used? </A>
|
|
</H2>
|
|
|
|
<P>For example, let's say our local user has never owned a microphone in his life
|
|
and definitely doesn't want to see any of those useless SSB spots. Our user
|
|
simply sets up a basic filter to reject any SSB spots before they reach the
|
|
user's console. Similarly, it's now the ARRL CW DX contest weekend, so not only
|
|
does our user not want to see SSB spots, but now doesn't want to see any UHF,
|
|
VHF, DATA or any US/Canadian "DX" spots. Our user now only accepts HF CW
|
|
CONTEST spots and in the same rule rejects spots for W and VE stations. In these
|
|
and many more situations, "filters are our friends."</P>
|
|
|
|
|
|
<HR>
|
|
<A HREF="filtering_en-4.html">Next</A>
|
|
<A HREF="filtering_en-2.html">Previous</A>
|
|
<A HREF="filtering_en.html#toc3">Contents</A>
|
|
</BODY>
|
|
</HTML>
|