[Dxspider-support] Alternative/additional comment elements in spots
Rob Harrison
g4ujs at outlook.com
Fri Jan 14 12:49:19 GMT 2022
Bravo Dirk!!! 😊
From: Dxspider-support <dxspider-support-bounces at tobit.co.uk> On Behalf Of Dirk Koopman via Dxspider-support
Sent: 14 January 2022 12:39
To: dxspider-support at tobit.co.uk
Cc: Dirk Koopman <djk at tobit.co.uk>
Subject: Re: [Dxspider-support] Alternative/additional comment elements in spots
Björn
Firstly, could I gently point out that DXSpider is being used by more nodes than any other software put together - by quite a large margin. And this has been the case since well before ARC6 became available (1997 in my case). It is a continuing source of irritation that I am called "to account" for why I change something (particularly in spot formatting) by various logging programs that *insist* on trying parse the output that is designed for humans, instead of using the various machine readable outputs that available in DXSpider (which, incidentally. I would be quite willing to modify or add to). As yet, no logging program author has *ever* engaged with me constructively to do something better.
Having said that, on the substantive question that you have asked. The answer is a definite no. I am not going to substantially change it and, I am not about to turn DXSpider into an RBN or PSKReporter amplifier. Or at least not in the lightly edited and wasteful form that ARC6 does it.
As an aside, I am doing some preliminary research on integrating PSKReporter into the current RBN system. But it will not do it in the same way the RBN (input) interface does it at the moment (because the limited number of connections that PSKReporter allows); therefore the RBN module, in its current internal form, will change with it. An announcement will be made about that in due course - probably in a couple of months - work is at a preliminary research stage at the moment whilst I deal with the remaining security and integrity of spot reporting issues.
The issue here is the bandwidth required to both receive this data and then to explode it to interested users. The SNR of that data is, in my eyes, unacceptably low (says he politely). And your justification of ARC6's method frankly does not stand up to any scrutiny, when I challenge you (or anyone else) to parse this data by eye - in real time - make a contact (at reasonable WPM) and NOT MISS ANYTHING ELSE that might arrive in the meantime. The only way this information *might* become useful is if a(other) program parses and concentrates it in some way. I am aware that these programs may do other things, like operate your radio, even run the contact automatically. No skill required.
I have a further problem with CT1BOH's method (as documented), as the algorithm for determining the distance between a suspect spot and one that passed before is quite CPU intensive and is based on *characters*, not the *underlying* morse code which is, itself, a decode of the raw signal. As I have some form in this area (in the day job) I struggle to understand the justification for relying on the statistical analysis of third order data in order to determine what the raw signal might actually have been, while maintaining that that method is inherently better than DXSpider's. One is tying both hands behind one's back and wiggling a little finger - on one hand - whilst looking over the other shoulder and squinting at it in the mirror.
ARC6, as I understand it, has to run on quite a beefy CPU, in multiple threads to process all of this. DXSpider runs perfectly happily on DigitalOcean's smallest droplet (1 CPU and 1GB RAM) at about 10% CPU with 1000+ connected users during CQWW CW. And that matters to me. As does the bandwidth that all this consumes. DXSpider's system weeds out clearly rubbish spots, but does not try to guess what they might have been. That is my cost/benefit analysis - for what it is worth.
At its heart, CT1BOH's/ARC6's way is just another statistical method. At the same level as, but different to, mine. You pays yer money (cost free in my case) and yer takes yer choice! My method gets you a pretty decent signal but for about 3% of the RBN input, at a fraction of one CPU. You / logging programs may not like the format, but that is a detail that could be discussed.
Arguably, this sort of analysis should be done much nearer to, or preferably at, groups of skimmers that are reasonably near to each other - and with the raw signal. That way some usable diversity might become available and make all this multiple spotting - 25 or more spots (2000+ bytes) for one strong station's CQ call - redundant. It would make everyone's life a lot easier and put the CPU power where it needs to be, instead of delegating it to dxcluster nodes and ultimately "logging" programs.
Since DXSpider is a human user oriented program - at least in its default output - I asked questions of various DXers I know and came up with the format that it now has. I can spend some time defending it, if someone wants to dispute the way that it works or what it looks like. But please - if you want to do that - don't use this mailing list to do so. Either email me directly or join the cluster-tech mailing list and do it there. Even better, get the logging program authors to join in. I am getting a little tired of trying to deal with things like this second or third hand.
73 + HNY
Dirk G1TLH
On 14/01/2022 07:37, Joaquin . via Dxspider-support wrote:
I would bet on keeping the current structure of DXSpider and expanding it with some more qualifier, but it must be third-party applications that should be adapted to spider.
Regarding the possibility of receiving all the spots, that is, Q = 1, this could be implemented with a "set" command.
Kin EA3CV
El jue., 13 ene. 2022 21:54, Björn Ekelund via Dxspider-support <dxspider-support at tobit.co.uk<mailto:dxspider-support at tobit.co.uk>> escribió:
Around 2013 the world renowned contester Jose CT1BOH invented a scheme for RBN spot
quality assessment that was later implemented in AR Cluster Version 6.
Unlike the Q: method in DXSpider, the method never suppresses spots but instead tags
them with a quality assessment.
Since contest loggers like Win-Test and DXLog make use of these tags, ARC6 nodes have
been popular with contesters. It however seems it is increasingly difficult to get ARC6 nodes
to run since after the demise of the author since the software only exists in binary form
and Microsoft's updates to the .NET runtime keep killing nodes.
Being the only free cluster software in active development, DXSpider seems to be becoming the
backbone of the DX cluster.
Jose's scheme adds a tag in the rightmost end of the comment field, V for validated, ? for unknown,
B for busted (with an optional corrected call included within parentheses), and Q for QSY.
http://lists.contesting.com/_cq-contest/2013-11/msg00085.html<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.contesting.com%2F_cq-contest%2F2013-11%2Fmsg00085.html&data=04%7C01%7C%7Cb109b63293cf48d15eaa08d9d75af288%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637777607897066192%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=p8QfDfY%2FtVSa%2BQWbTTkBMWjArFw1FjLSfdka%2BsOg7BE%3D&reserved=0>
http://reversebeacon.blogspot.com/2013/08/testing-spot-quality-filters.html<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Freversebeacon.blogspot.com%2F2013%2F08%2Ftesting-spot-quality-filters.html&data=04%7C01%7C%7Cb109b63293cf48d15eaa08d9d75af288%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637777607897066192%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=z6yw0wyj0SnS5ee2M%2BN8FkFDRxFVXEwZsJ9U8uMvS6Q%3D&reserved=0>
You can see it live by connecting to any ARC6 cluster node and typing
"SET DX EXTENSION SKIMMERQUALITY". You can see an example below. There is also filtering
options but these are typically not used for contesting since you do not want to miss spots by
single skimmers.
I (and surely many other contesters) would love to see these tags available also from DXSpider.
Particularly since it seems the end of life for ARC6 is approaching.
I believe that most of the logic required to determine the tags is already there and used to determine
the Q:# elements. Supporting this use case would of course also require allowing single skimmer spots
through, since they are the spots tagged with ?.
Björn SM7IUN
DX de S50ARX-#: 14035.0 RO22NY CW 21 dB 27 WPM CQ V 1119Z
DX de BG4GOV2-#: 7017.0 JH6LDY CW 6 dB 17 WPM CQ ? 1119Z
DX de MM0ZBH-#: 14007.5 EA1EYL CW 26 dB 20 WPM CQ V 1119Z
DX de OH6BG-#: 14035.1 RO22NY CW 27 dB 27 WPM CQ V 1119Z
DX de LZ4UX-#: 14029.0 SQ6IS CW 6 dB 19 WPM CQ ? 1119Z
DX de HB9JCB-#: 21031.3 DL0AET CW 6 dB 22 WPM CQ (DL0AA) B 1119Z
DX de HB9CAT-#: 14025.6 UA9MA CW 12 dB 32 WPM CQ V 1119Z
DX de UA0S-#: 14035.0 RO22NY CW 3 dB 28 WPM CQ V 1119Z
DX de OH4KA-#: 7011.0 LY13LY CW 5 dB 26 WPM CQ V 1119Z
DX de DO4DXA-#: 14007.5 EA1EYL CW 23 dB 20 WPM CQ V 1119Z
DX de DO4DXA-#: 14024.0 RC6AQ CW 10 dB 23 WPM CQ Q 1119Z
DX de TF4X-#: 14051.9 ON6KE CW 22 dB 18 WPM CQ ? 1119Z
DX de OG66X-#: 14051.9 ON6KE CW 30 dB 19 WPM CQ V 1119Z
DX de EA1URA-#: 14051.9 ON6KE CW 24 dB 19 WPM CQ V 1119Z
DX de KP2RUM-#: 14052.0 ON6KE CW 12 dB 18 WPM CQ V 1119Z
DX de R9IR-#: 14037.5 RA4ZA CW 6 dB 20 WPM CQ V 1119Z
DX de RN4WA-#: 14035.0 RO22NY CW 33 dB 26 WPM CQ V 1119Z
DX de K5TR-#: 7038.0 K3Y/9 CW 21 dB 15 WPM CQ V 1119Z
_______________________________________________
Dxspider-support mailing list
Dxspider-support at tobit.co.uk<mailto:Dxspider-support at tobit.co.uk>
https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.tobit.co.uk%2Fmailman%2Flistinfo%2Fdxspider-support&data=04%7C01%7C%7Cb109b63293cf48d15eaa08d9d75af288%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637777607897066192%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=jjwBoP1o55c1zro2Sj%2BhcwPP8MgYNx7zT%2FwYQvqBNro%3D&reserved=0>
_______________________________________________
Dxspider-support mailing list
Dxspider-support at tobit.co.uk<mailto:Dxspider-support at tobit.co.uk>
https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.tobit.co.uk%2Fmailman%2Flistinfo%2Fdxspider-support&data=04%7C01%7C%7Cb109b63293cf48d15eaa08d9d75af288%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637777607897066192%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=jjwBoP1o55c1zro2Sj%2BhcwPP8MgYNx7zT%2FwYQvqBNro%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.tobit.co.uk/pipermail/dxspider-support/attachments/20220114/adc822b6/attachment-0001.htm>
More information about the Dxspider-support
mailing list