1 <!doctype linuxdoc system>
5 <!-- Title information -->
7 <title>The DXSpider User Filtering Primer v1.0</title>
8 <author>Compiled By W3BG - Jim Samuels (jimsam@comcast.net) With Introduction by N3RD - Dave Hawes (dave.n3rd@comcast.net)</author>
9 <date>April 2003 revision 0.2</date>
12 A primer and tutorial for Users and SysOps of the DXSpider DXCluster program.
15 <!-- Table of contents -->
18 <!-- Begin the document -->
23 The PacketCluster software written in the mid-80s by Dick Newell, AK1A, has
24 served us well. Dick has moved on though and has not supported the software
25 with updates etc. for the last 10 years. Numerous PacketCluster "clones" have
26 come and gone over the years, however there is one, called DX Spider, which
27 provides a very similar user interface to that of AK1A, allows internet
28 connections of users and node-to-node links, is actively supported by the
29 author, and best of all is freeware. FRC has started to convert several nodes
33 One of the strengths of DX Spider is its very powerful and flexible DX spot
34 filtering routines. These filters are totally different from anything we
35 learned how to do with PacketCluster, and along with their power and
36 flexibility comes somewhat of a learning curve. Hence the need for this
40 In the following sections, you will learn that you can filter DX spots by:
45 Callsign of the spot (by state, country, zone, or specific callsign)
46 Callsign of the spotter (by state, country, zone, or specific callsign)
47 Callsign of the source node of the spot (by state, country, zone, or specific callsign)
51 With a few keystrokes, you can set up a filter for the CQ WW SSB contest, for
52 example, that says that you only want to see SSB spots on the contesting bands.
53 In the ARRL contest, it is simple to exclude spots for Ws and VEs. For example,
54 the best all around one-line filter for users in the CQ WW SSB contest would be:
57 accept/spots on contesthf/ssb
60 This simply reads, "I want to get spots on the hf contesting bands on SSB only."
63 Jim Samuels, W3BG, has put together this primer which not only provides complete
64 details on the format for all the available filter commands, but also provides
65 useful examples that can be simply typed in, without the need to learn the
69 I would be remiss in not thanking Charlie Carroll, K1XX, who gave a lot of
70 encouragement and mentoring, and provided some of the material in this primer.
73 As always, your local sysop is available to help you out, if need be. Don't
74 hesitate to contact him for assistance.
82 While attempting to learn how DXSpider filters work, I found that I had to glean
83 bits and pieces of information from the DXSpider User Manual and Administrators
84 Guide as well as various posted messages, help files and the program and
85 data-base files themselves. Therefore, this is by no means an original work. I
86 have used and in some cases copied from some of these sources. What I have tried
87 to accomplish is to gather this scattered information, put it in one spot
88 (please pardon the pun) so others might benefit. I would advise those with
89 interest to go back and read these other sources at their leisure.
92 <sect>Configuring Spot Filters
94 <sect1>What is a spot filter?
97 A spot filter is one rule (a one line spot filter) or multiple rules (multiple
98 line spot filters) that a user can setup within DXSpider to control which
99 specific spot(s) are received at the shack console. These configurable
100 filters/rules reside on the DXSpider node and are stored along with the user's
101 other information. Filters can be likened to a car wash . . . . . like cars,
102 information goes in one end dirty, gets washed and comes out the other end
106 All spots received from other users on the cluster, or those received from other
107 nodes, start out life destined for each and every connected user's console. If
108 spot filtering has been configured, all spots headed for that user first go into
109 the filter input, are processed and sent out the other end of these filters
110 before being sent to the user's console. Like a car wash, each spot goes through
111 one or many stages depending on whether the user wanted a simple or a
112 super-duper filtering job. Along the way, the spot gets scrubbed, unwanted
113 information removed or wanted information passed on and finally the wanted spots
114 only are spit out the other end - nice and clean with all unwanted "stuff" sent
115 down the drain to the infamous "bit-bucket."
118 <sect1>How can filters be used?
121 For example, let's say our local user has never owned a microphone in his life
122 and definitely doesn't want to see any of those useless SSB spots. Our user
123 simply sets up a basic filter to reject any SSB spots before they reach the
124 user's console. Similarly, it's now the ARRL CW DX contest weekend, so not only
125 does our user not want to see SSB spots, but now doesn't want to see any UHF,
126 VHF, DATA or any US/Canadian "DX" spots. Our user now only accepts HF CW
127 CONTEST spots and in the same rule rejects spots for W and VE stations. In these
128 and many more situations, "filters are our friends."
131 <sect>Types of spot filters used in DXSpider
134 Basic filter types are "accept", "reject", and "clear" where the following
138 Reject filters - any spots that match will be dumped, all others passed on.
139 Accept filters - any spots that match are passed on, all others are dumped.
140 Clear filters - the filter slot(s) referenced will be cleared from the filter
144 For the most part we will use only reject and accept filters. These are the main
145 filter types. Basically, reject means dump it and accept means take it and pass
146 it on to the user. By nature, accept filters are more powerful than reject
147 filters. A user can generally do with a one line accept rule what it could take
148 many lines of reject rules to accomplish. However, the flip-side of this
149 statement is that a series of reject filters are usually easier to administer
152 <sect1> Numbering lines and slots
155 There are ten usable filter slots in DXSpider. Each slot holds one reject and
156 one accept rule. Therefore, each type filter can have up to ten lines of rules
157 contained in these ten slots. The filter rules must be numbered sequentially,
158 that is, 0-9 lines of reject filter rules and 0-9 lines of accept filter rules
159 to correspond to their respective slot position. If no number is used, every
160 line is assumed to be in slot 1 and the addition of a second filter line of the
161 same type without a number will just over-write the first that was previously
162 written to slot 1. (Why not slot 0? I don't know. This is the way it works.)
165 <em>Important:</em> The filter rules are applied in sequence, i.e., 0-9. If a
166 line matches, action is taken on that line. The filter sequence acts on rules
167 in the order listed. It acts on the reject filter in each slot before acting
168 on the accept filter contained in that slot. If the slot is completely blank or
169 if a reject or accept filter line is missing in that slot it skips right over
170 to the next filter rule in the sequence. A picture of a filter set might look
174 Execution Sequence Slot Number Filter Rule
175 1 Slot0 reject/spot 0 <pattern>
176 2 accept/spot 0 <pattern>
177 3 Slot1 reject/spot 1 <pattern>
178 4 accept/spot 1 <pattern>
179 5 Slot2 reject/spot 2 <pattern>
180 6 accept/spot 2 <pattern>
182 19 Slot9 reject/spot 9 <pattern>
183 20 accept/spot 9 <pattern>
187 <sect1>Reject before accept
190 This is not a good rule for life, but it makes sense for DXSpider filters. As
191 a general rule, reject filter rules within a slot are always executed before
192 accept filter rules. There is a very good reason for this. If a spot doesn't
193 match a reject filter, the spot is passed to the next filter line in the set.
194 However, if a spot matches an accept filter, it is sent immediately to the user.
196 <sect1>Using Multiple Reject Filter Rules
199 Another important concept to know is that you can do everything you want to do
200 with multiple reject filters AND NO ACCEPT FILTERS. By default, if a spot
201 doesn't match any of the reject filter definitions, then the system considers
202 you want the spot and sends it to you. For example, the following two filters
203 perform exactly the same thing ...
206 accept/spots on contesthf
207 reject/spots not on contesthf
210 So, why would we choose one rather than the other? Using reject syntax allows
211 you to add another filter line easily, without disturbing the first line. A
212 real example will show us how this works. Let's say that there is a RTTY
213 contest coming up and you don't wish to see the RTTY spots. Simply add another
214 reject filter like this ...
217 reject/spots 2 on hf/rtty
220 Note that we need to specify that this is the second line of reject filter
221 definitions. Also, the "RTTY" sub-band specification has to be associated with
222 a range of bands; it can't be specified all by itself. So, we just add it
223 behind the range of bands defined by "HF". So in our example, if the user does
224 a show/filter, he will be told by the Spider that his current filters are ...
227 filter 1 reject not on contesthf
228 filter 2 reject on hf/rtty
231 With these filters set up, if a spot comes through on 14085 kHz, the filter
235 filter1: Is spot NOT on the HF contest bands? No.
236 The spot doesn't match the filter definition, so pass it to
239 filter2: Is spot within the frequency range defined for RTTY? Yes.
240 Since the spot matches the filter definition, the spot is rejected
241 and the user never sees it.
244 Had the frequency of the spot been 14025, then the spot would have not matched
245 the filter2 definition either, would have passed through all the filters, and
246 would have been sent to the user at the end of the filter set. Similarly, had
247 the spot been on 10 MHz, it would have met the definition of filter1, been
248 rejected immediately, and the filtering process would have stopped before
249 processing
\rfilter2.
252 In addition, the filtering system has a rough time handling accept filters
253 followed by reject filters and adds inefficiency to the processing.
254 (Note: a reject as a "qualifier" to an accept rule in an accept filter line is
255 okay as we will see below)
258 <sect1>A very useful command
261 To see all active filters in use at any time, just type the following command
268 <sect1>Case does not matter
271 In entering any filter - case does not matter. Upper, lower, or mixed case
272 will not effect how filters work or perform.
277 Logical operands can be used in rule sets to combine multiple actions or
278 qualify others. These are ...
283 or a and not (c or b)= action
286 Note: as a general rule when or is used you must also use parentheses ().
287 We will see how these can be used in examples later.
289 <sect1>Comma Separation
292 Any command can have multiple pattern variables if commas separate them.
296 reject/spot call_state nj,ny,pa,de,md
302 A reject filter line means that if a spot matches, send it to the trash, dump
303 it, do not send it down the line to the next rule or to the user, but pass-on
304 all other spots that do not match.
307 Syntax: reject/spots [0-9] <pattern>
310 Any of the following patterns may be used in this line ...
320 call_state <state 2-letter abbreviations>
325 by_state <state 2-letter abbreviations>
326 origin <prefixes> Used primarily be SYSOPS, not by users and not discussed.
327 channel <prefixes> Used primarily be SYSOPS, not by users and not discussed.
330 <sect>Filters to reject spots based on frequency
334 Syntax: reject/spot [0-9] freq <range>
338 reject/spot [0-9] on <range>
341 Important: both <em>freq</em> and <em>on</em> are exactly the same and can be
342 used interchangeably - most persons use <em>on</em> (less typing.)
345 For range, you can specify a frequency like 7040, a range of frequencies like
346 0/30000 ( the whole HF band) or use any of the "band" or "region" names defined
347 in the show/bands command.
349 <sect1>Bands Available
365 military: 29700 -> 50000, 230000 -> 420000
366 band1: 47000 -> 49999, 52000 -> 68000
368 pmrlow: 68000 -> 87500
370 band2: 87500 -> 108000
371 aircraft: 108000 -> 137500
372 pmrmid: 138000 -> 165000
374 pmrhigh: 165000 => 174000
375 band3: 176000 => 230000
376 220: 220000 => 222000
377 pmruhf: 425000 => 430000, 440000 => 471000
378 70cm: 430000 => 450000
379 band4: 471000 => 550000
380 band5: 550000 => 868000
381 23cm: 1240000 => 1325000
382 13cm: 2310000 => 2450000
383 9cm: 3400000 => 3475000
384 6cm: 5650000 => 5850000
385 3cm: 10000000 => 10500000
386 12mm: 24000000 => 24250000
387 6mm: 47000000 => 47200000
390 <sect1>Regions Available
394 all: 73khz 136khz 160m 80m 60m 40m 30m 20m 17m 15m 12m 10m 6m 4m
395 2m 220 70cm 23cm 9cm 6cm 3cm 12mm 6mm
396 vhfradio: band1 band2
398 contesthf: 160m 80m 40m 20m 15m 10m
399 warc: 60m 30m 17m 12m
400 pmr: pmrlow pmrmid pmrhigh pmruhf
402 shf: 23cm 13cm 9cm 6cm 3cm
405 hf: 160m 80m 60m 40m 30m 20m 17m 15m 12m 10m
413 The following line will reject spots on 7,040 kHz and pass all others.
416 reject/spot 0 freq 7040
419 The next line will reject spots from 0 to 30,000 kHz and pass on all others.
422 reject/spot 1 on 0/30000
425 This next will trash all spots in the frequency range 144000 -> 148000 kHz and
429 reject/spot 2 freq 2m
432 This rule will reject all spots on 6m, 4m, 2m, and 220 and pass on all
439 This rule will dump all spots on the 160m, 80m, 60m, 40m, 30m, 20m, 17m, 15m,
440 12m, 10m bands and all spots on 70cm and 23cm bands passing all other spots.
443 reject/spot 4 freq hf and freq uhf
446 This is a special spot to be used only by members of the Yankee Clipper
447 Contest Club during contest weekends. Hi!
453 <sect1>Sub-bands as part of range
456 In conjunction with range, you can use the following sub-band names,
459 cw, rtty, data, ssb, and sstv
462 by using a forward-slash [(band or region)/sub-band] as part of the range
463 definition. For example ...
466 This rule will reject all HF phone spots passing on all others
469 reject/spot 0 freq hf/ssb
472 This filter rule will reject all HF CW spots but will not reject DATA and RTTY
473 spots in the CW range and will pass on all other spots.
476 reject/spot 1 on hf/cw and not (on hf/data or on hf/rtty)
479 <sect1>Filters to reject spots based on the "info" data in the spot
484 Syntax: reject/spot [0-9] info <string>
487 This filter is used to key on information contained in the information section
488 of the spot. One could use this to reject any spots containing IOTA, QSL OP or
489 any other "key-word" used in the information string of the spot.
495 This filter will reject spots containing IOTA information and pass on all
499 reject/spot 0 info IOTA
502 This filter will reject all general CW spots on HF, but will still permit any
503 HF CW spots that contain iota information in addition to passing all others.
506 reject/spot 1 on hf/cw and not info iota
509 This next filter will reject spots asking or containing QSL information and
513 reject/spot 2 info QSL
516 Note: The following series of filters are based on <em>call</em> and
517 <em>by</em>. Call always references the callsign of the spotted DX station.
518 By always references the callsign of the spotting station.
520 <sect1>Filters to reject spots based on call
524 Syntax: reject/spot [0-9] call <prefixes>
527 This filter is misleading in a way. It is strictly based on the spotted call
528 sign letters or numbers entered and not based on countries or DXCC entities.
529 One could filter on JIMSAM62 if desired.
535 This filter will reject spots for G1AAA, GJ2BBB, and GW3CCC and will pass on
542 This next filter will reject spots for PA3AAA and pass on spots for PB4BBB
545 reject/spot 1 call PA
548 This filter will reject spots for K1AA, KC4AAA, and KH6DDD and pass on spots
555 <sect1>Filters to reject spots based on call_dxcc
559 Syntax: reject/spot [0-9] call_dxcc <numbers or prefixes>
562 This filter is based on DXCC entities and uses either the country prefix or
563 the DXCC entity number, found by using the command <em>show/prefix</em>.
570 W DXCC: 226 ITU: 7 CQ: 4 LL: 43 0 N 87 54 W (W, United-States-W)
575 VE DXCC: 197 ITU: 9 CQ: 5 LL: 45 18 N 66 6 W (VE, New-Brunswick-VE)
576 DXCC: 197 ITU: 9 CQ: 5 LL: 48 30 N 56 0 W (VE, Newfoundland-VE)
577 DXCC: 197 ITU: 9 CQ: 5 LL: 44 36 N 63 36 W (VE, Nova-Scotia-VE)
578 DXCC: 197 ITU: 4 CQ: 5 LL: 45 30 N 73 36 W (VE, Quebec-VE)
579 DXCC: 197 ITU: 4 CQ: 4 LL: 43 42 N 79 24 W (VE, Ontario-VE)
580 DXCC: 197 ITU: 3 CQ: 4 LL: 49 54 N 97 6 W (VE, Manitoba-VE)
581 DXCC: 197 ITU: 3 CQ: 4 LL: 50 30 N 104 36 W (VE, Saskatchewan-VE)
582 DXCC: 197 ITU: 2 CQ: 3 LL: 51 0 N 114 6 W (VE, Alberta-VE)
583 DXCC: 197 ITU: 2 CQ: 3 LL: 49 18 N 123 6 W (VE, British-Columbia-VE)
584 DXCC: 197 ITU: 75 CQ: 1 LL: 60 42 N 135 6 W (VE, Yukon-VE)
590 This spot filter will reject all spots for US and Canada stations and pass on
594 reject/spot 0 call_dxcc 226,197
597 This spot filter will reject all spots for US and Canada stations and pass on
598 all others including the special event station, W2WTC, who I want to work the
599 next time he is on the air.
602 reject/spot 1 call_dxcc w,ve not call w2wtc
605 <sect1>Filters to reject spots based on call_itu
608 Similarly, call_itu and call_zone use ITU regions that can also be obtained
609 using the show/prefix <prefix> command (see above.)
612 Syntax: accept/spot [0-9] call_itu <numbers>
618 This spot filter will reject all spots for ITU region 7 and pass on all
622 reject/spot 0 call_itu 7
625 <sect1>Filters to reject spots based on call_zone
629 Syntax: reject/spot [0-9] call_zone <numbers>
632 This filter is based on CQ zones and uses the CQ zone number found by using the
633 command <em>show/prefix</em> (see above.)
639 This spot filter will reject all spots for CQ zone 5 and pass on all others.
642 reject/spot 0 call_zone 5
645 <sect1>Filters to reject spots based on call_state
649 Syntax: reject/spot [0-9] call_state <state2-letter abbreviations>
652 This filter is based on the state of the call spotted, for those callsigns
653 contained in the usdb database. Use the command <em>show/usdb</em> to see an
654 example of a listing in the database, like this ...
664 This spot filter will reject all spots for stations in the Mid-Atlantic
665 states and pass on all others.
668 reject/spot call_state nj,ny,pa,de,md
671 <sect1>Filters to reject spots based on by
674 <em>by</em> filters are similar to and function exactly as call filters except
675 that they act on the spotting station callsign and not the spotted callsign.
681 This filter is similar to and functions like the call <prefixes>
682 (See above) except that it rejects spots generated by the spotting callsign
683 and passes all other spots.
686 Syntax: reject/spot [0-9] by <prefixes>
689 This next filter is based on DXCC entities and uses the DXCC entity number
690 found by using the command show/prefix <prefix> and it rejects spots
691 generated within the spotting DXCC entity and passes all other spots.
694 Syntax: reject/spot [0-9] by_dxcc <numbers>
697 This next filter is based on ITU regions and uses the ITU region number found by
698 using the command <em>show/prefix</em> (see above), except that it rejects
699 spots generated by a spotting callsign within the ITU region and passes all
703 Syntax: reject/spot [0-9] by_itu <numbers>
706 This filter is based on CQ zones and uses the CQ zone number found by using
707 the command <em>show/prefix</em> (see above), except that it rejects spots
708 generated by a spotting callsign within the CQ zone and passes all other
712 Syntax: reject/spot [0-9] by_zone <numbers>
715 This filter is based on the state of the spotting station found by using the
716 command <em>show/usdb</em> and passes all other spots.
719 Syntax: reject/spot [0-9] by_state <state2-letter postal codes
725 An accept filter line means that if a spot matches pass it on to the user, send
726 it down the line to the next rule or to the user, and trash, dump, all other
727 spots that do not match to the next filter line.
730 Syntax: accept/spots [0-9] <pattern>
733 Any of the following patterns may be used in this line ...
743 call_state <state2-letter abbreviations>
748 by_state <state2-letter abbreviations>
749 origin <prefixes> Used primarily be SYSOPS, not by users and not discussed.
750 channel <prefixes> Used primarily be SYSOPS, not by users and not discussed.
753 Using these patterns, we can accept spots based upon ...
756 Frequency of the spot
757 Callsign of the spot (country or zone)
758 Callsign of the spotter (country or zone)
759 Contents of the "information field" which comes with the spot
762 <sect1>Filters to accept spots based on frequency
766 Syntax: accept/spot [0-9] freq <range>
770 accept/spot [0-9] on <range>
773 Important: as noted before, both <em>freq</em> and <em>on</em> are exactly
774 the same and can be used interchangeably.
777 For range, you can specify a frequency like 7040, a range of frequencies
778 like 0/30000 ( the whole HF spectrum) or use any of the band/region names
779 defined in the SHOW/BANDS command (see above).
785 This will pass on a HF spots only from 0 to 30,000 kHz and dump all others.
788 accept/spot 1 on 0/30000
791 This passes on all spots in the frequency range 144000 -> 148000 kHz and trash
795 accept/spot 2 freq 2m
798 This rule will only pass on spots on 6m, 4m, 2m, and 220 and reject all
805 This rule will pass on all spots on the 160m, 80m, 60m, 40m, 30m, 20m, 17m,
806 15m, 12m, 10m bands and all spots on 70cm and 23cm bands only. All other
810 accept/spot 4 freq hf and freq uhf
813 <sect1>Sub-bands as part of range
816 In conjunction with range, you can use the following sub-band names: CW, RTTY,
817 DATA, SSB, and SSTV by using a back-slash [(band or region)/sub-band] as part
818 of the range definition.
824 This rule will only accept and pass on HF phone spots rejecting all others
827 accept/spot 0 freq hf/ssb
830 This filter rule will accept all HF CW spots but will not include DATA and
831 RTTY spots in the CW range. In addition all other spots will be dumped.
834 accept/spot 1 on hf/cw and not (on hf/data or on hf/rtty)
837 <sect1>Filters to accept spots based on info
841 Syntax: accept/spot [0-9] info <string>
844 This filter is used to key on information contained in the information section
845 of the spot. One could use this to accept any spots containing IOTA, QSL OP or
846 any other "key-word" used in the information string of the spot.
852 This filter will accept spots containing IOTA information only and reject all
856 accept/spot 0 info IOTA
859 This filter will accept only 10m SSB spots, but will still permit any spots
860 that contain iota information in addition - rejecting all other spots.
863 accept/spot 1 on 10m/ssb and info iota
866 This next filter will accept spots asking or containing QSL information and dump
870 accept/spot 2 info QSL
873 Note: The following series of filters are based on <em>call</em> and
874 <em>by</em>. Call always references the callsign of the spotted DX station.
875 By always references the callsign of the spotting station.
877 <sect1>Filters to accept spots based on call
881 Syntax: accept/spot [0-9] call <prefixes>
884 This filter is misleading in a way. It is strictly based on the spotted call
885 sign letters or numbers entered and not based on countries or DXCC entities.
891 This filter will accept spots for G1AAA, GJ2BBB, and GW3CCC and reject all
892 others, including M0AAA.
898 This next filter will accept spots for PA3AAA and reject spots for PB4BBB as
902 accept/spot 1 call PA
905 This filter will accept spots for callsigns beginning with "K", i.e., K1AA,
906 KC4AAA, KH6DDD and reject spots for W3BG and N3RD as well as all other
913 <sect1>Filters to accept spots based on call_dxcc
917 Syntax: accept/spot [0-9] call_dxcc <numbers or prefixes>
920 This filter is based on DXCC entities and uses either the country prefixes or
921 the DXCC entity number found by using the command <em>show/prefix</em>. See
922 example of <em>show/prefix</em> above.
928 accept/spot 0 call_dxcc 226,197
932 accept/spot 0 call_dxcc ve,w
935 (Both will work) These spot filters will accept all spots for US and Canada
936 stations and trash all others.
939 The folowing spot filter will accept all spots for US stations and yet reject
940 any spots for W3FM who is always being spotted by Europeans and filling up my
944 accept/spot 1 call_dxcc w not call w3fm
947 <sect1>Filters to accept spots based on call_itu
950 Similarly, call_itu and call_zone use ITU regions that can also be obtained
951 using the <em>show/prefix</em> command (see above.)
954 Syntax: accept/spot [0-9] call_itu <numbers>
960 This spot filter will accept all spots for ITU region 7 and reject all
964 accept/spot 0 call_itu 7
967 <sect1>Filters to accept spots based on call_zone
971 Syntax: accept/spot [0-9] call_zone <numbers>
974 This filter is based on CQ zones and uses the CQ zone number found by using
975 the command <em>show/prefix</em> (see above.)
981 This spot filter will accept all spots for CQ zone 5 and reject all others.
984 accept/spot 0 call_zone 5
987 <sect1>Filters to accept spots based on call_state
991 Syntax: accept/spot [0-9] call_state <state2-letter postal codes>
994 This filter is based on state of the call spotted for those callsigns contained
995 in the usdb database.
1001 This spot filter will accept all spots of stations located in the
1002 Commonwealth of Pennsylvania and reject all others. It's the PA QSO Party
1006 accept/spot 0 call_state pa
1009 <sect1>Filters to accept spots based on by
1012 <em>by</em> filters are similar to and function exactly as call filters except
1013 that they act on the spotting station callsign and not the spotted callsign
1019 This filter is similar to and functions like the call <prefixes> (See above)
1020 except that it accepts spots generated by the spotting callsign and dumps all
1024 Syntax: accept/spot [0-9] by <prefixes>
1027 This filter is based on DXCC entities and uses the DXCC entity number found
1028 by using the command <em>show/prefix</em> and it accepts spots generated
1029 within the spotting DXCC entity and rejects other spots.
1032 Syntax: accept/spot [0-9] by_dxcc <numbers>
1035 This next filter is based on ITU regions and uses the ITU region number found by
1036 using the command <em>show/prefix</em> (see above), except that it accepts
1037 spots generated by a spotting callsign within the ITU region and rejects all
1041 Syntax: accept/spot [0-9] call_itu <numbers>
1044 This filter is based on CQ zones and uses the CQ zone number found by using
1045 the command <em>show/prefix</em> (see above), except that it accepts spots
1046 generated by a spotting callsign within the CQ zone and rejects all other
1050 Syntax: accept/spot [0-9] call_zone <numbers>
1053 This filters is based on the state location of the spotting station found
1054 by using the command <em>show/usdb</em> and accepts only those spots
1055 generated by stations from the states(s) specified rejecting all other spots.
1058 Syntax: accept/spot [0-9] by_state <state2-letter postal codes>
1064 A clear filter line will delete the slot number specified or all slots and
1065 consequently all filters that have been created by a user.
1069 Syntax: clear/spots [0-9]
1079 This will clear any or both accept and reject spot filters in slot 2.
1085 This will clear each and every user spot filter - it will clear out all
1086 filters in all slots.
1092 Note - if you just want to replace a spot filter, enter the rule again (with a
1093 line number) and it will overwrite the previous filter in that slot. If you
1094 forget the line number, it will overwrite the filter in slot 1 by default.
1096 <sect>Some Practice Examples
1099 The proceeding sections have discussed the basics of DXSpider filters. The
1100 following are some examples utilizing basic filters and some not so basic
1101 combination filters.
1104 Let's say you don't want to see any of those 6m, 2m, or 220 spots.
1107 reject/spot 0 on uhf
1110 As a good stand alone contest filter ...
1113 accept/spot on contesthf/<mode> where mode is either CW, SSB, or RTTY
1116 Note: since a slot number is not included slot 1 is assumed.
1119 It's a CW contest weekend so you don't want to see any WARC band or SSB spots.
1122 accept/spots 0 on contesthf/cw
1125 It's the same weekend, but you also don't want to see any US or Canadian spots,
1126 or any rtty and data spots that are included in the CW portion of the bands.
1127 Any of the following will accomplish the same result:
1130 reject/spot 0 not on contesthf/cw
1131 reject/spot 1 on contesthf/data
1132 reject/spot 2 call_dxcc w,ve
1136 accept/spot 0 on contesthf/cw and not (call_dxcc 226,197 or on contesthf/data)
1140 accept/spot 0 on contesthf/cw and not (call_dxcc w,ve or on contesthf/data)
1143 The following two discussions are from the Administrator Manual and are good
1144 "textbook" examples:
1149 acc/spot 2 on 50000/1400000 and (by_zone 14,15,16 or call_zone 14,15,16)
1152 Note that accept and reject can be abbreviated. Also, the first filter has not
1153 been specified with a number. This will automatically be assumed to be number 1.
1154 In this case, we have said to reject all HF spots in the CW section of the bands
1155 but accept all others at HF. Also accept anything in VHF and above that is
1156 spotted in or by operators in the zones 14, 15 and 16. Each filter slot actually
1157 has a 'reject' rule slot and an 'accept' rule slot. The reject rule slot is
1158 executed BEFORE the accept rule slot.
1161 It was mentioned earlier that after a reject test that doesn't match, the
1162 default for following tests is 'accept', the reverse is true for 'accept'. In
1163 the example what happens is that the reject is executed first, any non hf/cw
1164 spot is passed to the accept line, which lets through everything else on HF.
1165 The next filter line lets through just VHF/UHF spots from EU.
1168 If you set a reject filter like this ...
1171 reject/spots on hf/cw
1174 Then you will get everything except HF CW spots. You could make this single
1175 filter even more flexible. For example, if you are interested in IOTA and will
1176 work it on CW even though normally you are not interested in CW, then you could
1180 reject/spots on hf/cw and not info iota
1183 But in that case you might only be interested in iota and say,
1186 accept/spots not on hf/cw or info iota
1189 which achieves exactly the same thing. Note that since slot numbers were
1190 not used, slot 1 is assumed.
1195 This Primer is a work in progress. Additional features and filters are added
1196 from time to time by Dirk Koopman, G1TLH, the developer behind DXSpider. So
1197 periodic revisions will be made to this document. If you have any questions,
1198 comments, or suggestions relative to this primer on spot filtering, please
1202 Jim Samuels, W3BG jimsam@comcast.net
1206 Dave Hawes, N3RD (W3FRC Cluster SYSOP) dave.n3rd@comcast.net