[Dxspider-support] Respotting defects?

[g4piq at btinternet.com]

Hi Dirk,

 

Oddly enough I ran across the same issue as Bjorn a few weeks back (and I was logged into GB7DJK at the time so you may find the logs there…) – I think I was re-spotting someone on 2m several hours after the first spot (but on the same frequency) and it told me it was a dupe. Seemed odd – but I forgot about it.

 

On your new propoasls, I think only allowing a re-spot if someone has moved 25 kHz is far too strict. Realistically this needs to be 1 kHz or less in my view. On CW in a contest, or – more realistically for manual spots - on weak signal VHF, 1 kHz is a long way to be out.

 

73

 

Andy G4PIQ

 

 

 

 

 

From: Dxspider-support <dxspider-support-bounces at tobit.co.uk> On Behalf Of djk via Dxspider-support
Sent: 18 June 2024 19:59
To: Björn Ekelund via Dxspider-support <dxspider-support at tobit.co.uk>
Cc: djk <djk at tobit.co.uk>
Subject: Re: [Dxspider-support] Respotting defects?

 

I am actually working on this area of the code at the moment in an effort to prevent the situation where certain stations send the same spot - at the same time - to as many nodes as possible. 

Some time ago I asked the question as to whether I can remove the originating node from the spot dupe code. I am not aware of anybody giving me a definitive answer so I am going to default to remove the originating node. 

There are some other twiddle pots in the code which I have put in over the years, some of which could (and in a few cases) should be revisited. 

Having said that - even in the current mojo branch code - changing the "spotter" will (in my tests at least) be treated as a new spot. In fact, whilst I was doing this earlier today, I noticed two spots for the same Danish beacon (and time) come in, one after the other, from different spotters and they appeared in my console as one would expect. 

DXSpider does not limit spotting the same callsign by different spotters either at the same time or later. It does, however, stop the same user spotting the same callsign on the same QRG and comment (if any). The only time this is allowed is with some (extra) information in the comment section. 

This is the tuple that is stored in the spot cache:  "X|$call|$by|$qrg|$node|$nd|$text" 

$qrg is "slot" of frequency which has been too large, I will reduce this to (default) 25Khz - but I am open to discussions about this. Change $Spot::qrggranularity.

$nd  is "slot " of time. This may be overkill but is (default) 10 minutes (600 seconds). Change $Spot::timegranularity.

A stored dupe tuple like this is only active for (default) 1 hour (3600 secs) . Change $Spot::dupage.

In my test code currently running on GB7DJK the $node field is blanked out and the $qrg field is normalised to the nearest 25Khz. 

Until this email, I have not had any complaints from sysops about excessively strict deduping. So am at a loss to explain why you have these problems. 

73 Dirk G1TLH

On 18/06/2024 13:09, Björn Ekelund via Dxspider-support wrote:

This morning I was verifying some changes in the spot handling functionality  

in DXLog and doing this I created manual spots on my DXSpider node.  

 

When spotting a callsign again on the same frequency after a few minutes, 

DXSpider told me "Sorry, this is a duplicate." Which is sort of expected.


What was not expected is that DXSpider kept saying this also after over 30 minutes, 

even when spotting using a different callsign. This is unacceptable.

If limiting repeat spots on the same frequency at all, the timer should not be longer 

than RBN which is 10 minutes.

 

What was also not expected is that it did not matter if I changed the frequency 

of the spot. Spotting the callsign on a completely new frequency within the same band 

yielded the same message about being a duplicate. This is clearly a bug. When a 

station is spotted on a new frequency, no re-spotting rules should apply.

 

Björn SM7IUN

 





_______________________________________________
Dxspider-support mailing list
Dxspider-support at tobit.co.uk <mailto:Dxspider-support at tobit.co.uk> 
https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.tobit.co.uk/pipermail/dxspider-support/attachments/20240618/d4cbf3fb/attachment-0002.htm>