[chirp_devel] Updates to ICOM IC-Vx Radios
Hey Dan and all,
You have probably noticed that I have pushed a couple changes to support a few older Icom handheld radios and marked them as experimental. The memories and banks have been mapped and the basic functionality (excluding extra settings support) have all been added.
I have marked them experimental with an alert to users for the reason that I do not actually have access to these radios for validation purposes, however I am fairly certain that these drivers are functionally accurate in their initial state. The only action that I cannot confirm is the actual write to the radio, which would require inherent knowledge of the specific icf end frame marker for these models . To complete this would require access to the unit (which I do not have) or a lucky guess (which I have attempted).
When I get a moment I can also send along a couple manufactured image files for these radios to be added to the test base, however real images would be preferable (maybe someone on the list has these radios?). But in the meantime please advise if you have any questions or concerns with these drivers, as they have been requested by many users in the past and may prove useful to some.
Thanks again!
-kosta
You have probably noticed that I have pushed a couple changes to support a few older Icom handheld radios and marked them as experimental. The memories and banks have been mapped and the basic functionality (excluding extra settings support) have all been added.
I have marked them experimental with an alert to users for the reason that I do not actually have access to these radios for validation purposes, however I am fairly certain that these drivers are functionally accurate in their initial state. The only action that I cannot confirm is the actual write to the radio, which would require inherent knowledge of the specific icf end frame marker for these models . To complete this would require access to the unit (which I do not have) or a lucky guess (which I have attempted).
Okay, I'd rather not apply them to the tree until someone has actually tested these drivers with a real radio. They also look very similar to each other -- is there room for re-use here instead of copying the code to each driver?
When I get a moment I can also send along a couple manufactured image files for these radios to be added to the test base, however real images would be preferable (maybe someone on the list has these radios?). But in the meantime please advise if you have any questions or concerns with these drivers, as they have been requested by many users in the past and may prove useful to some.
We definitely need test images from these, and definitely as captured from real radios. I think I can also spot a couple of ways that these will not pass the driver tests. Before I review them, I'll want to see them pass tests.
So, I'll hold off on these and hopefully someone can provide some images with which to test them.
Thanks!
--Dan
On Tue, Sep 28, 2021 at 6:06 PM Dan Smith via chirp_devel < chirp_devel@intrepid.danplanet.com> wrote:
You have probably noticed that I have pushed a couple changes to support
a few older Icom handheld radios and marked them as experimental. The memories and banks have been mapped and the basic functionality (excluding extra settings support) have all been added.
I have marked them experimental with an alert to users for the reason
that I do not actually have access to these radios for validation purposes, however I am fairly certain that these drivers are functionally accurate in their initial state. The only action that I cannot confirm is the actual write to the radio, which would require inherent knowledge of the specific icf end frame marker for these models . To complete this would require access to the unit (which I do not have) or a lucky guess (which I have attempted).
Okay, I'd rather not apply them to the tree until someone has actually tested these drivers with a real radio. They also look very similar to each other -- is there room for re-use here instead of copying the code to each driver?
[kosta] They are similar, however given they each differ in some uniquely inconsistent way from each other I did not bother encapsulating the common components as I felt that the logic was simple enough that doing so would only complicate it unnecessarily. It may be worth revisiting this idea again should Icom decide to make a bunch more IC-V8x models... but given their current cadence I am not overly concerned.
When I get a moment I can also send along a couple manufactured image
files for these radios to be added to the test base, however real images would be preferable (maybe someone on the list has these radios?). But in the meantime please advise if you have any questions or concerns with these drivers, as they have been requested by many users in the past and may prove useful to some.
We definitely need test images from these, and definitely as captured from real radios. I think I can also spot a couple of ways that these will not pass the driver tests. Before I review them, I'll want to see them pass tests.
[kosta] I have tested them against the ICF files, which plainly put is
simply a hex dump representation of the binary image.. Currently ICF files are opened as read only, so in theory if we had a mechanism to serialize from image to ICF we could run the tests?
So, I'll hold off on these and hopefully someone can provide some images with which to test them.
[kosta] I can certainly understand the hesitancy, however given that they
are clearly marked as experimental could we consider releasing these in hopes that some user may attempt to run them and thus is more likely to provide an image? As it stands with no support for these radios, users are not provided any mechanism in which to generate an image to begin with... By releasing the experimental drivers we increase the likelihood of potentially receiving feedback and/or getting an image from some user - and assuming their expectations are tempered, impact to the community should be low. This does not alleviate our desire to test on actual hardware, but considering the scarcity of some of these radios it may be something to think about...
Thanks!
--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
[kosta] I have tested them against the ICF files, which plainly put is simply a hex dump representation of the binary image.. Currently ICF files are opened as read only, so in theory if we had a mechanism to serialize from image to ICF we could run the tests?
Okay, I forget if you can open as ICF and then save as .img. Technically you should be able to, but I can't remember if the UI will let you. Either way, if we're going to get someone to test these (and we should) we should just get images from them at the same time.
[kosta] I can certainly understand the hesitancy, however given that they are clearly marked as experimental could we consider releasing these in hopes that some user may attempt to run them and thus is more likely to provide an image? As it stands with no support for these radios, users are not provided any mechanism in which to generate an image to begin with... By releasing the experimental drivers we increase the likelihood of potentially receiving feedback and/or getting an image from some user - and assuming their expectations are tempered, impact to the community should be low. This does not alleviate our desire to test on actual hardware, but considering the scarcity of some of these radios it may be something to think about...
Yeah, to me experimental means "we think this works but probably isn't perfect." It's a far cry from "this has never talked to a real radio" IMHO.
Users can load the .py as a module to test it, so if there are users asking for these in a bug, you should be able to send that to them to let them try it before we commit.
--Dan
Thanks for all the replies!
On Wed, Sep 29, 2021 at 6:15 PM Dan Smith via chirp_devel < chirp_devel@intrepid.danplanet.com> wrote:
[kosta] I have tested them against the ICF files, which plainly put is
simply a hex dump representation of the binary image.. Currently ICF files are opened as read only, so in theory if we had a mechanism to serialize from image to ICF we could run the tests?
Okay, I forget if you can open as ICF and then save as .img. Technically you should be able to, but I can't remember if the UI will let you. Either way, if we're going to get someone to test these (and we should) we should just get images from them at the same time.
[kosta] if i get some time i will play around with using icf files as part
of our tests, this would go a long way towards giving us more credibility.
[kosta] I can certainly understand the hesitancy, however given that
they are clearly marked as experimental could we consider releasing these in hopes that some user may attempt to run them and thus is more likely to provide an image? As it stands with no support for these radios, users are not provided any mechanism in which to generate an image to begin with... By releasing the experimental drivers we increase the likelihood of potentially receiving feedback and/or getting an image from some user - and assuming their expectations are tempered, impact to the community should be low. This does not alleviate our desire to test on actual hardware, but considering the scarcity of some of these radios it may be something to think about...
Yeah, to me experimental means "we think this works but probably isn't perfect." It's a far cry from "this has never talked to a real radio" IMHO.
Users can load the .py as a module to test it, so if there are users asking for these in a bug, you should be able to send that to them to let them try it before we commit.
[kosta] Fair enough, normally I would agree but this is technically an ICF
driver, where the radio comms are already fairly established; either way rather than debate it I will add the drivers to the ticket so as to have them committed at a later date so as not to lose the effort and lets see what happens.
--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
participants (2)
-
Dan Smith -
Kosta Arvanitis