[chirp_devel] [PATCH] [ft4] allow validation of RO frequencies [#6615]

[Dan Smith]

> The problem is that I added TX Frequency validation to the validate_memory method of my driver. After failing using other approaches, I went back to a March 14 e-mail on the devel list where Jim Unroe pointed me at gmrs_uv1.py. He extends the validate_memory method. I did the same for my new code.  The problem is that that the mem structure passed to validate_memory is not the same as the one later passed to mem_set: Specifically, If the "duplex" field is "off" in the UI column, mem.duplex is set to "" when it reaches validate_memory. If it is "split" in the UI column, it gets changed in some other way that makes it different from  what is passed to set_memory.  I looked for and failed to find the spot where the value is changed back to "off" or "split".

Okay, I'm not sure what you're describing there, but perhaps we should try to figure that out instead of making the change you've got here, or validate that what you have is correct.

> Without this change, My modifed driver rejects an RO channel (i.e., one that has duplex "off") that has a frequency that is invalid for TX, and the UI "duplex" column is forced back to "". With this change, my driver works.

Okay, just having skimmed your driver patch, I'm concerned that you're changing too much underneath a bunch of drivers without accounting for it. I'll try to look closer soon.

After our last exchange, I've been thinking about how much it's worth doing all of this, I'm a little concerned that we're going down a rabbit hole here that might not really come with much payoff. Taking another radio as an example here, the modern Icom HF radios all "support" the 60m band. By default they can only transmit on the actually-allowed frequencies that the FCC has designated, but they can receive the whole band of course. When the FCC up and changed a few of them recently, older radios were stuck, unable to use the new channels because the regulations had been baked in. People that owned those radios performed the MARS/CAP mod (and the MARS people did too of course) so they could transmit on the entire 60m band in order to access the new frequencies. There's no way to tell from the outside that those mods have been done. If the CHIRP driver for these radios were to enforce the rules of an unmodified radio, the users of a modified radio wouldn't be able to do what they want.

Point being, I'm just not sure how useful it is to try to make CHIRP account for the fine-grained differences between TX/RX and TX-only frequencies in a radio. We're really just trying to manipulate the contents of the memory in a generic way for a ton of models, not provide holistic radio experience for one specific one with every possible quirk accounted for.

Would you be satisfied with some sort of visual indication in the UI of "A stock specimen of this model may not be able to transmit on the frequency you just put in" ?

--Dan