The nature of large volume skimmers is such that there will be the odd false decode once in a way. Blacklisting a skimmer node itself
IMHO is not a solution as one will run out of skimmer to blacklist after a while :)

Finding the reason for these decodes would be the way to go but I suspect it will be a long and arduous hunt with nothing much gained.

I monitor the unfiltered feed from the skimmer here and do find an odd decode with no real reason as to why it happens.
 
73,

Prasad VU2PTT.


On Tue, Dec 17, 2024 at 7:53 AM Pete Smith N4ZR <pete.n4zr@gmail.com> wrote:

Good point, Robert, though I don't know what the people you cite are using (DEEP vs NORMAL).

73, Pete N4ZR
On 12/16/2024 7:04 PM, Robert W5AJ via groups.io wrote:
 
This is not issue with CC - but skimmers that are feeding into the DX spots.
Today's examples include:   WZ7I-# spotting 9E8VB, KM3T-# spotting P7VUM, WC2L-# spotting P63NHS 
None good.   For me and I suspect others, these show up in the ALARM page!
These do tend to come more from certain clusters/skimmers.
I've locked out (best possible) some skimmers from displaying in my CC Cluster with the use of "Keywords" setting and inserting their skimmer callsigns.
This stops both good and false decodes from these folks.
 
FINDINGS:   WSJT, earlier versions do, although rare, false decode when set in "DEEP" mode.   Seems skimmers should use the "NORMAL" setting there to stop false decodes.
Hopefully some of the skimmers monitor this group and will pay attention....
 
73 Robert W5AJ
_._,_._,_
Groups.io Links:

You receive all messages sent to this group.

View/Reply Online (#10606) | Reply to Group | Reply to Sender | Mute This Topic | New Topic
Your Subscription | Contact Group Owner | Unsubscribe [pete.n4zr@gmail.com]

_._,_._,_
_______________________________________________
Skimmertalk mailing list
Skimmertalk@contesting.com
http://lists.contesting.com/mailman/listinfo/skimmertalk