[Proposal] RX Frequency and Offset in Channel Mode
[Proposal] RX Frequency and Offset in Channel Mode
Hello,
I sent a pull request for a feature that would display the RX frequency and the offset at the very bottom of the display. It's not perfect and I'm requesting feedback. Here are some samples of what it looks like.
Roger suggested we request feedback on the forum.
Some thoughts on how to improve it include centering the text, separating the frequency and the offset with a space, putting brackets or parentheses around the offset, and adding MHz somewhere to make it more obvious it's a frequency. Please let us know what you think of the feature, and if you have an idea how to improve it, please describe.
The pull request is at https://github.com/rogerclarkmelbourne/ ... 7/pull/139
I sent a pull request for a feature that would display the RX frequency and the offset at the very bottom of the display. It's not perfect and I'm requesting feedback. Here are some samples of what it looks like.
Roger suggested we request feedback on the forum.
Some thoughts on how to improve it include centering the text, separating the frequency and the offset with a space, putting brackets or parentheses around the offset, and adding MHz somewhere to make it more obvious it's a frequency. Please let us know what you think of the feature, and if you have an idea how to improve it, please describe.
The pull request is at https://github.com/rogerclarkmelbourne/ ... 7/pull/139
Re: [Proposal] RX Frequency and Offset in Channel Mode
IMHO
Generally the reason for having channels is to not need to display the frequency, and this makes the display more cluttered with unnecessary information.
I know in your case you have multiple repeaters with the same callsign on different frequencies, but personally if I had the same thing here I'd append something onto the end of the name to indicate something about the repeater, rather than wanting to know its operating frequency.
The frequency can be viewed in the Channel details screen, and that screen could be modified so that the Tx and Rx frequencies could be seen without needing to scroll up and down.
BTW. The CPS actually tries to prevent having multiple channels with the same name, but there is no technical reason for this, and tools like Colin's codeplug converter do not enforce this.
However I suspect if you ever opened one of these channels with duplicate names in the CPS it would probably force you to rename it.
Generally the reason for having channels is to not need to display the frequency, and this makes the display more cluttered with unnecessary information.
I know in your case you have multiple repeaters with the same callsign on different frequencies, but personally if I had the same thing here I'd append something onto the end of the name to indicate something about the repeater, rather than wanting to know its operating frequency.
The frequency can be viewed in the Channel details screen, and that screen could be modified so that the Tx and Rx frequencies could be seen without needing to scroll up and down.
BTW. The CPS actually tries to prevent having multiple channels with the same name, but there is no technical reason for this, and tools like Colin's codeplug converter do not enforce this.
However I suspect if you ever opened one of these channels with duplicate names in the CPS it would probably force you to rename it.
Re: [Proposal] RX Frequency and Offset in Channel Mode
I try not to hand manage anything in the CPS, but instead use scripts to generate the data.
A restriction to have unique channel names seems an arbitrary limitation of the CPS since the radio clearly doesn't enforce it or have a reason to. The data sources I use (BrandMeister repeater database and my local coordinator's database) don't enforce any uniqueness, so to import those into the radio with uniqueness enforced I'd have to come up with some arbitrary way to modify the names, maybe just numbering them, which still isn't going to help me know which repeater is which.
I think it would be ideal, for ham radio use, if the CPS could import channel data directly from BrandMeister and RepeaterBook, probably based on distance from a location. CHIRP is able to do this for some data sources, and it's very convenient. I wouldn't want to have to enforce uniqueness in the CPS while importing from a data source that doesn't enforce it.
I also think it's just generally important for an operator to know what frequencies they're operating on. I've at least once transmitted on the wrong frequency when, if I'd realized what frequency it was, I would not have. As a general rule (I'm sure there are exceptions) I'd say a ham radio should always display the relevant operating parameters.
There are two reasons I see for having unique channel names.
One is for export and import of zone lists (as to CSV). If an exported zone list uses channel numbers, and the channel number changes, on re-import you'll have the wrong channels in every zone.
The other is if the radio supports searching for a channel by name. That would be a really handy feature, but what I think it should do without unique names is sort matches alphabetically and let me scroll through them to choose the right one. Obviously it's helpful if the frequency and offset are shown here too, which is one reason why I implemented a formatting function that could be used anywhere.
One possible compromise I just thought of would be to have an option to show the frequency and the offset instead of the channel number or zone name. That said, I still prefer to use the space at the bottom and have more information on the screen.
Or we could add a 6x6 font, if you just want it more out of the way.
In any case I think there are lots of good reasons to always display the frequency and offset, and I hope you'll reconsider accepting some form of this patch. I'm happy to make whatever improvements are needed.
A restriction to have unique channel names seems an arbitrary limitation of the CPS since the radio clearly doesn't enforce it or have a reason to. The data sources I use (BrandMeister repeater database and my local coordinator's database) don't enforce any uniqueness, so to import those into the radio with uniqueness enforced I'd have to come up with some arbitrary way to modify the names, maybe just numbering them, which still isn't going to help me know which repeater is which.
I think it would be ideal, for ham radio use, if the CPS could import channel data directly from BrandMeister and RepeaterBook, probably based on distance from a location. CHIRP is able to do this for some data sources, and it's very convenient. I wouldn't want to have to enforce uniqueness in the CPS while importing from a data source that doesn't enforce it.
I also think it's just generally important for an operator to know what frequencies they're operating on. I've at least once transmitted on the wrong frequency when, if I'd realized what frequency it was, I would not have. As a general rule (I'm sure there are exceptions) I'd say a ham radio should always display the relevant operating parameters.
There are two reasons I see for having unique channel names.
One is for export and import of zone lists (as to CSV). If an exported zone list uses channel numbers, and the channel number changes, on re-import you'll have the wrong channels in every zone.
The other is if the radio supports searching for a channel by name. That would be a really handy feature, but what I think it should do without unique names is sort matches alphabetically and let me scroll through them to choose the right one. Obviously it's helpful if the frequency and offset are shown here too, which is one reason why I implemented a formatting function that could be used anywhere.
One possible compromise I just thought of would be to have an option to show the frequency and the offset instead of the channel number or zone name. That said, I still prefer to use the space at the bottom and have more information on the screen.
Or we could add a 6x6 font, if you just want it more out of the way.
In any case I think there are lots of good reasons to always display the frequency and offset, and I hope you'll reconsider accepting some form of this patch. I'm happy to make whatever improvements are needed.
-
- Posts: 43
- Joined: Sun Nov 24, 2019 12:10 pm
Re: [Proposal] RX Frequency and Offset in Channel Mode
+1 for the general idea of showing the RX and offset.
Why? When auditing the codeplug, to make sure everything is correct, it currently requires the menu functions to show the Rx and Tx for a channel.
A suggestion, perhaps if the user did a [some function key] + ['?' key] then the Frequency could show above the channel name (where Squelch also shows).
To recap, press a function key and the '?' keypad to show Rx + offset. Since '?' means 'what' in vernacular, then '?' shows the 'what' about the channel.
Perhaps the '?' display function can last until toggled off. Then, just changing channels makes it easy to see any channel frequency.
[73]
Why? When auditing the codeplug, to make sure everything is correct, it currently requires the menu functions to show the Rx and Tx for a channel.
A suggestion, perhaps if the user did a [some function key] + ['?' key] then the Frequency could show above the channel name (where Squelch also shows).
To recap, press a function key and the '?' keypad to show Rx + offset. Since '?' means 'what' in vernacular, then '?' shows the 'what' about the channel.
Perhaps the '?' display function can last until toggled off. Then, just changing channels makes it easy to see any channel frequency.
[73]
Re: [Proposal] RX Frequency and Offset in Channel Mode
Inspired by NA7Q's unofficial firmware I thought I'd post a build of my RX+Offset footer patch here in case anyone wanted to try it and see if they agree it's worth having in the official firmware.
I can see making it optional if there are folks who don't like having it on all the time. To me it's really important to have the operating frequencies displayed always.
Maybe there are other bits of information that should be displayed in the margins? Or maybe it would be useful to have an option to choose what to display?
Anyway, here's a build, based on master from today plus my patches, for folks to try. Let me know what you think.
Much thanks to Daniel F1RMB for his patch to show the frequencies when SK1 is pressed in channel mode, which to some degree obsoletes this. I still prefer to have the frequencies displayed always, but at least that feature made it easy to get to.
I can see making it optional if there are folks who don't like having it on all the time. To me it's really important to have the operating frequencies displayed always.
Maybe there are other bits of information that should be displayed in the margins? Or maybe it would be useful to have an option to choose what to display?
Anyway, here's a build, based on master from today plus my patches, for folks to try. Let me know what you think.
Much thanks to Daniel F1RMB for his patch to show the frequencies when SK1 is pressed in channel mode, which to some degree obsoletes this. I still prefer to have the frequencies displayed always, but at least that feature made it easy to get to.
- Attachments
-
[The extension sgl has been deactivated and can no longer be displayed.]
Re: [Proposal] RX Frequency and Offset in Channel Mode
Thanks, I like it, I was able to notice some errors that I had made in the memories by reading the shift
-
- Posts: 43
- Joined: Sun Nov 24, 2019 12:10 pm
Re: [Proposal] RX Frequency and Offset in Channel Mode
KC7RBW wrote: ↑Sat Nov 30, 2019 12:25 amHello,
I sent a pull request for a feature that would display the RX frequency and the offset at the very bottom of the display. It's not perfect and I'm requesting feedback. Here are some samples of what it looks like.
69840985-5439b200-1212-11ea-8e6c-3b71093bcb5a.png
69890403-91549000-1349-11ea-9446-6fc85f038bc1.png
69890528-53a43700-134a-11ea-9332-8081f2058874.png
Roger suggested we request feedback on the forum.
Some thoughts on how to improve it include centering the text, separating the frequency and the offset with a space, putting brackets or parentheses around the offset, and adding MHz somewhere to make it more obvious it's a frequency. Please let us know what you think of the feature, and if you have an idea how to improve it, please describe.
The pull request is at https://github.com/rogerclarkmelbourne/ ... 7/pull/139
I'd like a 'options' option in the radio to allow this.
My preference is to have this only for analog channels, I just don't see DMR channels being config'd on the fly.
Also, move the frequency to above the channel name, where the squelch normally goes (i.e. the display is exactly as opengd77 with the Rx at the line above the channel name).
Of course, during squelch adjustment, it would not appear.
Also, a little space between the Rx and +- sign would make it look a bit cleaner to me.
I like the idea. There are times when I want to see the Rx and Tx and this accomplishes that!
Re: [Proposal] RX Frequency and Offset in Channel Mode
Thanks for the feedback!
Add CC and VFO scanning and you might even find a repeater without the help of the Internet.
There's enough room to also display the TX CTCSS.
My most basic principle here is that the operator should always know what's going to happen when they press the PTT. With this patch you have everything on the screen you need to know about the RF you're about to splatter on the airwaves (at least for rules compliance) - the mode, the bandwidth, the power, and the frequency.
While traveling I'm more likely to find something in RepeaterBook on my phone and program it by hand than pull out my Windows laptop to use the CPS.footloosejava wrote: ↑Mon Jan 06, 2020 7:04 pmI just don't see DMR channels being config'd on the fly.
Add CC and VFO scanning and you might even find a repeater without the help of the Internet.
Interesting idea. This is also where the contact displays in Digital mode, so it would only work if it only applied to Analog channels, which is not something I'm convinced of. And there's space there at the bottom, unused. I also like that it's out of the way where it is.footloosejava wrote: ↑Mon Jan 06, 2020 7:04 pmAlso, move the frequency to above the channel name, where the squelch normally goes (i.e. the display is exactly as opengd77 with the Rx at the line above the channel name).
Of course, during squelch adjustment, it would not appear.
Current version has this, and is pulled in a bit from the left, which to me looked better and was easier to see than early versions.footloosejava wrote: ↑Mon Jan 06, 2020 7:04 pmAlso, a little space between the Rx and +- sign would make it look a bit cleaner to me.
There's enough room to also display the TX CTCSS.
My most basic principle here is that the operator should always know what's going to happen when they press the PTT. With this patch you have everything on the screen you need to know about the RF you're about to splatter on the airwaves (at least for rules compliance) - the mode, the bandwidth, the power, and the frequency.
Re: [Proposal] RX Frequency and Offset in Channel Mode
KC7RBW, would it be okay if I possibly used your code in my unofficial builds? I may do it at some point. Thanks! I like what you're doing. The open source community is wonderful!