On Sun, May 2, 2021 at 8:04 AM Dan Smith via chirp_devel < chirp_devel@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:
- Do nothing for the minority of users impacted by this issue and hope
they figure out to change their CI-V on their own.
- 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).
- 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.
- 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@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers