[Dxspider-support] Possible failure in RBN filters
Dirk Koopman
djk at tobit.co.uk
Sun Nov 6 14:13:45 GMT 2022
It'll never work...
Contrary to what one might reasonably think, RBN spots don't have
comments - as such - what they *do* have is *information* that
squirrelled away in the comment field, as there isn't anywhere else to
put it. I could offer a purpose built cluster friendly format that an
RBN client could use more easily use such an RBN "spot", and the spot
would not then look alarmingly a *real* DX one. But since CCCluster and
DXSpider between us have about 85% of the nodes and 90% of the users,
have active (well fairly active) (OK alive then) maintainers and rarely
crash, seems to count for diddly squat.
By the time an RBN Spot is presented to the filtering system, it has no
comment field. So no 'info xxx' clause will work. This is not a bug, it
is a feature. However all the normal zone, itu and similar things should
work as this information is populated into spot. Having said that, I
must confess that multiple zones probably would not work. And I also
confess that might still not do what you want and may require a separate
command ("set/rbn_byzone"?). You should also remember that neither RBN
input, nor DXSpider RBN spots are stored and (one of) the reasons is
that the "sh/dx" command, dx filtering only operate on the spot data
fields that are stored on the disk.
From the code:
['freq', 'r', 0, 0, \&decodefreq],
['on', 'r', 0, 0, \&decodefreq],
['call', 'c', 1],
['info', 't', 3],
['by', 'c', 4],
['call_dxcc', 'nc', 5],
['by_dxcc', 'nc', 6],
['origin', 'c', 7, 9],
['call_itu', 'ni', 8],
['call_zone', 'nz', 9],
['by_itu', 'ni', 10],
['by_zone', 'nz', 11],
['call_state', 'ns', 12],
['by_state', 'ns', 13],
['channel', 'c', 14],
['ip', 'c', 15],
It is not possible (at the moment) to filter on quality. I can see a
reason to allow a minimum quality (>= $RBN::minqual) on a per user
basis, but that would have to be a "set/rbn_minqual" (or similar name)
command.
73 Dirk G1TLH
On 06/11/2022 12:05, Joaquin via Dxspider-support wrote:
> Hi Dirk,
>
> Due to a user complaint, I have started researching RBN filters.
>
> The tests have been carried out on a newly installed node where only
> RBN traffic is received.
> It is defined as register ON.
> Its version is 444.
>
>
> *Test 1
>
> EC3BH session:
> set/skim
> rej/rbn 1 info {[Z:14]}
>
> No spot rx
>
>
> EC3BH-1 Session:
> set/skim
> No filters according to sh/filter
>
> No spot rx
>
>
> * Test 2
>
> EC3BH Session:
> cle/rbn all
>
> rbn spots re-enters
>
>
> EC3BH-1 Session:
>
> They still don't enter spots
>
> * Test 3
>
> I close and start session of EC3BH-1
>
> RX all the spots
>
>
> * Test 4
>
> None of these filters work:
>
> rej/rbn 1 info {Z:}
> rej/rbn 1 info {Z:4}
> rej/rbn 1 info {Z:[45]}
> rej/rbn 1 info {Z:[4|5]}
>
> But it does work:
>
> rej/rbn 1 info {Q:}
> rej/rbn 1 info {Q:2}
> rej/rbn 1 info {Q:[29]}
> rej/rbn 1 info {Q:[2|9]}
>
>
> It seems that it only affects the case of "Z".
> Filters generated in <callsign> are inherited to <callsign>-<ssid> but
> do not appear when doing sh/filter or stop applying when using cle/rbn
> all
>
> 73 de Kin EA3CV
>
>
>
> _______________________________________________
> Dxspider-support mailing list
> Dxspider-support at tobit.co.uk
> https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
More information about the Dxspider-support
mailing list