[Dxspider-support] bands.pl

Thu Oct 17 14:49:24 BST 2024

 OK, if you prefer to use band segments, here's the full definition of what is being skimmed and reported by VE3EID; hope it helps:

# For use with CWSL_DIGI v0.88
[decoders]
# The set of decoders. Each line is one decoder of at least "frequency mode"# frequency is in Hz# mode is FT4, FT8, WSPR, Q65-30, JT65 or JS8# frequency, mode                   #   e.g., 14074000 FT8# frequency, mode, sharedmem        #   e.g., 14074000 FT8 2# frequency, mode, sharedmem, frequency calibration#   e.g., 14074000 FT8 2 1.00005738745## WSPR decoders optionally allow a spotter callsign per decoder.#   e.g., 14095600 WSPR 2 1.0 W2AXR-2## If you add additional lines here, please send them to W2AXR,#    alexranaldi at gmail.com for release with future versions!
# 6mdecoder=50323000 FT8decoder=50318000 FT4decoder=50313000 FT8decoder=50310000 FT8decoder=50293000 WSPR
# 10mdecoder=28180000 FT4decoder=28074000 FT8decoder=28091000 FT8decoder=28080000 FT4decoder=28090000 FT8decoder=28124600 WSPRdecoder=28124600 FST4W-120decoder=28078000 JS8
# 12mdecoder=24919000 FT4decoder=24915000 FT8decoder=24910000 FT8decoder=24924600 WSPRdecoder=24924600 FST4W-120decoder=24922000 JS8
# 15mdecoder=21140000 FT4 2decoder=21094600 WSPR 2decoder=21094600 FST4W-120 2decoder=21074000 FT8 2decoder=21091000 FT8 2decoder=21090000 FT8 2decoder=21080000 FT4 2decoder=21078000 JS8 2
# 17mdecoder=18104600 WSPR 2decoder=18104600 FST4W-120 2decoder=18104000 FT4 2decoder=18100000 FT8 2decoder=18095000 FT8 2decoder=18104000 JS8 2
# 20mdecoder=14095600 WSPR 2decoder=14095600 FST4W-120 2decoder=14090000 FT8 2decoder=14080000 FT4 2decoder=14074000 FT8 2decoder=14091000 FT8 2decoder=14078000 JS8 2
# 30mdecoder=10140000 FT4 2decoder=10138700 WSPR 2decoder=10138700 FST4W-120 2decoder=10136000 FT8 2decoder=10131000 FT8 2decoder=10144000 FT8 2decoder=10130000 JS8 2
# 40mdecoder=7074000 FT8 decoder=7047500 FT4decoder=7056000 FT8decoder=7038600 WSPRdecoder=7038600 FST4W-120decoder=7080000 FT8decoder=7090000 FT4decoder=7078000 JS8
# 60m#decoder=5357000 FT8#decoder=5287200 WSPR#decoder=5364700 WSPR
# 80mdecoder=3575000 FT4 decoder=3573000 FT8decoder=3563000 FT8decoder=3568600 WSPRdecoder=3568600 FST4W-120decoder=3578000 JS8
# 160mdecoder=1840000 FT8 2decoder=1840000 FT4 2decoder=1835000 FT4 2decoder=1835000 FT8 2decoder=1836600 WSPR 2decoder=1836800 FST4W-120 2#decoder=1839000 FST4-60#decoder=1839000 FST4-120decoder=1842000 JS8 2
    On Thursday, October 17, 2024 at 08:40:16 AM EDT, Keith Maton via Dxspider-support <dxspider-support at tobit.co.uk> wrote:  

 That document doesn’t seem to be available without joining the group.
