Gentlemen,
last night I tried to apply the limitations set/noft8 and set/noft4 to the VE7CC server (in command space) following the further indications of Roland HB9VQQ (sh/mydx instead of sh/dx).
Comparing the spots displayed on the log4om-V2 cluster with those of other sites (DXFUN for example) I had proof of a prefect congruence and filtering of the FT8 spots.
I will continue to test in the coming days.
Thanks for the tips.
Hiding Cluster Spots FT4/FT8
Re: Hiding Cluster Spots FT4/FT8
73
Max IK0TIX
Max IK0TIX
Re: Hiding Cluster Spots FT4/FT8
In addition to that I also configured key word filtering (reject) in CC User. Works as expected.
73
73
Flex 6600 - Spiderbeam
-
IW3HMH
- Site Admin
- Posts: 2926
- Joined: 21 Jan 2013, 14:20
- Location: Quarto d'Altino - Venezia (ITA)
- Contact:
Re: Hiding Cluster Spots FT4/FT8
Data protocol used by clusters is VERY concise
You have Date, Time, Callsign, frequency, Reporter and notes
From those data, everything else is generated by Log4OM internal logics.
Digital/Phone/CW is based on the bandplan supposed to be in use by the spotted callsign, that is different from country to country but it's assumed to be regulated by IARU zone (even if some countries doesn't belongs to IARU we assume they're using the same bandplan of their IARU area).
Some spots, in CW or Phone range can be identified as FT8/FT4 or other digital modes based on the notes. In that case we made a reclassification of the spot emission type from PHONE to DIGITAL (or from CW to DIGITAL)
Other spots are classified as FTx even if in the range of Phone or CW because they're spotted in the frequency we know FTx is usually working by default.
Those info are contained in the bandplan files.
Bearing, reliability, most wanted ranking and everything else including country and references is generated by our internal engine too, that is doing a lot of computation on every single QSO received.
QSO WORKED BEFORE is updated every 2 minutes as it's "time consuming" and we should work also with the "skimmer clusters" (that i personally think are poisoning the cluster concept).
So, if you have an heavy load on CPU when using a skimmer, it's because Log4OM is doing a LOT of calculations and verifications on each QSO to provide maximum reliability.
Actually we DON'T use clublog exception file for cluster as it's an additional overhead (this is why some callsigns are flagged as PIRATE in the cluster view, they're special callsign not mapped by any country prefix rule).
We can add clublog exception check to callsign parsing, as an option, but once done an user running with 3 concurrent skimmers with full quality checks enabled will melt his CPU because he want to have everything with the maximum level of confidence and detail... so until we will be able to detect a skimmer (not easy) we will probably don't add Clublog callsign verifications.
You have Date, Time, Callsign, frequency, Reporter and notes
From those data, everything else is generated by Log4OM internal logics.
Digital/Phone/CW is based on the bandplan supposed to be in use by the spotted callsign, that is different from country to country but it's assumed to be regulated by IARU zone (even if some countries doesn't belongs to IARU we assume they're using the same bandplan of their IARU area).
Some spots, in CW or Phone range can be identified as FT8/FT4 or other digital modes based on the notes. In that case we made a reclassification of the spot emission type from PHONE to DIGITAL (or from CW to DIGITAL)
Other spots are classified as FTx even if in the range of Phone or CW because they're spotted in the frequency we know FTx is usually working by default.
Those info are contained in the bandplan files.
Bearing, reliability, most wanted ranking and everything else including country and references is generated by our internal engine too, that is doing a lot of computation on every single QSO received.
QSO WORKED BEFORE is updated every 2 minutes as it's "time consuming" and we should work also with the "skimmer clusters" (that i personally think are poisoning the cluster concept).
So, if you have an heavy load on CPU when using a skimmer, it's because Log4OM is doing a LOT of calculations and verifications on each QSO to provide maximum reliability.
Actually we DON'T use clublog exception file for cluster as it's an additional overhead (this is why some callsigns are flagged as PIRATE in the cluster view, they're special callsign not mapped by any country prefix rule).
We can add clublog exception check to callsign parsing, as an option, but once done an user running with 3 concurrent skimmers with full quality checks enabled will melt his CPU because he want to have everything with the maximum level of confidence and detail... so until we will be able to detect a skimmer (not easy) we will probably don't add Clublog callsign verifications.
Daniele Pistollato - IW3HMH
