<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">VE2PKT via Dxspider-support je
14.5.2022 ob 4:55 napisal:<br>
</div>
<blockquote type="cite"
cite="mid:df0d2aaf-f1c5-3c3f-3128-ea5e438cc740@gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
Sorry Guy's, But what is MoJo?</blockquote>
<p>See UPGRADE.mojo and RBN.mojo files form the spider root
directory.</p>
<p>Good luck, Dan S50U</p>
<p><br>
</p>
<p>9th July 2020<br>
-------------<br>
<br>
There are the notes for upgrading to the mojo branch. PLEASE NOTE<br>
THERE HAVE BEEN CHANGES FOR all MOJO BRANCH USERS. See APPENDIX(i)
at<br>
the end of this document.<br>
<br>
There is NO POINT in doing this at the moment unless you are
running a<br>
node with many (>50) users. It is the future, but at the moment
I am<br>
testing larger and larger installations to check that it a) still<br>
works as people imagine it should and b) it provides the
improvement<br>
in scaling that I am anticipating. There are no significant new<br>
features - yet.<br>
<br>
The BIG TICKET ITEM in this branch is that (potentially) "long
lived"<br>
commands such as sh/dx and commands that poll external internet<br>
resources now don't halt the flow of data through the node. I am
also<br>
using a modern, event driven, web socket "manager" called
Mojolicious<br>
which is considerably more efficient than what went before (but is
not<br>
necessary for small nodes). There are some 200-400 user nodes out<br>
there that will definitely see the difference in terms of both CPU<br>
usage and general responsiveness. Using Mojolicious also brings
the<br>
tantalising possibility of grafting on a web frontend, as it were,
to<br>
the "side" of a DXSpider node. But serious work on this won't
start<br>
until we have a stable base to work on. Apart from anything else
there<br>
will, almost certainly, need to be some internal data structure<br>
reorganisation before a decent web frontend could be constructed.<br>
<br>
*IMPORTANT* There is an action needed to go from mojo build 228
and<br>
*below. See items marked IMPORTANT* below.<br>
<br>
Upgrading is not for the faint of heart. There is no installation<br>
script (but there will be) so, for the time being, you need to do
some<br>
manual editing. Also, while there is a backward path, it will
involve<br>
moving various files from their new home (/spider/local_data),
back to<br>
where they came from (/spider/data).<br>
<br>
Prerequisites:<br>
<br>
A supply of good, strong tea - preferably in pint mugs. A tin
hat,<br>
stout boots, a rucksack with survival rations and a decent
miners'<br>
lamp might also prove comforting. I enclose this link:<br>
<a class="moz-txt-link-freetext" href="http://www.noswearing.com/dictionary">http://www.noswearing.com/dictionary</a> in case you run out of
swear<br>
words.<br>
<br>
An installed and known working git based installation. Mojo is
not<br>
supported under CVS or installation from a tarball.<br>
<br>
perl 5.10.1, preferably 5.14.1 or greater. This basically
means<br>
running ubuntu 12.04 or later (or one of the other linux
distros<br>
of similar age or later). The install instructions are for
debian<br>
based systems. IT WILL NOT WORK WITHOUT A "MODERN" PERL. Yes,
you<br>
can use bleadperl if you know how to use it and can get it to
run<br>
the node under it as a daemon without resorting the handy URL<br>
supplied above. Personally, I wouldn't bother. It's easier and<br>
quicker just to upgrade your linux distro. Apart from anything<br>
else things like ssh ntpd are broken on ALL older systems and
will<br>
allow the ungodly in more easily than something modern.<br>
<br>
Install cpamminus:<br>
<br>
sudo apt-get install cpanminus<br>
or<br>
wget -O - <a class="moz-txt-link-freetext" href="https://cpanmin.us">https://cpanmin.us</a> | perl - --sudo App::cpanminus<br>
or<br>
sudo apt-get install curl<br>
curl -L <a class="moz-txt-link-freetext" href="https://cpanmin.us">https://cpanmin.us</a> | perl - --sudo App::cpanminus<br>
<br>
You will need the following CPAN packages:<br>
<br>
If you are on a Debian based system (Devuan, Ubuntu, Mint etc)<br>
that is reasonably new (I use Ubuntu 18.04 and Debian 10) then
you<br>
can simply do:<br>
<br>
sudo apt-get install libev-perl libmojolicious-perl
libjson-perl libjson-xs-perl libdata-structure-util-perl
libmath-round-perl<br>
<br>
or on Redhat based systems you can install the very similarly
(but<br>
not the same) named packages. I don't know the exact names but<br>
using anything less than Centos 7 is likely to cause a world
of<br>
pain. Also I doubt that EV and Mojolicious are packaged for
Centos<br>
at all.<br>
<br>
If in doubt or it is taking too long to find the packages you<br>
should build from CPAN. Note: you may need to install the<br>
essential packages to build some of these. At the very least
you<br>
will need to install 'make' (sudo apt-get install make) or
just<br>
get everything you are likely to need with:<br>
<br>
sudo apt-get install build-essential.<br>
<br>
sudo cpanm EV Mojolicious JSON JSON::XS <a class="moz-txt-link-freetext" href="Data::Structure::Util">Data::Structure::Util</a>
Math::Round<br>
<br>
# just in case it's missing (top, that is)<br>
sudo apt-get install procps<br>
<br>
Please make sure that, if you insist on using operating system<br>
packages, that your Mojolicious is at least version<br>
7.26. Mojo::IOLoop::ForkCall is NOT LONGER IN USE! The current
version<br>
at time of writing is 8.36.<br>
<br>
Login as the sysop user.<br>
<br>
Edit your /spider/local/DXVars.pm so that the bottom of the file
is<br>
changed from something like:<br>
<br>
---- old ----<br>
<br>
# the port number of the cluster (just leave this, unless it
REALLY matters to you)<br>
$clusterport = 27754;<br>
<br>
# your favorite way to say 'Yes'<br>
$yes = 'Yes';<br>
<br>
# your favorite way to say 'No'<br>
$no = 'No';<br>
<br>
# the interval between unsolicited prompts if not traffic<br>
$user_interval = 11*60;<br>
<br>
# data files live in <br>
$data = "$root/data";<br>
<br>
# system files live in<br>
$system = "$root/sys";<br>
<br>
# command files live in<br>
$cmd = "$root/cmd";<br>
<br>
# local command files live in (and overide $cmd)<br>
$localcmd = "$root/local_cmd";<br>
<br>
# where the user data lives<br>
$userfn = "$data/users";<br>
<br>
# the "message of the day" file<br>
$motd = "$data/motd";<br>
<br>
# are we debugging ?<br>
@debug = qw(chan state msg cron );<br>
<br>
---- to this: ----<br>
<br>
# the port number of the cluster (just leave this, unless it
REALLY matters to you)<br>
$clusterport = 27754;<br>
<br>
# your favorite way to say 'Yes'<br>
$yes = 'Yes';<br>
<br>
# your favorite way to say 'No'<br>
$no = 'No';<br>
<br>
# this is where the paths used to be which you have just
removed<br>
<br>
# are we debugging ?<br>
@debug = qw(chan state msg cron );<br>
<br>
---- new ------<br>
<br>
There may be other stuff after this in DXVars.pm, that doesn't<br>
matter. The point is to remove all the path definitions in<br>
DXVars.pm. If this isn't clear to you then it would be better if
you<br>
asked on dxspider-support for help before attempting to go any<br>
further.<br>
<br>
One of the things that will happen is that several files currently
in<br>
/spider/data will be placed in /spider/local_data. These include
the<br>
user, qsl and usdb data files, the band and prefix files, and
various<br>
"bad" data files. I.e. everything that is modified from the base
git<br>
distribution.<br>
<br>
Now run the console program or telnet localhost and login as the
sysop<br>
user.<br>
<br>
export_users<br>
bye<br>
<br>
as the sysop user:<br>
<br>
sudo service dxspider stop<br>
or<br>
sudo systemctl stop dxspider<br>
<br>
having stopped the node:<br>
<br>
mkdir /spider/local_data<br>
git reset --hard<br>
git pull --all<br>
git checkout --track -b mojo origin/mojo<br>
<br>
if you have not already done this:<br>
<br>
sudo ln -s /spider/perl/console.pl /usr/local/bin/dx<br>
sudo ln -s /spider/perl/*dbg /usr/local/bin<br>
<br>
Now in another window run:<br>
<br>
watchdbg<br>
<br>
and finally:<br>
<br>
sudo service dxspider start<br>
or<br>
sudo service systemctl start dxspider<br>
<br>
You should be aware that this code base is now under active<br>
development and, if you do a 'git pull', what you get may be<br>
broken. But, if this does happen, the likelihood is that I am
actively<br>
working on the codebase and any brokenness may be fixed (maybe in<br>
minutes) with another 'git pull'.<br>
<br>
I try very hard not to leave it in a broken state...<br>
<br>
Dirk G1TLH<br>
<br>
APPENDIX(i)<br>
<br>
Before shutting down to do the update, do a 'sh/ver' and take node
of<br>
the current git revision number (the hex string after "git: mojo/"
and<br>
the "[r]"). Also do an 'export_users' (belt and braces).<br>
<br>
With this revision of the code, the users.v3 file will be replaced<br>
with users.v3j. On restarting the node, the users.v3j file will
be<br>
generated from the users.v3 file. The users.v3 file is not
changed.<br>
The process of generation will take up to 30 seconds depending on
the<br>
number of users in your file, the speed of your disk(s) and the
CPU<br>
speed (probably in that order. On my machine, it takes about 5<br>
seconds, on an RPi??? This is a reversable change. Simply checkout
the<br>
revision you noted down before ("git checkout <reversion>")
and email<br>
me should anything go wrong.<br>
<br>
Part of this process may clear out some old records or suggest
that<br>
there might errors. DO NOT BE ALARM. This is completely normal.<br>
<br>
This change not only should make the rebuilding of the users file<br>
(much) less likely, but tests suggest that access to the users
file is<br>
about 2.5 times quicker. How much difference this makes in
practise<br>
remains to be seen.<br>
<br>
When you done this, in another shell, run<br>
/spider/perl/create_dxsql.pl. This will convert the DXQSL system
to<br>
dxqsl.v1j (for the sh/dxqsl <call> command). When this is
finished,<br>
run 'load/dxqsl' in a console (or restart the node, but it isn't<br>
necessary).<br>
<br>
This has been done to remove Storable - completely - from active
use<br>
in DXSpider. I have started to get more reports of user file<br>
corruptions in the last year than I ever saw in the previous 10.
One<br>
advantage of this is that change is that user file access is now
2.5<br>
times faster. So things like 'export_users' should not stop the
node<br>
for anything like as long as the old version.<br>
<br>
On the subject of export_users. Once you are happy with the
stability<br>
of the new version, you can clean out all your user_asc.* files
(I'd<br>
keep the 'user_asc' that you just created for emergencies). The
modern<br>
equivalent of this file is now called 'user_json' and can used in<br>
exactly the same way as 'user_asc' to restore the users.v3j file
(stop<br>
the node; cd /spider/local_data; perl user_json; start the node).</p>
<p><br>
</p>
<p>9th July 2020<br>
-------------<br>
<br>
IF YOU ARE ON THE MASTER BRANCH, STOP (I REPEAT) STOP READING THIS<br>
DOCUMENT AND READ UPGRADE.mojo FIRST.<br>
<br>
<br>
If you are not on an existing 'mojo' branch, or you have a build
less<br>
than 260, please stop reading as well and read UPGRADE.mojo (in
the<br>
section about installing packages), as you need to install some
extra<br>
packages before restarting the new version of the code. If in
doubt<br>
try installing the packages again as this will either confirm that
all<br>
is already done or will install what's missing.<br>
<br>
Assuming you have done the above:<br>
<br>
The latest release of the Mojo branch of DXSpider contains a
client<br>
for the Reverse Beacon Network (RBN). This is not a simple client,
it<br>
attempts to make some sense of the 10s of 1000s of "spots" that
the<br>
RBN can send PER HOUR. At busy times, actually nearly all the
time, the<br>
spots from the RBN come in too quickly for anybody to get anything
more<br>
than a fleeting impression of what's coming in.<br>
<br>
Something has to try to make this manageable - which is what I
have<br>
tried to do with DXSpider's RBN client.<br>
<br>
The RBN has a number of problems (apart from the overwhelming
quantity<br>
of data that it sends):<br>
<br>
* Spotted callsigns, especially on CW, are not reliably<br>
decoded. Estimates vary as to how bad it is but, as far as I can<br>
tell, even these estimates are unreliable!<br>
<br>
* The frequency given is unreliable. I have seen differences as
great<br>
as 600hz on CW spots.<br>
<br>
* There is far too much (in my view) useless information in each
spot<br>
- even if one had time to read, decode and understand it before
the<br>
spot has scrolled off the top of the screen.<br>
<br>
* The format of the comment is not regular. If one has both FTx
and<br>
"all the other" spots (CW, PSK et al) enabled at the same time,<br>
one's eye is constantly having to re-adjust. Again, very
difficult<br>
to deal with on contest days. Especially if it mixed in with<br>
"normal" spots.<br>
<br>
So what have I done about this? Look at the sample of input
traffic<br>
below:<br>
<br>
05Jul2020@22:59:31 (chan) <- I SK0MMR DX de KM3T-2-#: 14100.0
CS3B CW 24 dB 22 WPM NCDXF B 2259Z<br>
05Jul2020@22:59:31 (chan) <- I SK0MMR DX de KM3T-2-#: 28263.9
AB8Z/B CW 15 dB 18 WPM BEACON 2259Z<br>
05Jul2020@22:59:31 (chan) <- I SK0MMR DX de LZ3CB-#: 7018.20
RW1M CW 10 dB 18 WPM CQ 2259Z<br>
05Jul2020@22:59:31 (chan) <- I SK0MMR DX de W9XG-#: 14057.6
K7GT CW 7 dB 21 WPM CQ 2259Z<br>
05Jul2020@22:59:31 (chan) <- I SK0MMR DX de G0LUJ-#: 14100.1
CS3B CW 18 dB 20 WPM NCDXF B 2259Z<br>
05Jul2020@22:59:32 (chan) <- I SK0MMR DX de LZ4UX-#: 7018.3
RW1M CW 13 dB 18 WPM CQ 2259Z<br>
05Jul2020@22:59:32 (chan) <- I SK0MMR DX de LZ4AE-#: 7018.3
RW1M CW 28 dB 18 WPM CQ 2259Z<br>
05Jul2020@22:59:32 (chan) <- I SK0MMR DX de W1NT-6-#: 28222.9
N1NSP/B CW 5 dB 15 WPM BEACON 2259Z<br>
05Jul2020@22:59:32 (chan) <- I SK0MMR DX de W1NT-6-#: 28297.0
NS9RC CW 4 dB 13 WPM BEACON 2259Z<br>
05Jul2020@22:59:32 (chan) <- I SK0MMR DX de F8DGY-#: 7018.2
RW1M CW 23 dB 18 WPM CQ 2259Z<br>
05Jul2020@22:59:33 (chan) <- I SK0MMR DX de 9A1CIG-#: 7018.30
RW1M CW 20 dB 18 WPM CQ 2259Z<br>
05Jul2020@22:59:33 (chan) <- I SK0MMR DX de LZ7AA-#: 7018.3
RW1M CW 16 dB 18 WPM CQ 2259Z<br>
05Jul2020@22:59:33 (chan) <- I SK0MMR DX de DK9IP-#: 7018.2
RW1M CW 21 dB 18 WPM CQ 2259Z<br>
05Jul2020@22:59:33 (chan) <- I SK0MMR DX de WE9V-#: 10118.0
N5JCB CW 15 dB 10 WPM CQ 2259Z<br>
05Jul2020@22:59:34 (chan) <- I SK0MMR DX de DJ9IE-#: 7028.0
PT7KM CW 15 dB 10 WPM CQ 2259Z<br>
05Jul2020@22:59:34 (chan) <- I SK0MMR DX de DJ9IE-#: 7018.3
RW1M CW 31 dB 18 WPM CQ 2259Z<br>
05Jul2020@22:59:34 (chan) <- I SK0MMR DX de DD5XX-#: 7018.3
RW1M CW 21 dB 18 WPM CQ 2259Z<br>
05Jul2020@22:59:34 (chan) <- I SK0MMR DX de DE1LON-#: 14025.5
EI5JF CW 13 dB 19 WPM CQ 2259Z<br>
05Jul2020@22:59:34 (chan) <- I SK0MMR DX de DE1LON-#: 7018.3
RW1M CW 24 dB 18 WPM CQ 2259Z<br>
05Jul2020@22:59:34 (chan) <- I SK0MMR DX de ON6ZQ-#: 7018.3
RW1M CW 22 dB 18 WPM CQ 2259Z<br>
05Jul2020@22:59:34 (chan) <- I SK0MMR DX de OH6BG-#: 3516.9
RA1AFT CW 15 dB 25 WPM CQ 2259Z<br>
05Jul2020@22:59:35 (chan) <- I SK0MMR DX de HA1VHF-#: 7018.3
RW1M CW 30 dB 18 WPM CQ 2259Z<br>
05Jul2020@22:59:35 (chan) <- I SK0MMR DX de F6IIT-#: 7018.4
RW1M CW 32 dB 18 WPM CQ 2259Z<br>
05Jul2020@22:59:36 (chan) <- I SK0MMR DX de HB9BXE-#: 7018.3
RW1M CW 23 dB 18 WPM CQ 2259Z<br>
05Jul2020@22:59:37 (chan) <- I SK0MMR DX de SM0IHR-#: 7018.3
RW1M CW 21 dB 18 WPM CQ 2259Z<br>
05Jul2020@22:59:37 (chan) <- I SK0MMR DX de DK0TE-#: 7018.3
RW1M CW 26 dB 18 WPM CQ 2259Z<br>
05Jul2020@22:59:37 (chan) <- I SK0MMR DX de OE9GHV-#: 7018.3
RW1M CW 40 dB 19 WPM CQ 2259Z<br>
05Jul2020@22:59:37 (chan) <- I SK0MMR DX de CX6VM-#: 10118.0
N5JCB CW 20 dB 10 WPM CQ 2259Z<br>
05Jul2020@22:59:37 (chan) -> D G1TST DX de F8DGY-#: 7018.3
RW1M CW 23dB Q:9* Z:20 16 2259Z 14<br>
05Jul2020@22:59:38 (chan) <- I SK0MMR DX de HB9JCB-#: 7018.3
RW1M CW 16 dB 18 WPM CQ 2259Z<br>
05Jul2020@22:59:39 (chan) <- I SK0MMR DX de HB9JCB-#: 3516.9
RA1AFT CW 9 dB 26 WPM CQ 2259Z<br>
05Jul2020@22:59:39 (chan) <- I SK0MMR DX de KO7SS-7-#:
14057.6 K7GT CW 6 dB 21 WPM CQ 2259Z<br>
05Jul2020@22:59:39 (chan) <- I SK0MMR DX de K9LC-#: 28169.9
VA3XCD/B CW 9 dB 10 WPM BEACON 2259Z<br>
05Jul2020@22:59:40 (chan) <- I SK0MMR DX de HB9DCO-#: 7018.2
RW1M CW 25 dB 18 WPM CQ 2259Z<br>
05Jul2020@22:59:40 (chan) <- I SK0MMR DX de EA5WU-#: 7018.3
RW1M CW 19 dB 18 WPM CQ 2259Z<br>
<br>
* As you can see, there are frequently more than one spotter for a<br>
callsign:<br>
<br>
* I normalise the frequency and cache up to 9 copies from
different<br>
spots. In order to do this I have to wait a few (configurable)
seconds<br>
for the client to collect a reasonable number of copies. More
copies <br>
may come in after 9 copies have been received. Once I have
enough <br>
copies to be sure that the callsign is at least agreeed upon by
more<br>
than one skimmer, or the wait timer goes off, I emit a spot. By
this<br>
means I can reduce the number of spots sent to a node user by up
to a<br>
factor of around 10 for CW etc spots and about 8 for FTx spots.<br>
<br>
For example, from the trace above, all the RW1M RBN spots become
just<br>
one line:<br>
<br>
DX de F8DGY-#: 7018.3 RW1M CW 23dB Q:9*
Z:20 16 2259Z 14<br>
<br>
* No RBN spots can leak out of the node to the general cluster.
Each<br>
node that wants to use the RBN *must* establish their own<br>
connections to the RBN.<br>
<br>
* Currently no RBN spots are stored. This may well change but how
and<br>
where these spots are stored is not yet decided. Only "DXSpider<br>
curated" spots (like the example above) will be stored (if/when
they<br>
are). Sh/dx will be suitably modified if storage happens. <br>
<br>
* There are some things that need to be explained:<br>
<br>
a) The input format from the RBN is not the same as format emitted
by<br>
the cluster node. This is part of the unhelpfulness to mixing a
raw<br>
RBN feed with normal spots.<br>
<br>
b) Each spot sent out to a node user has a "Qwalitee" marker, In
this<br>
case Q:9*. The '9' means that I have received 9 copies of this
spot<br>
from different skimmers and, in this case, they did not agree on
the<br>
frequency (7018.2 - 7018.4) which is indicated by a '*'. The
frequency<br>
shown is the majority decision. If this station has been active
for<br>
for a while and he is still calling CQ after some time
(configurable,<br>
but currently 60 minutes), ignoring gaps for QSOs or tea breaks,
then<br>
a '+' character will be added.<br>
<br>
If the "Qualitee" Q:1 is seen on a CW spot, then only one skimmer
has<br>
seen that spot and the callsign *could* be wrong, but frequently,
if<br>
it is wrong, it is more obvious than the example below. But if Q
is<br>
Q:2 and above, then the callsign is much more likely to be
correct.<br>
<br>
DX de DJ9IE-#: 14034.9 UN7BBD CW 4dB Q:5*+
17 1444Z 14<br>
DX de OL7M-#: 14037.9 UA6LQ CW 13dB Q:7
16 1448Z 15<br>
DX de LZ3CB-#: 28050.2 DL4HRM CW 7dB Q:1
14 1448Z 20<br>
<br>
Having said that, I check every spots call with the standard
DXSpider<br>
is_callsign routine, to check that the callign is a valid format.
Then<br>
through the Prefix::search routine, to check that the prefix
actually<br>
exists. If either of these checks fails then the spot is ignored.<br>
<br>
c) I ditch the WPM and the 'CQ' as not being hugely relevant. <br>
<br>
d) If there is a Z:nn[,mm...], then this spot was also heard by<br>
skimmers in other zones. In this example, it means that this call
was<br>
also heard in CQ Zone 20. This list does NOT include the cq zone
of<br>
the skimmer nor the spot. If you would like to see these then do<br>
'set/dxcq'. This setting is active for all the examples in this<br>
document. This is completely optional.<br>
<br>
There can be a ',' separated list of as many zones where this spot
was<br>
also heard by another skimmers, up to the space available in the<br>
comment area.<br>
<br>
DX de LZ4UX-#: 14015.5 ON7TQ CW 6dB Q:9 Z:5,14,15,40
14 0646Z 20<br>
DX de VE7CC-#: 3573.0 N8ADO FT8 -14dB Q:4
Z:4,5 4 0647Z 3<br>
DX de DM7EE-#: 14027.5 R1AC CW 9dB Q:9* Z:5,15,17,20
16 0643Z 14<br>
DX de WE9V-#: 7074.0 EA7ALL FT8 -9dB Q:2+ Z:5
14 0641Z 4<br>
<br>
e) I shorten the skimmer callsign to 6 characters - having first<br>
chopped off any SSIDs, spurious /xxx strings from the end, leaving<br>
just the base callsign, before (re-)adding '-#' on the end. This
is<br>
done to minimise the misalignment of the spot rightwards, as in
the<br>
incoming skimmer spot from KO7SS-7-# below. There are some very<br>
strange skimmer callsigns with all sorts of spurious endings, all
of<br>
which I attempt to reduce to the base callsign. Some skimmer base<br>
callsigns still might be shortened for display purposes. Things
like<br>
'3V/K5WEM' won't fit in six characters but the whole base callsign
is<br>
used for zone info internally, but only the first 6 characters are<br>
displayed in any spot.<br>
<br>
05Jul2020@22:59:39 (chan) <- I SK0MMR DX de HB9JCB-#: 3516.9
RA1AFT CW 9 dB 26 WPM CQ 2259Z<br>
05Jul2020@22:59:39 (chan) <- I SK0MMR DX de KO7SS-7-#:
14057.6 K7GT CW 6 dB 21 WPM CQ 2259Z<br>
05Jul2020@22:59:39 (chan) <- I SK0MMR DX de K9LC-#: 28169.9
VA3XCD/B CW 9 dB 10 WPM BEACON 2259Z<br>
<br>
f) I happen to have a filter set (accept/spot by_zone 14 and not
zone<br>
14 or zone 14 and not by_zone 14) which will give me the first
spot<br>
that either spot or skimmer is in zone 14 but its companion isn't.
For<br>
those of us that are bad at zones (like me) sh/dxcq is your<br>
friend. You can have separate filters just for RBN spots if you
want<br>
something different to your spot filters. Use acc/rbn or rej/rbn.
NB:<br>
these will completely override your spot filters for RBN<br>
spots. Obviously "real" spots will will continue to use the spot<br>
filter(s). If you use set/dxcq, then unset/dxitu and unset/dxgrid<br>
first. You only need to this once.<br>
<br>
g) If there is NO filter in operation, then the skimmer spot with
the<br>
LOWEST signal strength will be shown. This implies that if any
extra<br>
zones are shown, then the signal will be higher in those zones.<br>
<br>
h) A filter can further drastically reduce the output sent to the<br>
user. As this STATS line shows:<br>
<br>
23:22:45 (*) RBN:STATS hour SK0MMR raw: 5826 sent: 555 delivered:
70 users: 1<br>
<br>
For this hour, I received 5826 raw spots from the CW etc RBN,
which<br>
produced 555 possible spots, which my filter reduced to 70 that
were<br>
actually delivered to G1TST. For the FTx RBN, I don't have a
filter<br>
active and so I got all the possibles:<br>
<br>
23:22:45 (*) RBN:STATS hour SK1MMR raw: 13354 sent: 1745
delivered: 1745 users: 1<br>
<br>
---------------------------------------------------------------------<br>
<br>
So how do you go about using this:<br>
<br>
First you need to create one or two RBN user(s). Now you can use
any call you<br>
like and it won't be visible outside of the node. I call mine
SK0MMR<br>
and SK1MMR. One of these connects to the "standard" RBN port that<br>
outputs CW, BEACON, DXF, PSK and RTTY spots, and the other
connects to<br>
the RBN port that just outputs FT4 and FT8 spots.<br>
<br>
set/rbn sk0mmr sk1mmr<br>
<br>
Now create connect scripts in /spider/connect/sk0mmr (and
similarly<br>
sk1mmr). They look like this:<br>
<br>
/spider/connect/sk0mmr:<br>
<br>
connect telnet telnet.reversebeacon.net 7000<br>
'call:' '<node callsign here'<br>
<br>
/spider/connect/sk1mmr:<br>
<br>
connect telnet telnet.reversebeacon.net 7001<br>
'call:' '<node callsign here'<br>
<br>
Now put them in your local crontab in /spider/local_cmd/crontab:<br>
<br>
* * * * * start_connect('sk0mmr') unless connected('sk0mmr')<br>
* * * * * start_connect('sk1mmr') unless connected('sk1mmr')<br>
<br>
This will check once every minute to see if each RBN connection is<br>
active, you can check what is connected with the 'links' command:<br>
<br>
Ave Obs Ping
Next Filters<br>
Callsign Type Started Uptime RTT Count Int.
Ping Iso? In Out PC92? Address<br>
GB7DJK DXSP 5-Jul-2020 1722Z 7h 6m 8s 0.02 2
300 89 Y 163.172.11.79<br>
SK0MMR RBN 5-Jul-2020 1722Z 7h 6m 8s
0 0 198.137.202.75<br>
SK1MMR RBN 5-Jul-2020 1722Z 7h 6m 8s
0 0 198.137.202.75<br>
<br>
The RBN connections are sometimes dropped or become stuck. I have
a<br>
mechanism to detect this and it will disconnect that RBN
connection<br>
and, by this means,it will be automatically reconnected by the<br>
crontab, just like any other (normal) node.<br>
<br>
I use the crontab, rather than restarting immediately after<br>
disconnection, to prevent race conditions (or just slow them down
to<br>
one disconnection a minute).<br>
<br>
The first time a connection is made, after node startup, there is
a 5 (configurable)<br>
minute pause before RBN spots come out for users. This is done to
fill<br>
up (or "train") the cache. Otherwise the users will be overwhelmed
by<br>
spots - it slows down reasonably quickly - but experiment shows
that 5<br>
minutes is a reasonable compromise. The delay is configurable,<br>
globally, for all RBN connections, but in future is likely to be<br>
configurable per connection. Basically, because the FTx RBN data
is<br>
much more bursty and there is more of it (except on CW contests),
it<br>
could do with a somewhat longer training period than the CW etc
RBN<br>
connection.<br>
<br>
If a connection drops and reconnects. There is no delay or extra<br>
training time. If the node is stopped and restarted within a few<br>
minutes, then no training time will occur.<br>
<br>
For users. At the moment. There is a single command that sets or<br>
unsets ALL RBN spot sorts:<br>
<br>
Users can select which type(s) of RBN/Skimmer spot they require
using<br>
the 'set/skimmer' command. Users can enter the 'help set/skimmer'<br>
command for more information on this. They can also enter then
'help<br>
rbn' command for more information about how to interpret what
DXSpider<br>
produces and some other useful background information.<br>
<br>
This still very much "work in progress" and will be subject to<br>
change. But I am grateful to the feedback I have received, so far,<br>
from:<br>
<br>
Kin EA3CV<br>
Andy G4PIQ<br>
Mike G8TIC<br>
Lee VE7CC<br>
<br>
But if you have comments, suggestions or even brickbats, please
email<br>
me or the support list.<br>
<br>
Dirk G1TLH</p>
<div class="moz-signature">-- <br>
<a href="http://www.hervardi.com/osti_jarej.php">Osti jarej!</a></div>
</body>
</html>