I don’t see the relevance here.  set/noft8 etc are not valid dxspider commands although if these changes are made, rej/spot on all/ft8 will be valid.  
FT8 and FT4 are data.  What’s actually wrong with adding their frequencies to the ‘data’ segment in bands.pl?  These modes have been around for years now and the frequencies are more defined than RTTY but yet there are RTTY segments defined in the current bands.pl
I know about SSIDs, I use multiple ones myself and am logged into my own node via a telnet session using one to test the suggested changes. 
I don’t see how in any way whatsoever that things could be harmed by making these changes.  
You asked "So why impose hard rules on spots based on frequency?”.  The answer is because it improves the user experience, it means someone can filter out those modes with a single command which is something they can’t do now.   As I said before, not everyone is using software that can filter on the info text or which is able to do any filtering whatsoever and so it has to be done at source.  If we can offer our users the chance to do it with a single command rather than a whole bunch of complicated frequency filters, why wouldn’t we?  
73 Keith

On 17 Oct 2024, at 12:57, Rudy Bakalov <r_bakalov at yahoo.com> wrote:

We had the same discussion on the Yankee Clipper Contest Club reflector. Hers what I suggested:

   - Pick a DXSpider or CC Cluster cluster. Both filter out busted spots. See page 7 of https://groups.io/g/yccc/files/All-Things-Telnet/N2WQ%20-%20On%20Spots_04-2024.pdf
   - CW contests

   - SET/SKIMMER
   - SET/NORTTY
   - SET/NOFT8
   - SET/NOFT4

   - RTTY contests

   - SET/SKIMMER
   - SET/NOCW
   - SET/NOFT8
   - SET/NOFT4

   - Digi contests

   - SET/SKIMMER
   - SET/NOCW
   - SET/NORTTY

   - SSB contests

   - SET/NOSKIMMER

To make it clear- RBN/SKIMMER spots already arrive with a mode tag. There is no guessing. This is what they look like:
      VA3UXA -> 64 DX de VE3EID-#:  14058.1  KE0YDN          7 dB  18 WPM  CQ            1758Z      VA3UXA -> 64 DX de VE3EID-#:  21090.0  PX0FF          10 dB   6 FT8  CQ HI36 1507  1758Z
