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

[Dan Clemmensen]

Ahh! chirp_common.py defines "ValidationWarining" in addition to
"ValidationError".

We will still need the patch to memdetail.py so that validate_memory gets
the correct value of "duplex", but a driver that wants to warn the user can
do so if necessary.  Now to go check on what the UI does when it sees a
"ValidationWarning" ...

On Mon, Apr 1, 2019 at 9:22 AM Dan Clemmensen <danclemmensen at gmail.com>
wrote:

> A warning instead of an error message would be fine: I'm trying to help
> the user, not limit the user.
>
> My proposed patch affects only the radios supported by the ft4.py  driver.
> We can limit the effect on other radios by asking other driver developers
> to avoid being overly restrictive. In the case of ft4.py, I have a patch
> waiting that will support the other radios in the family. This includes the
> "Asian" versions. The Asian versions are unlocked, so the warning will not
> occur. If a user unlocks a Euro or US version, this in effect makes it an
> Asian version, so the user can simply declare that their radio is Asian and
> carry on. The ft4.py driver cannot currently determine the radio type:
> there does not appear to be a difference in the portion of the memory that
> the driver accesses or in the ID string.
>
> My only concern with my approach is that it is causing you to waste time
> supporting my obsession with fully supporting my own radio. I realize that
> full support of any particular radio is at most a secondary mission for
> CHIRP: you say so right in the FAQ.
>
> Probably the easiest way to support the "warning, not error" approach from
> the driver side would be to add a "level" parameter to the message returned
> from validate_memory. Not sure how to then deal with a "warning" on the UI
> side. If you wish I can research this while you carry on with real CHIRP
> work.
>
> On Mon, Apr 1, 2019 at 7:14 AM Dan Smith via chirp_devel <
> chirp_devel at intrepid.danplanet.com> wrote:
>
>> > 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
>> _______________________________________________
>> chirp_devel mailing list
>> chirp_devel at intrepid.danplanet.com
>> http://intrepid.danplanet.com/mailman/listinfo/chirp_devel
>> Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20190401/11224363/attachment-0001.html