Band Plans in PoLo

Ragchew
1

Band plans in PoLo are used currently to automatically switch mode when changing frequency, having a good guess that’ll you’ll be switching to the mode typically used in that part of the band (and you can always change mode manually still).

But band plans vary across the ITU regions, and even country by country. So it would be great to get input from the community to improve this, as you’ll be familiar with how bands are used where you are.

The current band plan details PoLo uses can be found here.

Things to note:

  • Frequencies can overlap, with smallest frequency width wins e.g. small SSTV segment in wider SSB area.
  • Many areas of the band are multi-use and so this will never be perfect.
2

REPOST with mods from: Default Frequency modes for VK - #5 by M1SDH

Thanks for the ref to the default band plans @VK1AO ,

First I’d add the following source for Canada’s 0-30MHz section

“sources”: [
{ “url”: “Band Plans | International Amateur Radio Union (IARU)” },
{ “url”: “Band Plan” },
{ “url”: “Updated ARRL Amateur Radio Frequency Charts Now Available” },
{ “url”: “https://www.rac.ca/operating/bandplans/” },
{ “url”: “https://www.rac.ca/mivahih/2023/06/RAC_Bandplan_0–30_MHz.pdf” }
],

I will just focus on the 80m band here for an example

The current band plan listed, assuming based on AARL is:

“80m”: {
“mhz”: [3500, 3800],
“segments”: [
{ “name”: “CW”, “mhz”: [3500, 3600], “mode”: “CW” },
{ “name”: “Phone”, “mhz”: [3535, 3800], “mode”: “SSB”, “submode”: “LSB”, “regions”: [ 3 ] },
{ “name”: “FT8”, “mhz”: [3568, 3571], “mode”: “FT8”, “regions”: [ 3 ] },
{ “name”: “Data”, “mhz”: [3570, 3600], “mode”: “RTTY” },
{ “name”: “FT8”, “mhz”: [3573, 3576], “mode”: “FT8” },
{ “name”: “Phone”, “mhz”: [3600, 4000], “mode”: “SSB”, “submode”: “LSB” }
]
},

A Canada Specific one might look like the following:

“80m”: {
“mhz”: [3500, 4000],
“segments”: [
{ “name”: “CW”, “mhz”: [3500, 3580], “mode”: "CW },
{ “name”: “Data”, “mhz”: [3580, 3583], “mode”: “Data” },
{ “name”: “CW”, “mhz”: [3583, 3589], “mode”: “CW” },
{ “name”: “Data”, “mhz”: [3589, 3600], “mode”: “Data” },
{ “name”: “Phone”, “mhz”: [3600, 3842], “mode”: “SSB”, “submode”: “LSB”, “regions”: [ 3 ] },
{ “name”: “TV”, “mhz”: [3842, 3845], “mode”: “TV”, “regions”: [ 3 ] },
{ “name”: “Phone”, “mhz”: [3845, 4000], “mode”: “SSB”, “submode”: “LSB”, “regions”: [ 3 ] }
]
},

Is the “regions” parameter the ITU region? (source?) or the CQ Zones (Canada falls into 1, 2 , 3, 4 and 5. Is this how you differentiate what would apply in VK land?

Anyhow, not sure exactly how I can help with further defining the differences in the Canadian band plan. But I am willing to learn if I can be of use and if custom band plans is a a current or desired feature.

I would actually think the ideal approach to all this would be to just federate the band plan definitions. So for example RAC would maintain a machine readable version of the band plan at something like https://rac.ca/bandplan.json and then this file could be reffed in robots.txt .

It may be a big ask to get all national orgs to agree on a common standard, and perhaps Polo would be the reference implementation. Without going to deep in the rabit hole, I am not sure if JSON would be the best candidate, perhaps something a bit more semantic like RDF (RDF - Semantic Web Standards), and of course the general schema should follow Schema.org, which appears to have the BroadcastFrequencySpecification (BroadcastFrequencySpecification - Schema.org Type) which before being licensed I don’t think I knew existed. Gotta love learning new things.

Anyhow, back to band plans.

How can I help?

3

Hey @M1SDH ,

Thanks for dedicating a thread to discuss bandplans.

Based on my previous post, I am interested in better understanding what will be required for bandplan contributions. For instance:

  • What are the required and optional parameters
  • How do we request or contribute changes?
  • Do band plans need to be sequential for frequencies or groups by region and country?
  • Do we want a single file with all the bandplans or a single file per country band plan which gets selected based on operator location or manual selection.

Is there a preferred workflow? eg. Log issue, fork repository, make changes and submit pull req against original issue.

I found the “Contribution Guidelines” for the documentation, but I have not found your developer documentation.

ref: Contribution Guidelines | Ham2K Portable Logger

Once I have a better idea how things work, then I can contribute changes to the band plan.

Dave

4

The bandplan data is separate from PoLo and it’s available here lib-operation-data/src/data/bandPlans.json at main · ham2k/lib-operation-data · GitHub as part of the @ham2k/lib-operation-data npm package.

You can open a pull request on that repository to contribute changes.

You can see some examples on that file, but basically, the modeForFrequency() function looks for any segments that include the target frequency and then picks the narrowest one. Segments can apply only for a specific ITU Region, DXCC Entity or Country Code.

The actual algorithm sorts the segments by prioritizing countries over entities over regions over general segments, and then sorts by width of the segment.

A segment that includes countries: ["au", "za"] will apply to any Australian or South African operator, where as entities: ["VK"] would only work for mainland Australia but not for, say, VK9C.

I plan to add support for a special value "*" for countries and entities that lets us define narrow segments, like the one for FT8, in a way that applies both generally but also inside any other broad segment defined for specific countries.

A broad segment, like the ones for Australia, will override all of the general ones. So if we want Australian callsigns to get FT8 for

The segment