[Proposal] RX Frequency and Offset in Channel Mode

[KC7RBW]

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.

69840985-5439b200-1212-11ea-8e6c-3b71093bcb5a.png (1.36 KiB) Viewed 5316 times

69890403-91549000-1349-11ea-9446-6fc85f038bc1.png (882 Bytes) Viewed 5316 times

69890528-53a43700-134a-11ea-9332-8081f2058874.png (876 Bytes) Viewed 5316 times

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

[VK3KYY]

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.

[KC7RBW]

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.

[footloosejava]

+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]

[KC7RBW]

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.

[IK8JHL]

Thanks, I like it, I was able to notice some errors that I had made in the memories by reading the shift

[KC7RBW]

I was able to notice some errors that I had made in the memories by reading the shift

Exactly! Same here!

[footloosejava]

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.

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!

[KC7RBW]

Thanks for the feedback!

I just don't see DMR channels being config'd on the fly.

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.

Add CC and VFO scanning and you might even find a repeater without the help of the Internet.

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.

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.

Also, a little space between the Rx and +- sign would make it look a bit cleaner to me.

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.

rx-footer.png (3.14 KiB) Viewed 5104 times

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.

[NA7Q]

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!