See page 13 of the PDF above for how to define a preferred spotter (would be VE3EID-# in the example above). On the same slide, the screenshot on the right shows how to select contest bands and contest modes for configuring what to show on the available Mult & Q dashboard.
You can create so called SSIDs, such N2WQ-10, N2WQ-20, etc. and when you login using them, the settings from one SSID won't be applied to the others. That is, you can have a SSID for CW, RTTY, etc. One word of caution- I don't know how this will impact the ability to see who has spotted you. CC Cluster and DXSpider by default pass spots that match the login call, but I don't know if the logic applies to the different SSIDs. The same applies to N1MM as I don't know if the logger ignores the -nn number.
Rudy N2WQ
Sent using a tiny keyboard.  Please excuse brevity, typos, or inappropriate autocorrect.

On Oct 17, 2024, at 3:31 AM, Keith Maton via Dxspider-support <dxspider-support at tobit.co.uk> wrote:

Because at the moment, users who use the command "rej/spot on all/data” don’t get what they’re expecting.  FTx spots on most bands still get through and not everyone is using downstream software that blocks spots based on info text.  There’s never going to be SSB or CW in the few kHz per band that are used for FT8 and FT4 so it makes sense to add these spot frequencies (plus 3kHz) to the ‘data’ segment in bands.pl.
I agree that it won’t catch everything but it’ll certainly filter out a lot more than it does now.  
The most common question I get asked from my users is “How do I only get SSB/CW spots?”   Most of the time, they’ve already tried the data filter and found it doesn’t work properly.
Currently, I tell them to do this.
rej/spot 0 on all/datarej/spot 1 on 1839/1844 or on 3572/3580 or on 7073/7078 or on 7047/7051rej/spot 2 on 10130/10144 or on 14073/14085 or on 18099/18109rej/spot 3 on 21073/21080 or on 21139/21143rej/spot 4 on 24914/24924 or on 28073/28078 or on 28179/28184rej/spot 5 on 50312/50327 or on 50322/50327rej/spot 6 info FT8 or info FT4 or info RTTY or info PSK
If I can tell them to just do this, it’ll be so much easier for them and so much better all round.  
rej/spot 0 on all/datarej/spot 1 info FT8 or info FT4 or info RTTY or info PSK
73 Keith

On 16 Oct 2024, at 14:15, Rudy Bakalov via Dxspider-support <dxspider-support at tobit.co.uk> wrote:

I have been watching this thread only sporadically and missed its genesis. Apologies if my question was answered earlier.
The vast majority of spots are skimmer generated. They already come tagged with CW, RTTY, FT4, or FT8 and there is no ambiguity what mode they are, regardless of frequency. These mode tags are further used by downstream apps like loggers. During RTTY contests RTTY spots can be all over the bands. In addition, DXpeditions don’t necessarily stick to the official FT watering holes.
So why impose hard rules on spots based on frequency?

Rudy N2WQ
Sent using a tiny keyboard.  Please excuse brevity, typos, or inappropriate autocorrect.

On Oct 16, 2024, at 9:02 AM, g4piq--- via Dxspider-support <dxspider-support at tobit.co.uk> wrote:

Dirks suggested you speak with me since I made some of the previous changes. This looks good. I had thought about making the FT8/4 segments 4 kHz wide rather than 3 kHz, but in reality it seems there are no/very few spots above a 3 kHz audio frequency – so 3 kHz as you have implemented works better and avoid dropping RTTY / SSB spots  if you had rej/ft8 selected – though it’s a real minor corner case.   Just a few suggestions…  I would add 50323-50326 to the 6m FT8 range – it’s a commonly used 2nd slot for inter-continental FT8. Also, you could add FT8 70154-70157 for 4m, 144174-144177 for 2m and 432174-432177 for 70cm. You could add FT8 - 5357 – 5340 for 6m.  73  Andy, G4PIQ             From: Dxspider-support <dxspider-support-bounces at tobit.co.uk> On Behalf Of IZ2LSC via Dxspider-support
Sent: 16 October 2024 09:30
To: The DXSpider Support list <dxspider-support at tobit.co.uk>
Cc: IZ2LSC <iz2lsc.andrea at gmail.com>
Subject: Re: [Dxspider-support] bands.pl  new file herehttps://drive.google.com/file/d/1jBDNTcZgEVidWPycXPXhGdMgirPNW2CK/view?usp=sharing  Andrea
-->    Il giorno mar 15 ott 2024 alle ore 23:29 Keith Maton via Dxspider-support <dxspider-support at tobit.co.uk> ha scritto:
This process about copying the file to /spider/local_data is what I was saying in my earlier email (I said "The supplied bands.pl is in /spider/data.  I know better than to overwrite files there so should this be placed in /spider/local_data?”)  I’ve just spent the last hour trying to make it work with no success.  If I copy bands.pl over to /spider/local_data and edit it there, then load it using load/bands and reload the filters as a user, it’s still using the file in /spider/data  I can see this very quickly because if I do a show/dx filter real 30, I’m getting spots that should be filtered out.  Editing the file in /spider/data, updating using load/bands and reloading the filters, it’s working as expected but it simply doesn’t seem to load the file from /spider/local_data.  Yes, the permissions were correct (sysop:sysop).  Can anyone else test this please?  Andrea, 30m needs changing on your version.  It should be 10136,10139 for FT8, not 10131,10134 (my mistake on my earlier message).  73 Keith        

On 15 Oct 2024, at 19:10, Dirk Koopman via Dxspider-support <dxspider-support at tobit.co.uk> wrote:  (Andrea) Please don't do that. When an update is installed it will reset your /spider/data/bands.pl and you will lose all your changes. 

The correct thing to do is to copy /spider/data/band.pl to /spider/local_data and modify it there. A 'load/bands' will pick your modified version as the modification date is newer than the one in /spider/data. If there is an update then the one in /spider/data will be used but - importantly - your version in /spider/local_data will not change. So you *could* 'touch /spider/local_data/bands.pl' to get your version back again.  

The (system) bands.pl changes very rarely, in fact it was changed this year for the first time since 2021. I am open to suggestions for changes, particularly for new mode band sections (assuming that they are stable). Please coordinate with Andy G4PIQ as he knows more about band plans than I do. If your changes are more general then I would be happy to incorporate them. 

73 Dirk

On 15/10/2024 13:41, IZ2LSC via Dxspider-support wrote:
you can rename the original file as bands.old and copy the modified one in the /spider/data.   Then you have to run the command load/bands  No reboot is needed  Andrea
-->    Il giorno mar 15 ott 2024 alle ore 11:18 Keith Maton via Dxspider-support <dxspider-support at tobit.co.uk> ha scritto:
Understood Andrea,   I didn’t look beyond the new entries and hadn’t spotted you’d added them to the data segments.  The supplied bands.pl is in /spider/data.  I know better than to overwrite files there so should this be placed in /spider/local_data?   Does spider need to be restarted in order to use the replacement file?  Dirk, are you happy to take a look over this and consider implementing it in a future release if you’re happy with it?  73 Keith

On 15 Oct 2024, at 06:59, IZ2LSC <iz2lsc.andrea at gmail.com> wrote:  Hi Keith,  FT* frequencies were added as data mode and as well as specific mode using ft8/ft4 name to have more granularity if you want to block only ft8/ft4.And yes, you already have the specific filter for RTTY.  If you look at the first example in my previous email you can see that FT* frequencies are included in the data mode.    Andrea
-->    Il giorno lun 14 ott 2024 alle ore 23:11 Keith Maton via Dxspider-support <dxspider-support at tobit.co.uk> ha scritto:
Hi Andrea,   Thanks, but shouldn’t these be included as data, rather than given new names?  I mean, by definition, FT8 and FT4 are data modes.  I don’t think they need to be differentiated, we don’t have separate filters for RTTY and PSK, it’s all just data.  73 Keith

On 14 Oct 2024, at 21:15, IZ2LSC <iz2lsc.andrea at gmail.com> wrote:  Hi, I modified the bands.pl file.You can download it from here: https://drive.google.com/file/d/1mfwKtz7WxhWMK16KLjp9GzAsLAiQ5tEx/view?usp=sharing  Below some filter examples with the detailed freq range.  73Andreaiz2lsc    rej/spot on all/data  "filter1":{
      "reject":{
         "asc":"(($r->[0]>=1838 && $r->[0]<=1843) || ($r->[0]>=3570 && $r->[0]<=3619) || ($r->[0]>=5366 && $r->[0]<=5467) || ($r->[0]>=7040 && $r->[0]<=7100) || ($r->[0]>=10141 && $r->[0]<=10149) || ($r->[0]>=10131 && $r->[0]<=10134) || ($r->[0]>=10140 && $r->[0]<=10143) || ($r->[0]>=14070 && $r->[0]<=14098) || ($r->[0]>=14101 && $r->[0]<=14111) || ($r->[0]>=18100 && $r->[0]<=18108) || ($r->[0]>=21070 && $r->[0]<=21119) || ($r->[0]>=21140 && $r->[0]<=21143) || ($r->[0]>=24920 && $r->[0]<=24929) || ($r->[0]>=24915 && $r->[0]<=24918) || ($r->[0]>=28050 && $r->[0]<=28149) || ($r->[0]>=29200 && $r->[0]<=29299) || ($r->[0]>=28180 && $r->[0]<=28183) || ($r->[0]>=50300 && $r->[0]<=50500) || ($r->[0]>=5670000 && $r->[0]<=5700000))",
         "code":null,
         "user":"on all/data"  rej/spot on all/ft8  "filter1":{
      "reject":{
         "asc":"(($r->[0]>=1840 && $r->[0]<=1843) || ($r->[0]>=3573 && $r->[0]<=3576) || ($r->[0]>=7074 && $r->[0]<=7077) || ($r->[0]>=10131 && $r->[0]<=10134) || ($r->[0]>=14074 && $r->[0]<=14077) || ($r->[0]>=18100 && $r->[0]<=18103) || ($r->[0]>=21074 && $r->[0]<=21077) || ($r->[0]>=24915 && $r->[0]<=24918) || ($r->[0]>=28074 && $r->[0]<=28077) || ($r->[0]>=50313 && $r->[0]<=50316))",
         "code":null,
         "user":"on all/ft8"
      }  rej/spot on all/ft4  "filter1":{
      "reject":{
         "asc":"(($r->[0]>=3575 && $r->[0]<=3578) || ($r->[0]>=7047 && $r->[0]<=7051) || ($r->[0]>=10140 && $r->[0]<=10143) || ($r->[0]>=14080 && $r->[0]<=14083) || ($r->[0]>=18104 && $r->[0]<=18107) || ($r->[0]>=21140 && $r->[0]<=21143) || ($r->[0]>=24919 && $r->[0]<=24922) || ($r->[0]>=28180 && $r->[0]<=28183) || ($r->[0]>=50318 && $r->[0]<=50321))",
         "code":null,
         "user":"on all/ft4"
      }
   },  rej/spot on 20m/ft8  "filter1":{
      "reject":{
         "asc":"(($r->[0]>=14074 && $r->[0]<=14077))",
         "code":null,
         "user":"on 20m/ft8"
      }    rej/spot on all/ft8 or on all/ft4  "filter1":{
      "reject":{
         "asc":"(($r->[0]>=1840 && $r->[0]<=1843) || ($r->[0]>=3573 && $r->[0]<=3576) || ($r->[0]>=7074 && $r->[0]<=7077) || ($r->[0]>=10131 && $r->[0]<=10134) || ($r->[0]>=14074 && $r->[0]<=14077) || ($r->[0]>=18100 && $r->[0]<=18103) || ($r->[0]>=21074 && $r->[0]<=21077) || ($r->[0]>=24915 && $r->[0]<=24918) || ($r->[0]>=28074 && $r->[0]<=28077) || ($r->[0]>=50313 && $r->[0]<=50316)) || (($r->[0]>=3575 && $r->[0]<=3578) || ($r->[0]>=7047 && $r->[0]<=7051) || ($r->[0]>=10140 && $r->[0]<=10143) || ($r->[0]>=14080 && $r->[0]<=14083) || ($r->[0]>=18104 && $r->[0]<=18107) || ($r->[0]>=21140 && $r->[0]<=21143) || ($r->[0]>=24919 && $r->[0]<=24922) || ($r->[0]>=28180 && $r->[0]<=28183) || ($r->[0]>=50318 && $r->[0]<=50321))",
         "code":null,
         "user":"on all/ft8 or on all/ft4"
      }
-->    Il giorno dom 13 ott 2024 alle ore 11:30 Keith Maton via Dxspider-support <dxspider-support at tobit.co.uk> ha scritto:
That’s what I’ve done, the frequency pairs I listed are the base FT8 and FT4 frequencies for each band, plus 3kHz.  FT8 is often spotted as the base frequency plus the offset people are transmitting on so yes, it could be up to 3kHz above the base.   At the moment, if someone sets a filter rej/spot on all/data, it doesn’t block FT8 or FT4 on all bands.  The data filter should block alldata, including FT4/8 and adding these pairs to bands.pl will fix that.  73 Keith          

On 13 Oct 2024, at 10:10, Kin EA3CV via Dxspider-support <dxspider-support at tobit.co.uk> wrote:  I would propose at least a 3/4 kHz range to ensure that the spot frequency is always in the defined range.It would be interesting if those who usually use the various digital modes prepared their ranges.  Kin EA3CV    De: IZ2LSC <iz2lsc.andrea at gmail.com>
Enviado: domingo, octubre 13, 2024 10:33:24 a. m.
Para: The DXSpider Support list <dxspider-support at tobit.co.uk>
CC: Kin <ea3cv at cronux.net>
Asunto: Re: [Dxspider-support] bands.pl  Hi, this change is quite easy to implement in bands.plI'm not so expert on FT8. Do we really want to block the whole range?I mean, i.e, for ft8 on 20m is it better to block only 14074 or from 14074 to 14077 ?  Andrea 
-->    Il giorno sab 12 ott 2024 alle ore 19:15 Kin via Dxspider-support <dxspider-support at tobit.co.uk> ha scritto:
Hello, Good idea, Keith.I'm busy with other things at the moment, but I'll make a note of it in case no one else is up for it. 73 de Kin EA3CV  De: Dxspider-support <dxspider-support-bounces at tobit.co.uk> En nombre de Keith Maton via Dxspider-support
Enviado el: sábado, 12 de octubre de 2024 16:01
Para: The DXSpider Support list <dxspider-support at tobit.co.uk>
CC: Keith Maton <g6nhu at me.com>
Asunto: Re: [Dxspider-support] bands.pl I’ve been helping a number of my users to filter out FT8 spots and I’ve been setting up frequency segments for them because setting rej/spot filters for data doesn’t seem to work very well with FT8 spots getting through. Looking at bands.pl, I think it’s clear why, a lot of bands don’t have the FT8 frequency specified in the data entry. For example, the main FT8 frequency on 30m is 10,131.000 kHz but bands.pl has 10141, 10149.  I’m not sure if these are spot frequencies or a range from 10141-10149. 17m lists 18101,18108 but the main FT8 frequency for that band is 18100. 12m lists 24920,24929 but the main FT8 frequency is 24915 I know bands.pl was updated earlier this year but I think we need some more entries in for FT8/FT4, etc.  If the entries are ranges then it should be straightforward to add additional ones for FT8 and FT4. My suggestions for the primary HF bands. FT8:1840,18433573,35767074,707710131,1013414074,1407718100,1810324915,2491828074,28077 FT4:3575,35787047,705110140,1014314080,1408318104,1810721140,2114324919,2492228180,28183 I appreciate that there’s slight overlap on some of these and that it won’t stop spots for DXpeditions that operate outside the normal frequencies but if we can get all these added to bands.pl as part of the data segments, it’ll really help us. 73 Keith  

On 19 Apr 2024, at 12:11, Kin EA3CV via Dxspider-support <dxspider-support at tobit.co.uk> wrote: Hi, It is true that there are users who limit themselves to the exclusive use of the BandMap, but others apply filters from their log/test sw, and these are generally those of the cluster used. We must not forget those who still use the command interface. For a long time banding has evolved very slowly, but lately we have more bands. I would opt for a mixed model, that is, using the IARU band plan and rigorously adapting it to the de facto use of some that have carved out a niche for themselves in the spectrum. To answer, the same. Now I have a first version of the plan for Region I, and it would be interesting if other users could contribute II and III Region. It is recast into a single one and we designate the typical segments. Regards,  Kin EA3CV  Enviado desde Outlook para Android_______________________________________________
Dxspider-support mailing list
Dxspider-support at tobit.co.uk
https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
 _______________________________________________
Dxspider-support mailing list
Dxspider-support at tobit.co.uk
https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
  _______________________________________________
Dxspider-support mailing list
Dxspider-support at tobit.co.uk
https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
  _______________________________________________
Dxspider-support mailing list
Dxspider-support at tobit.co.uk
https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support

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

  _______________________________________________
Dxspider-support mailing list
Dxspider-support at tobit.co.uk
https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
  _______________________________________________Dxspider-support mailing listDxspider-support at tobit.co.ukhttps://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
  _______________________________________________
Dxspider-support mailing list
Dxspider-support at tobit.co.uk
https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
  _______________________________________________
Dxspider-support mailing list
Dxspider-support at tobit.co.uk
https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
_______________________________________________
Dxspider-support mailing list
Dxspider-support at tobit.co.uk
https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support

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

_______________________________________________
Dxspider-support mailing list
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/20241017/1139706f/attachment-0001.htm>