I’m going to write an agent that, whenever I receive an email from DX Spider, responds with “Can someone get me off this list? And yes, I used the unsubscribe link but it doesn’t work”. 😆 On Tue, 3 Feb 2026 at 17:35, Rudy Bakalov via Dxspider-support < dxspider-support@dxcluster.org> wrote:
Hi Kin,
You are investing a lot of personal time and effort to produce these reports and provide recommendations. It must be important. But I honestly do not understand the impact of sending or not sending PC92 traffic. Impact in terms of ability to send or receive spots.
To make this concrete- N2WQ-73 is a true DXS node and sends and receives PC92 frames. N2WQ-77 is the cluster node I developed that receives (and immediately dumps), but does not send PC92 frames. The two of the communicate just fine and exchange spots. And of course N2WQ-1 and VE3EID-1, both CCC, don't send PC92, but work just fine.
So what functionality is broken when a node does not send PC92? If spots are flowing in both directions, what is not? I need help understanding the practical implications.
Rudy N2WQ
On Tuesday, February 3, 2026 at 10:35:44 AM EST, Kin via Dxspider-support < dxspider-support@dxcluster.org> wrote:
Hi,
Below is some data that may help identify issues between nodes.
A value of "1" indicates that the node has reported an active connection with its peer. A value of "0" means that there was either no response from the node or that it reported a disconnection. "U" indicates the total number of connections. "D" indicates the total number of disconnections.
Nodes that do not appear here are not necessarily operating correctly; these are simply the accumulated values at the time the data was read.
All of this data comes from the analysis of PC92 frames transmitted on the network. Interconnections between nodes that do not use PC92 will never appear here — for the network, they effectively do not exist.
There are nodes, such as ARC, that never emit PC92 frames. Some CCC nodes emit them, but most do not, and they do not behave in the same way as DXSpider nodes. Additionally, some DXSpider nodes do not use PC92 either because it is disabled or because they are running obsolete versions.
In any case, this data indicates a problem between nodes, either because the link is not being established correctly or because the nodes are not fully compatible.
Please note that the callsigns of the nodes shown in the list are those reported by the peer node. It is quite common to see nodes appearing with a different callsign (with or without SSID, or with a different SSID). This is usually a clear indication of configuration problems on the link. Some nodes shown in the list have not been properly defined, either because they are not defined as nodes at all or because they are defined with an incorrect node type. This will prevent the link from being established.
The most common and correct configuration should include definitions such as: * set/spider * set/ccluster * set/node
If the callsign of a peer node is incorrect, it must be corrected using the commands above and/or by verifying the connection configuration file.
A typical and expected connection file should look like this:
timeout 15 connect telnet <hostname or IP> <port> 'login: ' '<our node callsign>' 'assword:' '<password, if required>'
In some cases, the login field does not contain the node’s actual callsign, but a different one. This is a common source of problems and should be corrected.
If a sysop believes that they do not have an active link with one of the nodes shown in the list, the usual and recommended action is to inform the peer sysop and ask them to remove any pending or repeated connection attempts from their crontab.
I hope this information helps clarify and resolve the issue. Please see the attached file.
Kin EA3CV
_______________________________________________ Dxspider-support mailing list -- dxspider-support@dxcluster.org To unsubscribe send an email to dxspider-support-leave@dxcluster.org _______________________________________________ Dxspider-support mailing list -- dxspider-support@dxcluster.org To unsubscribe send an email to dxspider-support-leave@dxcluster.org