[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

[Dan Smith]

> In terms of the CIV address change - it really is a question of user experience. First, each model of icom radios are given a unique ci-v address. ICom supports configuration of their CI-V address for the situation where multiple radios are connected to the same cable in order to be able to address each one individually - much like multiple peripherals on an I2C bus. But I suspect you knew that and really doubt that any chirp user is suffering from this limitation... most likely true.

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.

> 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