[Dxspider-support] Enabling Q:1 spots

Wed Jul 7 10:20:05 CEST 2021

The MOJO image been happily chugging away running RBN for contest type applications here for some time with no drama at all – thank you Dirk! 

I’ve given a little thought to what I think I would like to do in an ideal – and that’s set $minqual = 1 for spotted callsigns which are in a known good calls file (probably an amalgamation of the contest MASTER.DTA files from supercheckpartial.com and the VHF database from DL8EBW) – and set $minqual = 2 for all other calls….

Don’t know if that suggestion makes processing easier 😉 Just a suggestion for the pot..

73,

Andy, G4PIQ

From: Dxspider-support <dxspider-support-bounces at tobit.co.uk> On Behalf Of Dirk Koopman via Dxspider-support
Sent: 06 July 2021 21:07
To: rin JG1VGX via Dxspider-support <dxspider-support at tobit.co.uk>
Cc: Dirk Koopman <djk at tobit.co.uk>
Subject: Re: [Dxspider-support] Enabling Q:1 spots

On 06/07/2021 04:54, rin JG1VGX via Dxspider-support wrote:

Hi All,

I have played with filters myself and here is a summary.

What I wished to do:

- Allow Q:1 spots system-wide

- Set Q:2-9 as default for a new user

- Users can allow Q:1 as necessary

What I have done:

- set $minqual = 1 as Andy G4PIQ has suggested

(But this cannot be a permanent solution because /local/RBN.pm needs to be updated manually each time /perl/RBN.pm is updated)

- then played with various user filters, eg. acc/rbn, rej/rbn, user_default, node_default

What I have found:

- 'node_default' This looks like a different animal and serves no purpose in this case?

- 'user_default' This does the job, but cannot be overriden by users' own filters. Not useful?

This is news to me. The thing about user_default is that is applies *only until* a user defines a personal filter for a category, it then will override the user_default with their preferences. The only caveat is that there seems to be a bug (in all branches) where "frequently" the user filter does not "take" until the user logs out and then in again.

"Frequently" in this context means: "never - when I am trying to find the fault" or "often enough for users to get confused and annoyed so that they logout, fume, wait a day or two and then login again when it now (magically) works".

- finally got the gist that a single 'acc/ A' and a 'rej/ not A' mean the same, but multiple 'acc' filters works like additive (A OR B) while 'rej' works like multiplicative (A AND B).

- if no /rbn filter is defined, /spots filters apply for both regular and RBN spots. But once any /rbn filter is defined, filters must be defined separately for both regular and RBN spots.

Please do "help filter" or read it on the wiki. It's meant to be "intuitive", but then it would be - to me. It's not quite as you describe it. But in essence it's this:

0. If there is no filter for this "thing" then nothing is filtered. It is just passed on.
1. For every type of thing you can filter (spots, announcements etc) there as 10 filter slots.
2. You can have a different filter in each slot.
3. Each slot is tried in the order 0 -> 9. This is "ladder logic".
4. Empty slots are ignored.
5. For every slot that matches: if it is a REJ filter it immediately rejects that "thing"; if is an ACC filter it will accept that "thing". No further processing on that "thing" occurs for that filter.
6. REJ filters are tried first; if it falls out of the bottom then the ACC filters are tried and if it falls out of the bottom then that "thing" is rejected.

The point of this is that nobody gets negative logic right the first time (nor the second or third time) however good one might be. Hence the REJ filters - they throw away everything you DON'T want. The ACC filters (only) give you what you DO want. You are therefore using positive logic to get what you want (much more of the time). 

As we are all consenting sysops here, you should be made aware of the implications of input filters on your feeds (or node_default file for that "thing"). Any input filter will affect what gets into your node for onward processing. It is dumped at source. BTW a more efficient way of reducing what your users can see is to rcmd/<node partner> acc/spots by_zone 1,2,3 (for instance) and your node will never see any spots from spotters in other zones. Saves a lot some bandwidth. 

So far my purpose was not fulfilled but currently I have at my node:

- Set $minqual = 1

- In case users bothered by busted Q:1 spots, I would suggest them to use

  acc/rbn info {q:[2-9]}, or rej/rbn info {q:1} 

I agree with this. But it is not a perfect answer to the problem. At the moment, I don't know what the processing issues might be for "per user" $minqual settings. 

If there are better solutions, please let me know!

73 rin JG1VGX

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.tobit.co.uk/pipermail/dxspider-support/attachments/20210707/0ec43265/attachment-0001.htm>