[chirp_devel] Patch for #681: Add support for band plans
Hi,
Please find attached a patch to add band plans. It replaces "Automatic Repeater Offsets".
When you have a band plan selected and you modify a frequency, the band plan code looks up the frequency and sets: - The default mode. - The default repeater offset. - The default tune step. There is also support in the band plan for tones, but it isn't plumbed through yet.
You can select multiple plans because, for example, you might want both an IARU plan and a country plan.
chirpui/bandplans.py is the API for accessing band plans. chirp/bandplan_*.py are the technical details of each band plan. bandplans.py is in the UI directory because it deals with config, which appears to be used exclusively from the chirpui directory.
The format in bandplan_au.py is the format I prefer. The format in bandplan_na.py is carried over from chirp_common.py and should be replaced by the new format once we agree on how it should look.
I've left placeholders for the IARU band plans (eg. http://www.iaru-r2.org/band-plan/). We can add them to the UI once they have been populated.
While testing this I noticed that there are multiple instances of the config class, with different and overlapping lifetimes. This means that sometimes configuration changes are applied and sometimes they are not. That is a separate issue.
Wow, this is a lot of work, thanks for doing it!
You can select multiple plans because, for example, you might want both an IARU plan and a country plan.
So, from reading part of the code, I got the impression that perhaps the plans are/should be hierarchical. Meaning, that the NA plan is a subset of IARU 2. Is that the case? I ask because I'm wondering if it makes more sense to let folks choose IARU 2 or NA (which would inherit from IARU, and perhaps override some bits) instead of this mix-and-match behavior. I don't think it would make much sense to have NA and IARU 1 enabled at the same time, for example, but maybe I'm wrong. Of course, that has me thinking that we should be utilizing inheritance...
The format in bandplan_au.py is the format I prefer. The format in bandplan_na.py is carried over from chirp_common.py and should be replaced by the new format once we agree on how it should look.
It's very close to what I pulled out of thin air earlier, and overall I think I'm fine with it. I do wonder if we should be using objects instead of just primitives, but I'm not sure.
While testing this I noticed that there are multiple instances of the config class, with different and overlapping lifetimes. This means that sometimes configuration changes are applied and sometimes they are not. That is a separate issue.
Hmm? Config is a singleton, and the various proxy objects should just be views into it. I've not seen any such issues, but if you find them, we should definitely get them resolved.
- "bands": {
- (28.000e6, 29.700e6): {
I don't like the specification of these as floats. Can we use ints, perhaps with easy shortcut helpers such as:
(k(28000), k(28700))
and
(m(146), m(148))
?
+def _walk_bandplan(freq, bandplan, defaults):
- # Override defaults with values from this level.
- for name in defaults:
defaults[name] = bandplan.get(name, defaults[name])- # Go more specific if the frequency fits within an available
sublevel.
- for key, vals in bandplan.items():
if key in defaults:passelif isinstance(key, tuple):if key[0] > key[1]:raise Exception("Invalid range %s - %s" % key)if int(freq) >= key[0] and int(freq) < key[1]:_walk_bandplan(freq, vals, defaults)breakelse:raise Exception("Invalid key %s" % key)
This just screams at me for the use of an object structure instead of primitives. Is there a reason you decided against it? (other than me firing off a half-baked concept earlier, of course :P)
<menu action="bandplan" name="bandplan"><menuitem action="north_america"/><menuitem action="australia"/></menu>
This is fine, of course, and we don't have many here right now, but we can automate the generation of the submenu so that adding a new bandplan is a little less involved.
# Migrate old "automatic repeater offset" setting to
Thanks for this!
Otherwise, I think it looks fine. Again, thanks a lot for taking on this non-trivial thing :)
On Wed, Mar 13, 2013 at 11:52 AM, Dan Smith dsmith@danplanet.com wrote:
Wow, this is a lot of work, thanks for doing it!
You can select multiple plans because, for example, you might want both an IARU plan and a country plan.
So, from reading part of the code, I got the impression that perhaps the plans are/should be hierarchical. Meaning, that the NA plan is a subset of IARU 2. Is that the case?
Yes, however a North American Marine band plan and a North American Amateur band plan would both be under an ITU region 2 band plan, and you might want to use both.
I ask because I'm wondering if it makes more sense to let folks choose IARU 2 or NA (which would inherit from IARU, and perhaps override some bits) instead of this mix-and-match behavior. I don't think it would make much sense to have NA and IARU 1 enabled at the same time, for example, but maybe I'm wrong. Of course, that has me thinking that we should be utilizing inheritance...
You're right. I'll try it with objects and see how it looks. I expect that will make it easier to calculate and claim the repeater input blocks too (with opposite offsets).
The format in bandplan_au.py is the format I prefer. The format in bandplan_na.py is carried over from chirp_common.py and should be replaced by the new format once we agree on how it should look.
It's very close to what I pulled out of thin air earlier, and overall I think I'm fine with it. I do wonder if we should be using objects instead of just primitives, but I'm not sure.
While testing this I noticed that there are multiple instances of the config class, with different and overlapping lifetimes. This means that sometimes configuration changes are applied and sometimes they are not. That is a separate issue.
Hmm? Config is a singleton, and the various proxy objects should just be views into it. I've not seen any such issues, but if you find them, we should definitely get them resolved.
I've filed bug #683
- "bands": {
- (28.000e6, 29.700e6): {
I don't like the specification of these as floats. Can we use ints, perhaps with easy shortcut helpers such as:
(k(28000), k(28700))
and
(m(146), m(148))
Sounds good to me.
+def _walk_bandplan(freq, bandplan, defaults):
- # Override defaults with values from this level.
- for name in defaults:
defaults[name] = bandplan.get(name, defaults[name])- # Go more specific if the frequency fits within an available
sublevel.
- for key, vals in bandplan.items():
if key in defaults:passelif isinstance(key, tuple):if key[0] > key[1]:raise Exception("Invalid range %s - %s" % key)if int(freq) >= key[0] and int(freq) < key[1]:_walk_bandplan(freq, vals, defaults)breakelse:raise Exception("Invalid key %s" % key)This just screams at me for the use of an object structure instead of primitives. Is there a reason you decided against it? (other than me firing off a half-baked concept earlier, of course :P)
I'll try what you suggest.
<menu action="bandplan" name="bandplan"><menuitem action="north_america"/><menuitem action="australia"/></menu>This is fine, of course, and we don't have many here right now, but we can automate the generation of the submenu so that adding a new bandplan is a little less involved.
# Migrate old "automatic repeater offset" setting toThanks for this!
Otherwise, I think it looks fine. Again, thanks a lot for taking on this non-trivial thing :)
No worries.
Yes, however a North American Marine band plan and a North American Amateur band plan would both be under an ITU region 2 band plan, and you might want to use both.
Hrm, bummer, okay.
You're right. I'll try it with objects and see how it looks. I expect that will make it easier to calculate and claim the repeater input blocks too (with opposite offsets).
Cool, thanks!
I've filed bug #683
Thanks! I just sent a patch for this, let me know if it resolves it for you. It's actually silly internal logic and not related to config objects. Nice catch :)
Hi,
I've attached a revised patch.
Band plans (chirp/bandplan_*.py) contain some information to help with maintenance (source URL, version) and after that they are basically flat lists of Band instances. Band instances can suggest modes, tuning steps, tones, duplex offsets, etc. You can reuse one band plan in another using the + operator (eg. bandplan_na imports bandplan_iaru_r2)
chirp/bandplan.py defines the Band class and the BandTree class. These are distinct because the same Band may be in multiple BandTrees. A BandTree is just an optimised way of applying properties of wider bands to sub bands within them, as implemented in the search() function.
chirpui/bandplans.py handles all of the band plans on behalf of the user interface. When you add a band plan you just create bandplan_whatever.py and then add it to this file.
chirpui/mainapp.py has been modified to make channel defaults selection a pop up with a single select drop down (populated from chirpui/bandplans.py). To simplify conflict resolution I've flipped from multiple selection to single selection. I figure that if you go from adding amateur channels to adding marine channels you can select a different band plan when you start on the marine channels.
Users won't notice any immediate change except that the default (North America) now has some HF band defaults (eg. AM mode for 14.29MHz)
On Wed, Mar 13, 2013 at 1:05 PM, Dan Smith dsmith@danplanet.com wrote:
Yes, however a North American Marine band plan and a North American Amateur band plan would both be under an ITU region 2 band plan, and you might want to use both.
Hrm, bummer, okay.
You're right. I'll try it with objects and see how it looks. I expect that will make it easier to calculate and claim the repeater input blocks too (with opposite offsets).
Cool, thanks!
I've filed bug #683
Thanks! I just sent a patch for this, let me know if it resolves it for you. It's actually silly internal logic and not related to config objects. Nice catch :)
-- Dan Smith www.danplanet.com KK7DS
chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
Double check your data. For example, the North American bandplan for the 70cm band for repeaters should be 440.000 to 445.000 (+5 Mhz) and 445.025 to 450.000 (-5 Mhz). There are other items in 10m, 6m and others.
-- Charles J. Hargrove - N2NOV NYC ARECS/RACES Citywide Radio Officer/Skywarn Coord.
NYC-ARECS/RACES Net Mon. @ 8:30PM 147.360/107.2 PL http://www.nyc-arecs.org and http://www.nyc-skywarn.org
NYDXA SWL & Scanner Net Wed. @ 9PM 147.360/107.2 PL http://www.n2nov.net
"Information is the oxygen of the modern age. It seeps through the walls topped by barbed wire, it wafts across the electrified borders." - Ronald Reagan
"The more corrupt the state, the more it legislates." - Tacitus
"Molann an obair an fear" - Irish Saying (The work praises the man.)
"No matter how big and powerful government gets, and the many services it provides, it can never take the place of volunteers." - Ronald Reagan
Hi,
Do you have a reference North American band plan? That one is straight from chirp_common.py (hence it has no URL field). I would be happy to populate it from a more authoritative source.
On Wed, Mar 27, 2013 at 1:04 PM, Charles J. Hargrove n2nov@nyc-arecs.orgwrote:
Double check your data. For example, the North American bandplan for the 70cm band for repeaters should be 440.000 to 445.000 (+5 Mhz) and 445.025 to 450.000 (-5 Mhz). There are other items in 10m, 6m and others.
-- Charles J. Hargrove - N2NOV NYC ARECS/RACES Citywide Radio Officer/Skywarn Coord.
NYC-ARECS/RACES Net Mon. @ 8:30PM 147.360/107.2 PL http://www.nyc-arecs.org and http://www.nyc-skywarn.org
NYDXA SWL & Scanner Net Wed. @ 9PM 147.360/107.2 PL http://www.n2nov.net
"Information is the oxygen of the modern age. It seeps through the walls topped by barbed wire, it wafts across the electrified borders." - Ronald Reagan
"The more corrupt the state, the more it legislates." - Tacitus
"Molann an obair an fear" - Irish Saying (The work praises the man.)
"No matter how big and powerful government gets, and the many services it provides, it can never take the place of volunteers." - Ronald Reagan
chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
Hi,
I've added IARU region 3 and added it as a parent for Australian Amateur.
While adding IARU region 3 I noticed a few bugs in the original patch: - a typo in the code that builds the bands tree resulted in misplaced items. - IARU region 2 had CW spanning 24.89-29.15 rather than 24.89-24.915
I've also added a debug function to print the bands tree structure (chirpui/bandplans.py PrintBandPlan())
N2NOV, I've found a US amateur band plan. It supplies channel step and mode, which will be reflected in the defaults once I've incorporated it into bandplan_na.py: http://www.arrl.org/band-plan
On Wed, Mar 27, 2013 at 12:54 PM, Sean Burford sburford@google.com wrote:
Hi,
I've attached a revised patch.
Band plans (chirp/bandplan_*.py) contain some information to help with maintenance (source URL, version) and after that they are basically flat lists of Band instances. Band instances can suggest modes, tuning steps, tones, duplex offsets, etc. You can reuse one band plan in another using the + operator (eg. bandplan_na imports bandplan_iaru_r2)
chirp/bandplan.py defines the Band class and the BandTree class. These are distinct because the same Band may be in multiple BandTrees. A BandTree is just an optimised way of applying properties of wider bands to sub bands within them, as implemented in the search() function.
chirpui/bandplans.py handles all of the band plans on behalf of the user interface. When you add a band plan you just create bandplan_whatever.py and then add it to this file.
chirpui/mainapp.py has been modified to make channel defaults selection a pop up with a single select drop down (populated from chirpui/bandplans.py). To simplify conflict resolution I've flipped from multiple selection to single selection. I figure that if you go from adding amateur channels to adding marine channels you can select a different band plan when you start on the marine channels.
Users won't notice any immediate change except that the default (North America) now has some HF band defaults (eg. AM mode for 14.29MHz)
On Wed, Mar 13, 2013 at 1:05 PM, Dan Smith dsmith@danplanet.com wrote:
Yes, however a North American Marine band plan and a North American Amateur band plan would both be under an ITU region 2 band plan, and you might want to use both.
Hrm, bummer, okay.
You're right. I'll try it with objects and see how it looks. I expect that will make it easier to calculate and claim the repeater input blocks too (with opposite offsets).
Cool, thanks!
I've filed bug #683
Thanks! I just sent a patch for this, let me know if it resolves it for you. It's actually silly internal logic and not related to config objects. Nice catch :)
-- Dan Smith www.danplanet.com KK7DS
chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
-- Sean Burford sburford@google.com
The ARRL suggested bandplan has always been a little quirky because of how it is really used in the real world. Look at this repeater coordinator to get an idea (http://www.metrocor.net/bands/440MHz.htm)
N2NOV, I've found a US amateur band plan. It supplies channel step and mode, which will be reflected in the defaults once I've incorporated it into bandplan_na.py: http://www.arrl.org/band-plan
-- Charles J. Hargrove - N2NOV NYC ARECS/RACES Citywide Radio Officer/Skywarn Coord.
NYC-ARECS/RACES Net Mon. @ 8:30PM 147.360/107.2 PL http://www.nyc-arecs.org and http://www.nyc-skywarn.org
NYDXA SWL & Scanner Net Wed. @ 9PM 147.360/107.2 PL http://www.n2nov.net
"Information is the oxygen of the modern age. It seeps through the walls topped by barbed wire, it wafts across the electrified borders." - Ronald Reagan
"The more corrupt the state, the more it legislates." - Tacitus
"Molann an obair an fear" - Irish Saying (The work praises the man.)
"No matter how big and powerful government gets, and the many services it provides, it can never take the place of volunteers." - Ronald Reagan
Hi,
On Fri, Mar 29, 2013 at 9:09 AM, Dan Smith dsmith@danplanet.com wrote:
I've attached a revised patch.
Thanks! I think it looks better than before, but I still feel like it's a bit heavyweight. If it works, though...
Ok, attached patch is lighter weight (I've changed from a tree structure to a simple list) and should apply at current head.
participants (3)
-
Charles J. Hargrove -
Dan Smith -
Sean Burford