3 The latest release of the Mojo branch of DXSpider contains a client
4 for the Reverse Beacon Network (RBN). This is not a simple client, it
5 attempts to make some sense of the 10s of 1000s of "spots" that the
6 RBN can send PER HOUR. At busy times, actually nearly all the time, the
7 spots from the RBN come in too fast for anybody to get anything more
8 than a fleeting impression of what's coming in.
10 Something has to try to make this manageable - which is what I have
11 tried to do with DXSpider's RBN client.
13 The RBN has a number of problems (apart from the overwhelming quantity
14 of data that it sends):
16 * Spotted callsigns, especially on CW, and not reliably
17 decoded. Estimates vary as to how bad it is but, as far as I can
18 tell, even these estimates are unreliable!
20 * The frequency given is unreliable. I have seen differences as great
23 * There is far too much (in my view) useless information in each spot
24 - even if one had time to read, decode and understand it before the
25 spot has scrolled off the top of the screen.
27 * The format of the comment is not regular. If one has both FTx and
28 "all the other" spots (CW, PSK et al) enabled at the same time,
29 one's eye is constantly having to re-adjust. Again, very difficult
30 to deal with on contest days.
33 So what have I done about this:
35 * As you can see, there are frequently more than one spotter for a
38 05Jul2020@22:59:31 (chan) <- I SK0MMR DX de KM3T-2-#: 14100.0 CS3B CW 24 dB 22 WPM NCDXF B 2259Z
39 05Jul2020@22:59:31 (chan) <- I SK0MMR DX de KM3T-2-#: 28263.9 AB8Z/B CW 15 dB 18 WPM BEACON 2259Z
40 05Jul2020@22:59:31 (chan) <- I SK0MMR DX de LZ3CB-#: 7018.20 RW1M CW 10 dB 18 WPM CQ 2259Z
41 05Jul2020@22:59:31 (chan) <- I SK0MMR DX de W9XG-#: 14057.6 K7GT CW 7 dB 21 WPM CQ 2259Z
42 05Jul2020@22:59:31 (chan) <- I SK0MMR DX de G0LUJ-#: 14100.1 CS3B CW 18 dB 20 WPM NCDXF B 2259Z
43 05Jul2020@22:59:32 (chan) <- I SK0MMR DX de LZ4UX-#: 7018.3 RW1M CW 13 dB 18 WPM CQ 2259Z
44 05Jul2020@22:59:32 (chan) <- I SK0MMR DX de LZ4AE-#: 7018.3 RW1M CW 28 dB 18 WPM CQ 2259Z
45 05Jul2020@22:59:32 (chan) <- I SK0MMR DX de W1NT-6-#: 28222.9 N1NSP/B CW 5 dB 15 WPM BEACON 2259Z
46 05Jul2020@22:59:32 (chan) <- I SK0MMR DX de W1NT-6-#: 28297.0 NS9RC CW 4 dB 13 WPM BEACON 2259Z
47 05Jul2020@22:59:32 (chan) <- I SK0MMR DX de F8DGY-#: 7018.2 RW1M CW 23 dB 18 WPM CQ 2259Z
48 05Jul2020@22:59:33 (chan) <- I SK0MMR DX de 9A1CIG-#: 7018.30 RW1M CW 20 dB 18 WPM CQ 2259Z
49 05Jul2020@22:59:33 (chan) <- I SK0MMR DX de LZ7AA-#: 7018.3 RW1M CW 16 dB 18 WPM CQ 2259Z
50 05Jul2020@22:59:33 (chan) <- I SK0MMR DX de DK9IP-#: 7018.2 RW1M CW 21 dB 18 WPM CQ 2259Z
51 05Jul2020@22:59:33 (chan) <- I SK0MMR DX de WE9V-#: 10118.0 N5JCB CW 15 dB 10 WPM CQ 2259Z
52 05Jul2020@22:59:34 (chan) <- I SK0MMR DX de DJ9IE-#: 7028.0 PT7KM CW 15 dB 10 WPM CQ 2259Z
53 05Jul2020@22:59:34 (chan) <- I SK0MMR DX de DJ9IE-#: 7018.3 RW1M CW 31 dB 18 WPM CQ 2259Z
54 05Jul2020@22:59:34 (chan) <- I SK0MMR DX de DD5XX-#: 7018.3 RW1M CW 21 dB 18 WPM CQ 2259Z
55 05Jul2020@22:59:34 (chan) <- I SK0MMR DX de DE1LON-#: 14025.5 EI5JF CW 13 dB 19 WPM CQ 2259Z
56 05Jul2020@22:59:34 (chan) <- I SK0MMR DX de DE1LON-#: 7018.3 RW1M CW 24 dB 18 WPM CQ 2259Z
57 05Jul2020@22:59:34 (chan) <- I SK0MMR DX de ON6ZQ-#: 7018.3 RW1M CW 22 dB 18 WPM CQ 2259Z
58 05Jul2020@22:59:34 (chan) <- I SK0MMR DX de OH6BG-#: 3516.9 RA1AFT CW 15 dB 25 WPM CQ 2259Z
59 05Jul2020@22:59:35 (chan) <- I SK0MMR DX de HA1VHF-#: 7018.3 RW1M CW 30 dB 18 WPM CQ 2259Z
60 05Jul2020@22:59:35 (chan) <- I SK0MMR DX de F6IIT-#: 7018.4 RW1M CW 32 dB 18 WPM CQ 2259Z
61 05Jul2020@22:59:36 (chan) <- I SK0MMR DX de HB9BXE-#: 7018.3 RW1M CW 23 dB 18 WPM CQ 2259Z
62 05Jul2020@22:59:37 (chan) <- I SK0MMR DX de SM0IHR-#: 7018.3 RW1M CW 21 dB 18 WPM CQ 2259Z
63 05Jul2020@22:59:37 (chan) <- I SK0MMR DX de DK0TE-#: 7018.3 RW1M CW 26 dB 18 WPM CQ 2259Z
64 05Jul2020@22:59:37 (chan) <- I SK0MMR DX de OE9GHV-#: 7018.3 RW1M CW 40 dB 19 WPM CQ 2259Z
65 05Jul2020@22:59:37 (chan) <- I SK0MMR DX de CX6VM-#: 10118.0 N5JCB CW 20 dB 10 WPM CQ 2259Z
66 05Jul2020@22:59:37 (chan) -> D G1TST DX de F8DGY-#: 7018.3 RW1M CW 23dB Q:9* Z:20 16 2259Z 14
67 05Jul2020@22:59:38 (chan) <- I SK0MMR DX de HB9JCB-#: 7018.3 RW1M CW 16 dB 18 WPM CQ 2259Z
68 05Jul2020@22:59:39 (chan) <- I SK0MMR DX de HB9JCB-#: 3516.9 RA1AFT CW 9 dB 26 WPM CQ 2259Z
69 05Jul2020@22:59:39 (chan) <- I SK0MMR DX de KO7SS-7-#: 14057.6 K7GT CW 6 dB 21 WPM CQ 2259Z
70 05Jul2020@22:59:39 (chan) <- I SK0MMR DX de K9LC-#: 28169.9 VA3XCD/B CW 9 dB 10 WPM BEACON 2259Z
71 05Jul2020@22:59:40 (chan) <- I SK0MMR DX de HB9DCO-#: 7018.2 RW1M CW 25 dB 18 WPM CQ 2259Z
72 05Jul2020@22:59:40 (chan) <- I SK0MMR DX de EA5WU-#: 7018.3 RW1M CW 19 dB 18 WPM CQ 2259Z
74 * I normalise the frequency and cache up to 9 copies from different
75 spots. In order to do this I have to wait a few (comfigurable) seconds
76 for the client to collect a reasonable number of copies. More copies
77 may come in after 9 copies have been. Once I have enough copies to be
78 sure that the callsign is at least agreeed upon by more than one
79 skimmer, or the wait timer goes off, I emit a spot. An example of
80 which is shown above in the spot sent to G1TST. By this means I can
81 reduce the number of spots sent to a node user by up to a factor of 10
82 for CW etc spots and about 8 for FTx spots.
84 * No RBN spots can leak out of the node to the general cluster. Each
85 node that wants to use the RBN *must* establish their own
86 connections to the RBN.
88 * Currently no RBN spots are stored. This may well change but how and
89 where these spots are stored is not yet decided. Only "new" spots
90 will be stored (if they are).
92 * There are some things that need to be said:
94 a) The input format from the RBN is not the same as format emitted by
95 the cluster node. This is part of the unhelpfulness to mixing a raw
96 RBN feed with normal spots.
98 b) Each spot sent out to a node user has a "Qwalitee" marker, In this
99 case Q:9*. The '9' means that I have received 9 copies of this spot
100 from different skimmers and, in this case, they did not agree on the
101 frequency (7018.2 - 7018.4) which is indicated by a '*'. The frequency
102 shown is the majority decision. If this station has been active for
103 some time and he is still calling CQ after some time (configurable,
104 but currently 60 minutes) and gaps for QSOs or tea breaks are ignored,
105 then a '+' character will be added.
107 c) I ditch the WPM and the 'CQ' as not being hugely relevant.
109 d) If there is a Z:nn[,mm...] is there it means that this call was also heard
110 in CQ Zone 20. There can a ',' separated list of as many zones as
111 there the space available (and this spot call was heard by :-). You
112 will notice the spot zone and skimmer call zone around the time. This
113 can be activated with a 'set/dxcq' command. This is completely
116 e) I shorten the skimmer callsign to 6 characters, before (re-)adding
117 '-#' on the end to minimise the movement rightwards as in the incoming
118 spot from KO7SS-7-# just two lines below G1TST. There are some very
119 strange skimmer callsigns.
121 f) I have a filter set (accept/spot by_zone 14 and not zone 14 or zone
122 14 and not by_zone 14) which will give me the first spot that either
123 spot or skimmer is in zone 14 but the other isn't. For those of us
124 that are bad at zones (like me) sh/dxcq is your friend. You can have
125 separate filters just for RBN spots if you want something different to
126 your spot filters. Use acc/rbn or rej/rbn. NB: these will completely
127 override your spot filters for RBN spots. Obviously "real" spots will
128 will continue to use the spot filter(s).
130 g) If there is NO filter in operation, then the skimmer spot with the
131 LOWEST signal strength will be shown. This implies that if any extra
132 zone are shown then the signal will be higher.
134 h) A filter can further drastically reduce the output sent to the
135 user. As this STATS line shows:
137 23:22:45 (*) RBN:STATS hour SK0MMR raw: 5826 sent: 555 delivered: 70 users: 1
139 For this hour, I received 5826 raw spots from the CW etc RBN, which
140 produced 555 possible spots, which my filter reduced to 70 that were
141 actually delivered to G1TST. For the FTx RBN, I don't have a filter
142 active and so I got all the possibles:
144 23:22:45 (*) RBN:STATS hour SK1MMR raw: 13354 sent: 1745 delivered: 1745 users: 1
146 ---------------------------------------------------------------------
148 So how do you go about using this:
150 First you need to create an RBN user. Now you can use any call you
151 like and it won't be visible outside of the node. I call mine SK0MMR
154 set/rbn sk0mmr sk1mmr
156 Now create connect scripts in /spider/connect/sk0mmr (and similarly
157 sk1mmr). They look like this:
159 /spider/connect/sk0mmr:
161 connect telnet telnet.reversebeacon.net 7000
162 'call:' '<node callsign here'
164 /spider/connect/sk1mmr:
166 connect telnet telnet.reversebeacon.net 7001
167 'call:' '<node callsign here'
169 RBN port 7000 is the "traditional" port for anything except FT4 or FT8
170 spots. They come from RBN port 7001.
172 Now put them in your local crontab in /spider/local_cmd/crontab:
174 * * * * * start_connect('sk0mmr') unless connected('sk0mmr')
175 * * * * * start_connect('sk1mmr') unless connected('sk1mmr')
177 This will check once every minute to see if each RBN connection is
178 active, you can check with the 'links' command:
180 Ave Obs Ping Next Filters
181 Callsign Type Started Uptime RTT Count Int. Ping Iso? In Out PC92? Address
182 GB7DJK DXSP 5-Jul-2020 1722Z 7h 6m 8s 0.02 2 300 89 Y 163.172.11.79
183 SK0MMR RBN 5-Jul-2020 1722Z 7h 6m 8s 0 0 198.137.202.75
184 SK1MMR RBN 5-Jul-2020 1722Z 7h 6m 8s 0 0 198.137.202.75
186 The connections are sometimes dropped or become stuck, I have a
187 mechanism to detect this and it will disconnect that connection and
188 the normal reconnection will happen just as any other (normal) node.
190 It is put in the crontab, rather than started immediately, to prevent
191 race conditions (or just slow them down to one disconnection a
194 The first time a connection is made, after node startup, there is a 5
195 minute pause before RBN spots come out for users. This is done to fill
196 up (or "train") the cache. Otherwise the users will be overwhelmed by
197 spots - it slows down reasonably quickly - but experiment shows that 5
198 minutes is a reasonable compromise. The delay is configurable,
199 globally, for all RBN connections, but in future is likely to be
200 configurable per connection. Basically, because the FTx RBN data is
201 much more bursty and there is more of it (except on CW contests), it
202 could do with a somewhat longer training period.
204 If a connection drops and reconnects. There is no delay or extra
207 For users. At the moment. There is a single command that sets or
208 unsets ALL RBN spot sorts:
213 Very soon this will be replaced with a '(un)set/skimmer' command that
214 allow the user to choose which categories they want. Filtering can be
215 used in conjunction with this proposed command to further refine
218 This still very much "work in progress" and will be subject to
219 change. But I am grateful to the feedback I have received, so far,
227 But if you have comments, suggestions and brickbats please email me or