[chirp_devel] [PATCH] [icomciv] Restructuring of IcomCIVRadio radio classes; breakout each radio into its own module in preparetion for simplifying support for upcomming CIV feature #4547

[Martin Cooper]

On Sun, May 2, 2021 at 8:04 AM Dan Smith via chirp_devel <
chirp_devel at intrepid.danplanet.com> wrote:

>
> Correct. I can imagine some complex automated stations needing two (say)
> IC-7000s connected to a single machine for some sort of tracking or
> repeating, but I suspect it is exceedingly rare.
>

I would think so too. And in this situation, the user has already figured
out how to change the CI-V address on one of the radios in order to get
that working. In my experience, people don't change their memory settings
all that often (at least on a scale that necessitates Chirp), so to me it
doesn't seem particularly onerous to tell them they need to change the CI-V
address to the default before running Chirp and change it back afterwards.
On the IC-910H, at least, going into 'set mode' to change the CI-V address
is a matter of a few seconds.

Martin.
KD6YAM



> > As such, while there is technically nothing wrong with simply supporting
> the default ci-v address, the scenario which presents itself in chirp is
> that in cases of communication failures due to a misconfigured ci-v address
> there is no indication to the user as to which address chirp is utilizing
> and as such this has led users to believe it to be an issue with their
> cable and frustration ensues (no surprise there) .
>
> I would think we could handle the UX issue by simply making sure the error
> message includes something about "Be sure your radio is configured for the
> default address of XX". Perhaps also with a link to a wiki doc about how to
> change it in the config if you *really* need it.
>
> > It would also be a fair argument to say that at this point neither of
> these scenarios are a common occurrence and that how or if this features
> needs to be exposed into the UI or at all is of course a matter of
> discussion.  I will add however, that laying the groundwork to support
> configurable ci-v addresses, opens the door for additional per 'radio
> model' configurable attributes to be utilized in the future; such as
> baud-rate, etc..
>
> We can add per-driver configuration options of course. Perhaps you mean
> communicating with two like radios on the same bus at different speeds?
> That seems like a counter-intuitive scenario for a shared-bus arrangement.
>
> > Without actually advocating for anything, here are a  couple potential
> scenarios:
> >
> > 1. Do nothing for the minority of users impacted by this issue and hope
> they figure out to change their CI-V on their own.
> > 2. Improve the error messaging to present the end-user with additional
> diagnostic information regarding their failed connection (may not be a bad
> idea either way).
> > 3. Implement radio model attributes to support ci-v addresses - keeping
> the hard-coded defaults in place while allowing for them to be overridden
> by an optional user defined config file.
> > 4. Exposing configurable attributes mentioned above in the UI in some
> manner that makes sense.
>
> Yeah, #2 for sure, #3 if you want. I think #4 needs a lot more
> justification, personally. I'd rather wait on that until a reasonable
> number of people show up really wanting it to be configurable, and with
> some real-world use case for why.
>
> --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/20210502/4dceb79e/attachment-0001.html