[chirp_devel] Adding Settings support to the VX8-R
Hi,
I'm trying to add support for Settings for the original VX-8R. I just recently have been switching over to chirp for all of my radios and was surprised to find that the Settings tab was empty after downloading from my VX-8R. After a few modifications to the vx8.py driver, I have settings coming up properly for my radio but have doubtless broken support for the VX-8DR.
The VX8-DR has expanded APRS features such as SmartBeaconing, more Message Macros, more DigiPaths, etc. These affect the memory layout some. To fix it (temporarily), I corrected the memory layout to align with the VX-8R and commented out the calls that referenced the now missing memory elements.
I'd like to contribute the changes back but I'm not sure how to handle support for both the VX-8R and VX-8DR (and VX-8GER). With differences in memory layout, should the VX-8R have a separate driver or can the memory layout differences be somehow accommodated within the same driver?
73's,
Keith KF7DRV
Hi,
I think I figured out the "chirp" method for dealing with differing memory layouts between radios withing the same driver.
I split the aprs struct into a shorter aprs struct, followed by a aprs_msg_macro[%d] struct, and an aprs2 struct. I prepended both the aprs_msg_macro[%d] struct and the aprs2 struct with "#seekto 0x%04X;" I then computed the beginning address of the aprs_msg_macro[%d] struct and added the starting address and number of message macros to the _mem_params for both the VX8Radio and VX8DRadio classes. I also computed the beginning address of the aprs2 struct and added those to the _mem_params for both radio classes.
I've tested these changes with my VX-8R and the test image Yaesu_VX-8_R.img. This leads to a quandry.
Reading back through the archived messages from around 2013, I see that when the Settings support was added for the VX-8DR, the conclusion at the time was that Settings would not be supported for the stock VX-8R due to lack of a radio to test with. It was felt that most everyone would have sent their VX-8R's in for the Yaesu upgrade that added the enhanced memory and APRS support of the VX-8DR. Unfortunately, I was asleep at the switch and was unaware of that opportunity until it was no longer offered. I would have jumped on that given that APRS was one of my major drivers for buying the VX-8R in the first place. Bummer..would have definitely liked to have smart beaconing. Anyway, inspecting the Yaesu_VX-8_R.img memory, I see that it is an AH029 that appears to have come from Dan who I remember from the archives had gotten his upgraded through the Yaesu program. So, apparently, the upgrade didn't result in a change to the _model for the radio.
Does anybody know of a way to disambiguate between a stock VX-8R and an upgraded one? I need to be able to support upgraded VX-8R's as VX-8DR's.
Can anyone supply an image for a true VX-8DR so that I can test that my code changes for the VX8DRadio class?
Thanks in advance!
73's,
Keith KF7DRV
On Fri, Jun 2, 2017 at 6:16 PM, Keith Williamson hkwilliamson@gmail.com wrote:
Hi,
I'm trying to add support for Settings for the original VX-8R. I just recently have been switching over to chirp for all of my radios and was surprised to find that the Settings tab was empty after downloading from my VX-8R. After a few modifications to the vx8.py driver, I have settings coming up properly for my radio but have doubtless broken support for the VX-8DR.
The VX8-DR has expanded APRS features such as SmartBeaconing, more Message Macros, more DigiPaths, etc. These affect the memory layout some. To fix it (temporarily), I corrected the memory layout to align with the VX-8R and commented out the calls that referenced the now missing memory elements.
I'd like to contribute the changes back but I'm not sure how to handle support for both the VX-8R and VX-8DR (and VX-8GER). With differences in memory layout, should the VX-8R have a separate driver or can the memory layout differences be somehow accommodated within the same driver?
73's,
Keith KF7DRV
My circa mid-2010, VX-8DR, bought as a VX-8DR, (not upgraded) sends AH29D ( 0x41 0x48 0x32 0x39 0x44 0x00 0x00 0x01 0x01 0x00). It's been many years since I've looked at the VX-8 memory map. Given the way Yaesu seems to do things, I'm surprised that an upgraded VX-8 would still send the same model number, since cloning a non-D VX-8 to an upgraded VX-8 would result in a different memory map.
IIRC, not just the location but the size of the APRS structs changed in the memory map as the number of slots changed from something like 40 to 50. I don't know if something else got compressed/removed to make room for those addition beacon/message slots.
I can send you an image from my radio. I don't have a factory clean image that is directly readable by chirp. Though I believe I did save the factory image with both FTBVX8 and RT Systems, which I could send you if you have either of those packages from the pre-Chirp days. (At one point I figured out how to decode an FTBVX8 file on disk back to a VX8 binary that chirp would read. I don't know if I have any working code around that might still do that.)
Hope this helps, --Rob
On 6/4/2017 4:59 PM, Keith Williamson via chirp_devel wrote:
Hi,
I think I figured out the "chirp" method for dealing with differing memory layouts between radios withing the same driver.
I split the aprs struct into a shorter aprs struct, followed by a aprs_msg_macro[%d] struct, and an aprs2 struct. I prepended both the aprs_msg_macro[%d] struct and the aprs2 struct with "#seekto 0x%04X;" I then computed the beginning address of the aprs_msg_macro[%d] struct and added the starting address and number of message macros to the _mem_params for both the VX8Radio and VX8DRadio classes. I also computed the beginning address of the aprs2 struct and added those to the _mem_params for both radio classes.
I've tested these changes with my VX-8R and the test image Yaesu_VX-8_R.img. This leads to a quandry.
Reading back through the archived messages from around 2013, I see that when the Settings support was added for the VX-8DR, the conclusion at the time was that Settings would not be supported for the stock VX-8R due to lack of a radio to test with. It was felt that most everyone would have sent their VX-8R's in for the Yaesu upgrade that added the enhanced memory and APRS support of the VX-8DR. Unfortunately, I was asleep at the switch and was unaware of that opportunity until it was no longer offered. I would have jumped on that given that APRS was one of my major drivers for buying the VX-8R in the first place. Bummer..would have definitely liked to have smart beaconing. Anyway, inspecting the Yaesu_VX-8_R.img memory, I see that it is an AH029 that appears to have come from Dan who I remember from the archives had gotten his upgraded through the Yaesu program. So, apparently, the upgrade didn't result in a change to the _model for the radio.
Does anybody know of a way to disambiguate between a stock VX-8R and an upgraded one? I need to be able to support upgraded VX-8R's as VX-8DR's.
Can anyone supply an image for a true VX-8DR so that I can test that my code changes for the VX8DRadio class?
Thanks in advance!
73's,
Keith KF7DRV
On Fri, Jun 2, 2017 at 6:16 PM, Keith Williamson <hkwilliamson@gmail.com mailto:hkwilliamson@gmail.com> wrote:
Hi, I'm trying to add support for Settings for the original VX-8R. I just recently have been switching over to chirp for all of my radios and was surprised to find that the Settings tab was empty after downloading from my VX-8R. After a few modifications to the vx8.py driver, I have settings coming up properly for my radio but have doubtless broken support for the VX-8DR. The VX8-DR has expanded APRS features such as SmartBeaconing, more Message Macros, more DigiPaths, etc. These affect the memory layout some. To fix it (temporarily), I corrected the memory layout to align with the VX-8R and commented out the calls that referenced the now missing memory elements. I'd like to contribute the changes back but I'm not sure how to handle support for both the VX-8R and VX-8DR (and VX-8GER). With differences in memory layout, should the VX-8R have a separate driver or can the memory layout differences be somehow accommodated within the same driver? 73's, Keith KF7DRV
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
FWIW, my VX-8GR identifies as AH041. I did a factory reset and took an image of it. It's not a DR, but I'd be happy to send it to you.
ray AC1BC
On Sun, Jun 4, 2017 at 4:59 PM, Keith Williamson via chirp_devel < chirp_devel@intrepid.danplanet.com> wrote:
Hi,
I think I figured out the "chirp" method for dealing with differing memory layouts between radios withing the same driver.
I split the aprs struct into a shorter aprs struct, followed by a aprs_msg_macro[%d] struct, and an aprs2 struct. I prepended both the aprs_msg_macro[%d] struct and the aprs2 struct with "#seekto 0x%04X;" I then computed the beginning address of the aprs_msg_macro[%d] struct and added the starting address and number of message macros to the _mem_params for both the VX8Radio and VX8DRadio classes. I also computed the beginning address of the aprs2 struct and added those to the _mem_params for both radio classes.
I've tested these changes with my VX-8R and the test image Yaesu_VX-8_R.img. This leads to a quandry.
Reading back through the archived messages from around 2013, I see that when the Settings support was added for the VX-8DR, the conclusion at the time was that Settings would not be supported for the stock VX-8R due to lack of a radio to test with. It was felt that most everyone would have sent their VX-8R's in for the Yaesu upgrade that added the enhanced memory and APRS support of the VX-8DR. Unfortunately, I was asleep at the switch and was unaware of that opportunity until it was no longer offered. I would have jumped on that given that APRS was one of my major drivers for buying the VX-8R in the first place. Bummer..would have definitely liked to have smart beaconing. Anyway, inspecting the Yaesu_VX-8_R.img memory, I see that it is an AH029 that appears to have come from Dan who I remember from the archives had gotten his upgraded through the Yaesu program. So, apparently, the upgrade didn't result in a change to the _model for the radio.
Does anybody know of a way to disambiguate between a stock VX-8R and an upgraded one? I need to be able to support upgraded VX-8R's as VX-8DR's.
Can anyone supply an image for a true VX-8DR so that I can test that my code changes for the VX8DRadio class?
Thanks in advance!
73's,
Keith KF7DRV
On Fri, Jun 2, 2017 at 6:16 PM, Keith Williamson hkwilliamson@gmail.com wrote:
Hi,
I'm trying to add support for Settings for the original VX-8R. I just recently have been switching over to chirp for all of my radios and was surprised to find that the Settings tab was empty after downloading from my VX-8R. After a few modifications to the vx8.py driver, I have settings coming up properly for my radio but have doubtless broken support for the VX-8DR.
The VX8-DR has expanded APRS features such as SmartBeaconing, more Message Macros, more DigiPaths, etc. These affect the memory layout some. To fix it (temporarily), I corrected the memory layout to align with the VX-8R and commented out the calls that referenced the now missing memory elements.
I'd like to contribute the changes back but I'm not sure how to handle support for both the VX-8R and VX-8DR (and VX-8GER). With differences in memory layout, should the VX-8R have a separate driver or can the memory layout differences be somehow accommodated within the same driver?
73's,
Keith KF7DRV
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
Hi Ray,
Yes, I would love to have a VX-8GR image also!
Thanks,
Keith
On Sun, Jun 4, 2017 at 3:01 PM, ray c rayslinky@gmail.com wrote:
FWIW, my VX-8GR identifies as AH041. I did a factory reset and took an image of it. It's not a DR, but I'd be happy to send it to you.
ray AC1BC
On Sun, Jun 4, 2017 at 4:59 PM, Keith Williamson via chirp_devel < chirp_devel@intrepid.danplanet.com> wrote:
Hi,
I think I figured out the "chirp" method for dealing with differing memory layouts between radios withing the same driver.
I split the aprs struct into a shorter aprs struct, followed by a aprs_msg_macro[%d] struct, and an aprs2 struct. I prepended both the aprs_msg_macro[%d] struct and the aprs2 struct with "#seekto 0x%04X;" I then computed the beginning address of the aprs_msg_macro[%d] struct and added the starting address and number of message macros to the _mem_params for both the VX8Radio and VX8DRadio classes. I also computed the beginning address of the aprs2 struct and added those to the _mem_params for both radio classes.
I've tested these changes with my VX-8R and the test image Yaesu_VX-8_R.img. This leads to a quandry.
Reading back through the archived messages from around 2013, I see that when the Settings support was added for the VX-8DR, the conclusion at the time was that Settings would not be supported for the stock VX-8R due to lack of a radio to test with. It was felt that most everyone would have sent their VX-8R's in for the Yaesu upgrade that added the enhanced memory and APRS support of the VX-8DR. Unfortunately, I was asleep at the switch and was unaware of that opportunity until it was no longer offered. I would have jumped on that given that APRS was one of my major drivers for buying the VX-8R in the first place. Bummer..would have definitely liked to have smart beaconing. Anyway, inspecting the Yaesu_VX-8_R.img memory, I see that it is an AH029 that appears to have come from Dan who I remember from the archives had gotten his upgraded through the Yaesu program. So, apparently, the upgrade didn't result in a change to the _model for the radio.
Does anybody know of a way to disambiguate between a stock VX-8R and an upgraded one? I need to be able to support upgraded VX-8R's as VX-8DR's.
Can anyone supply an image for a true VX-8DR so that I can test that my code changes for the VX8DRadio class?
Thanks in advance!
73's,
Keith KF7DRV
On Fri, Jun 2, 2017 at 6:16 PM, Keith Williamson hkwilliamson@gmail.com wrote:
Hi,
I'm trying to add support for Settings for the original VX-8R. I just recently have been switching over to chirp for all of my radios and was surprised to find that the Settings tab was empty after downloading from my VX-8R. After a few modifications to the vx8.py driver, I have settings coming up properly for my radio but have doubtless broken support for the VX-8DR.
The VX8-DR has expanded APRS features such as SmartBeaconing, more Message Macros, more DigiPaths, etc. These affect the memory layout some. To fix it (temporarily), I corrected the memory layout to align with the VX-8R and commented out the calls that referenced the now missing memory elements.
I'd like to contribute the changes back but I'm not sure how to handle support for both the VX-8R and VX-8DR (and VX-8GER). With differences in memory layout, should the VX-8R have a separate driver or can the memory layout differences be somehow accommodated within the same driver?
73's,
Keith KF7DRV
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
Hi,
Attached is a patch for adding settings to the VX-8. Also attached are image files for each model. Thanks to Ray and Rob for supplying images for the VX-8GR and VX-8DR. All tests against each of the three models are successful and now include Settings.
Note that there are now three distinct VX-8 models in the pull-down menu for Yaesu. I couldn't get things to work simply using VARIANT but perhaps I'm missing something (Chirp noob). Perhaps also there was already an issue with the VARIANT mechanism in the current driver. With the current driver, when I would download from my stock VX-8R, I would get traceback errors and then a blank Settings menu even though _has_settings was False for the base VX8Radio class. It was obvious that the VX8DRadio class functions were getting called even though the radio was a stock VX-8R (AH029). The only way I could get this behaviour to stop was to delete the VARIANT and change each radio MODEL from VX-8 to VX-8R, VX-8DR, and VX-8GE respectively.
The patch is somewhat lengthy due to the fact that I promoted most of the VX8DRadio class functions to the VX8Radio base class. This left the VX8DRadio class with just functions that were somewhat different for the VX-8DR and VX-8GE (e.g. _get_aprs_tx_settings) or unique to the VX-8DR and VX-8GE (e.g. _get_aprs_smartbeacon).
Hopefully, I haven't introduced any PEP-8 violations..PyCharm is pretty good at yelling at me about those. Please review and feel free to toss the whole thing if it's felt that I'm off base on this approach.
73's,
Keith KF7DRV
On Sun, Jun 4, 2017 at 4:39 PM, Keith Williamson hkwilliamson@gmail.com wrote:
Hi Ray,
Yes, I would love to have a VX-8GR image also!
Thanks,
Keith
On Sun, Jun 4, 2017 at 3:01 PM, ray c rayslinky@gmail.com wrote:
FWIW, my VX-8GR identifies as AH041. I did a factory reset and took an image of it. It's not a DR, but I'd be happy to send it to you.
ray AC1BC
On Sun, Jun 4, 2017 at 4:59 PM, Keith Williamson via chirp_devel < chirp_devel@intrepid.danplanet.com> wrote:
Hi,
I think I figured out the "chirp" method for dealing with differing memory layouts between radios withing the same driver.
I split the aprs struct into a shorter aprs struct, followed by a aprs_msg_macro[%d] struct, and an aprs2 struct. I prepended both the aprs_msg_macro[%d] struct and the aprs2 struct with "#seekto 0x%04X;" I then computed the beginning address of the aprs_msg_macro[%d] struct and added the starting address and number of message macros to the _mem_params for both the VX8Radio and VX8DRadio classes. I also computed the beginning address of the aprs2 struct and added those to the _mem_params for both radio classes.
I've tested these changes with my VX-8R and the test image Yaesu_VX-8_R.img. This leads to a quandry.
Reading back through the archived messages from around 2013, I see that when the Settings support was added for the VX-8DR, the conclusion at the time was that Settings would not be supported for the stock VX-8R due to lack of a radio to test with. It was felt that most everyone would have sent their VX-8R's in for the Yaesu upgrade that added the enhanced memory and APRS support of the VX-8DR. Unfortunately, I was asleep at the switch and was unaware of that opportunity until it was no longer offered. I would have jumped on that given that APRS was one of my major drivers for buying the VX-8R in the first place. Bummer..would have definitely liked to have smart beaconing. Anyway, inspecting the Yaesu_VX-8_R.img memory, I see that it is an AH029 that appears to have come from Dan who I remember from the archives had gotten his upgraded through the Yaesu program. So, apparently, the upgrade didn't result in a change to the _model for the radio.
Does anybody know of a way to disambiguate between a stock VX-8R and an upgraded one? I need to be able to support upgraded VX-8R's as VX-8DR's.
Can anyone supply an image for a true VX-8DR so that I can test that my code changes for the VX8DRadio class?
Thanks in advance!
73's,
Keith KF7DRV
On Fri, Jun 2, 2017 at 6:16 PM, Keith Williamson <hkwilliamson@gmail.com
wrote:
Hi,
I'm trying to add support for Settings for the original VX-8R. I just recently have been switching over to chirp for all of my radios and was surprised to find that the Settings tab was empty after downloading from my VX-8R. After a few modifications to the vx8.py driver, I have settings coming up properly for my radio but have doubtless broken support for the VX-8DR.
The VX8-DR has expanded APRS features such as SmartBeaconing, more Message Macros, more DigiPaths, etc. These affect the memory layout some. To fix it (temporarily), I corrected the memory layout to align with the VX-8R and commented out the calls that referenced the now missing memory elements.
I'd like to contribute the changes back but I'm not sure how to handle support for both the VX-8R and VX-8DR (and VX-8GER). With differences in memory layout, should the VX-8R have a separate driver or can the memory layout differences be somehow accommodated within the same driver?
73's,
Keith KF7DRV
chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/pro jects/chirp/wiki/Developers
The patch is somewhat lengthy due to the fact that I promoted most of the VX8DRadio class functions to the VX8Radio base class. This left the VX8DRadio class with just functions that were somewhat different for the VX-8DR and VX-8GE (e.g. _get_aprs_tx_settings) or unique to the VX-8DR and VX-8GE (e.g. _get_aprs_smartbeacon).
Hopefully, I haven't introduced any PEP-8 violations..PyCharm is pretty good at yelling at me about those. Please review and feel free to toss the whole thing if it's felt that I'm off base on this approach.
I'm okay with the refactor (in fact, I'm sure it's sorely needed), but do you think you could split this up into smaller pieces? Ideally, you'd lead with a refactor of things up into the base class, and then follow on with the "new" stuff in a separate patch. If we merge and release this, and then in six months someone reports a weird regression, it'll be hard to do anything other than revert this entire patch to see if it solves the problem.
I know it'll be some work, but... are you willing?
Thanks!
--Dan
Hi Dan,
Understand and I am willing.
Perhaps instead of leading with the refactor of the VX8DRadio class functions up to the VX8Radio class, I should first fix the obvious bug of the VXDRadio functions getting called for a VX-8R. Next, I would propose doing a patch that accommodates the memory layout differences between the VX-8R and VX-8DR/VX-8GE. Then I would do a patch that moves the common functions up to the base class (but don't yet get called for the VX-8R). The last patch would be to enable settings for the VX-8R by setting "has_settings" to True in the get_features function and adding the special version of the get_aprs_tx setting function in the base class (which would be overloaded by the get_aprs_tx function in the VX8DRadio class).
Would this work OK for you?
Assuming I would start by fixing the issue of the bug where the VX8DRadio functions are getting called when you download from a VX-8R, I am not really happy with my current "fix" anyway. I ended up adding separate models (VX-8R, VX-8DR, and VX-8GE) to the Yaesu pull-down menu. This works fine but long-time VX-8* users of Chirp would potentially not notice this change and select VX-8R when they have a VX-8DR. Additionally, the pull down menu is busier since it's now contaminated with variants. This problem doesn't occur when opening any of the VX-8R, VX-8DR, or VX-8GE image files. The specific model is apparently correctly determined by the ident string at the beginning of the image file. However, it definitely occurs when you download from the radio. I haven't yet ferreted out the difference between model detection via an image file open and model detection in the context of download from a radio. I've noticed that in other drivers there are explicit functions for identifying the radio. Is this some missing but required functionality not in the current VX8 driver? It also seems that Chirp has an Alias construct that seems to have replaced the Variant construct. I'm clearly very confused around this topic and a few pointers/suggestions would be most helpful!
Cheers,
Keith KF7DRV
On Mon, Jun 5, 2017 at 11:36 AM, Dan Smith via chirp_devel < chirp_devel@intrepid.danplanet.com> wrote:
The patch is somewhat lengthy due to the fact that I promoted most of the VX8DRadio class functions to the VX8Radio base class. This left the VX8DRadio class with just functions that were somewhat different for the VX-8DR and VX-8GE (e.g. _get_aprs_tx_settings) or unique to the VX-8DR and VX-8GE (e.g. _get_aprs_smartbeacon).
Hopefully, I haven't introduced any PEP-8 violations..PyCharm is pretty good at yelling at me about those. Please review and feel free to toss the whole thing if it's felt that I'm off base on this approach.
I'm okay with the refactor (in fact, I'm sure it's sorely needed), but do you think you could split this up into smaller pieces? Ideally, you'd lead with a refactor of things up into the base class, and then follow on with the "new" stuff in a separate patch. If we merge and release this, and then in six months someone reports a weird regression, it'll be hard to do anything other than revert this entire patch to see if it solves the problem.
I know it'll be some work, but... are you willing?
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
Perhaps instead of leading with the refactor of the VX8DRadio class functions up to the VX8Radio class, I should first fix the obvious bug of the VXDRadio functions getting called for a VX-8R. Next, I would propose doing a patch that accommodates the memory layout differences between the VX-8R and VX-8DR/VX-8GE. Then I would do a patch that moves the common functions up to the base class (but don't yet get called for the VX-8R). The last patch would be to enable settings for the VX-8R by setting "has_settings" to True in the get_features function and adding the special version of the get_aprs_tx setting function in the base class (which would be overloaded by the get_aprs_tx function in the VX8DRadio class).
Would this work OK for you?
Sounds awesome. I like awesome.
Assuming I would start by fixing the issue of the bug where the VX8DRadio functions are getting called when you download from a VX-8R, I am not really happy with my current "fix" anyway. I ended up adding separate models (VX-8R, VX-8DR, and VX-8GE) to the Yaesu pull-down menu. This works fine but long-time VX-8* users of Chirp would potentially not notice this change and select VX-8R when they have a VX-8DR. Additionally, the pull down menu is busier since it's now contaminated with variants.
I don't really think that's necessarily a bad thing. It's nice to be able to do everything automatically all the time, but Yaesus aren't very auto-detect-friendly. I don't really think it's a problem to make people choose the specific model, nor do I really think we'll see flak from users about it. Especially if we can point to "things work that didn't work before" type issues.
This problem doesn't occur when opening any of the VX-8R, VX-8DR, or VX-8GE image files. The specific model is apparently correctly determined by the ident string at the beginning of the image file. However, it definitely occurs when you download from the radio. I haven't yet ferreted out the difference between model detection via an image file open and model detection in the context of download from a radio. I've noticed that in other drivers there are explicit functions for identifying the radio. Is this some missing but required functionality not in the current VX8 driver?
Well, those detection routines are to probe for sub-models to do different things during clone. I'm not sure that's really necessary here, unless you want to unify all of the variants into a single class, and just check properties of the image every time you want to do something that differs between them. That would be okay if you think it's worth it.
I assume that this is doable at all with Yaesus because they barf their model number as the first thing when you hit clone on the radio right? They're not (AFAIK) interrogate-able for model info like every other radio on the planet.
It also seems that Chirp has an Alias construct that seems to have replaced the Variant construct. I'm clearly very confused around this topic and a few pointers/suggestions would be most helpful!
Well, the reason we added that is because of all the models coming out of China that are just re-badged with no other apparent differences. Variant was added so you could have slight differences between the European and North American model of a radio. However, if the same radio is called "Foobar 9000" and "Whizbang 84" the variant isn't enough to distinguish them (that, and you don't actually need a different subclass for differences since there are none).
--Dan
OK cool. In that case, I'll leave the bug fix as is and make that the first patch. The goal of the first patch is simply to ensure that if you download from a VX-8R, you don't generate trace back errors and you don't get a Settings menu at all. In other words, ensure that the correct code gets called for a given variant.
On an administrative note, should we just reject Issue 4881 and have me create a new issue with the scope of work limited to the bug fix?
-Keith KF7DRV
On Mon, Jun 5, 2017 at 1:29 PM, Dan Smith via chirp_devel < chirp_devel@intrepid.danplanet.com> wrote:
Perhaps instead of leading with the refactor of the VX8DRadio class functions up to the VX8Radio class, I should first fix the obvious bug of the VXDRadio functions getting called for a VX-8R. Next, I would propose doing a patch that accommodates the memory layout differences between the VX-8R and VX-8DR/VX-8GE. Then I would do a patch that moves the common functions up to the base class (but don't yet get called for the VX-8R). The last patch would be to enable settings for the VX-8R by setting "has_settings" to True in the get_features function and adding the special version of the get_aprs_tx setting function in the base class (which would be overloaded by the get_aprs_tx function in the VX8DRadio class).
Would this work OK for you?
Sounds awesome. I like awesome.
Assuming I would start by fixing the issue of the bug where the VX8DRadio functions are getting called when you download from a VX-8R, I am not really happy with my current "fix" anyway. I ended up adding separate models (VX-8R, VX-8DR, and VX-8GE) to the Yaesu pull-down menu. This works fine but long-time VX-8* users of Chirp would potentially not notice this change and select VX-8R when they have a VX-8DR. Additionally, the pull down menu is busier since it's now contaminated with variants.
I don't really think that's necessarily a bad thing. It's nice to be able to do everything automatically all the time, but Yaesus aren't very auto-detect-friendly. I don't really think it's a problem to make people choose the specific model, nor do I really think we'll see flak from users about it. Especially if we can point to "things work that didn't work before" type issues.
This problem doesn't occur when opening any of the VX-8R, VX-8DR, or VX-8GE image files. The specific model is apparently correctly determined by the ident string at the beginning of the image file. However, it definitely occurs when you download from the radio. I haven't yet ferreted out the difference between model detection via an image file open and model detection in the context of download from a radio. I've noticed that in other drivers there are explicit functions for identifying the radio. Is this some missing but required functionality not in the current VX8 driver?
Well, those detection routines are to probe for sub-models to do different things during clone. I'm not sure that's really necessary here, unless you want to unify all of the variants into a single class, and just check properties of the image every time you want to do something that differs between them. That would be okay if you think it's worth it.
I assume that this is doable at all with Yaesus because they barf their model number as the first thing when you hit clone on the radio right? They're not (AFAIK) interrogate-able for model info like every other radio on the planet.
It also seems that Chirp has an Alias construct that seems to have replaced the Variant construct. I'm clearly very confused around this topic and a few pointers/suggestions would be most helpful!
Well, the reason we added that is because of all the models coming out of China that are just re-badged with no other apparent differences. Variant was added so you could have slight differences between the European and North American model of a radio. However, if the same radio is called "Foobar 9000" and "Whizbang 84" the variant isn't enough to distinguish them (that, and you don't actually need a different subclass for differences since there are none).
--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
OK cool. In that case, I'll leave the bug fix as is and make that the first patch. The goal of the first patch is simply to ensure that if you download from a VX-8R, you don't generate trace back errors and you don't get a Settings menu at all. In other words, ensure that the correct code gets called for a given variant.
Yeah, good plan.
On an administrative note, should we just reject Issue 4881 and have me create a new issue with the scope of work limited to the bug fix?
It's up to you, but I don't think you need to close it. You could call all of your patches "groundwork" for getting to 4881, or open a new bug for the correctness (i.e. fixing the tracebacks) and then any refactors are mostly groundwork for the end goal of settings support for the base driver.
But, your call as you're doing the work. I just granted you permissions to monkey with the issues, so you can close/create/link as you see fit.
Thanks!
--Dan
Hello,
Attached is patch "vx8-4883.patch" which resolves bug issue #4883. This patch simply creates distinct MODELs for each of the supported VX-8 variants and removes the VARIANT constant for each of the radio classes. The result is new Yaesu radio drop down selections for VX-8R, VX-8DR, and VX-8GE. Also attached are test image files for each of the three radios. Running "run-tests" for each of the radios yields all PASSED except for the VX-8R which yields SKIPPED for the Settings test. Running a full "run-tests" shows 735 TOTAL with 624 PASSED and 111 SKIPPED.
The tests/images file Yaesu_VX-8_R.img is replaced by identical file Yaesu_VX-8R.img reflecting the assumed naming convention of MANUFACTURER_MODEL[_VARIANT].img since the "R" variant was subsumed into the model.
Cheers,
Keith KF7DRV
On Mon, Jun 5, 2017 at 1:49 PM, Dan Smith via chirp_devel < chirp_devel@intrepid.danplanet.com> wrote:
OK cool. In that case, I'll leave the bug fix as is and make that the first patch. The goal of the first patch is simply to ensure that if you download from a VX-8R, you don't generate trace back errors and you don't get a Settings menu at all. In other words, ensure that the correct code gets called for a given variant.
Yeah, good plan.
On an administrative note, should we just reject Issue 4881 and have me create a new issue with the scope of work limited to the bug fix?
It's up to you, but I don't think you need to close it. You could call all of your patches "groundwork" for getting to 4881, or open a new bug for the correctness (i.e. fixing the tracebacks) and then any refactors are mostly groundwork for the end goal of settings support for the base driver.
But, your call as you're doing the work. I just granted you permissions to monkey with the issues, so you can close/create/link as you see fit.
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
Hello,
Attached is patch vx8-4881-1.patch. This patch lays some groundwork for adding setting support for the VX-8 (Issue #4881).
The patch simply moves all VX8DRadio class functions that I anticipate will be needed for the VX-8R up to the VX8Radio class.
None of the functions have been modified in any way and there are no changes to Chirp behaviour. I will follow this patch with a second groundwork patch where I will modify the radio memory layout to accommodate differences between the VX-8DR/VX-8GE and VX-8R layouts.
I have tested the attached patch will all three radio image files and all tests pass except that the Settings test continues to be skipped for the VX-8R only.
73's,
Keith
On Mon, Jun 5, 2017 at 5:07 PM, Keith Williamson hkwilliamson@gmail.com wrote:
Hello,
Attached is patch "vx8-4883.patch" which resolves bug issue #4883. This patch simply creates distinct MODELs for each of the supported VX-8 variants and removes the VARIANT constant for each of the radio classes. The result is new Yaesu radio drop down selections for VX-8R, VX-8DR, and VX-8GE. Also attached are test image files for each of the three radios. Running "run-tests" for each of the radios yields all PASSED except for the VX-8R which yields SKIPPED for the Settings test. Running a full "run-tests" shows 735 TOTAL with 624 PASSED and 111 SKIPPED.
The tests/images file Yaesu_VX-8_R.img is replaced by identical file Yaesu_VX-8R.img reflecting the assumed naming convention of MANUFACTURER_MODEL[_VARIANT]. img since the "R" variant was subsumed into the model.
Cheers,
Keith KF7DRV
On Mon, Jun 5, 2017 at 1:49 PM, Dan Smith via chirp_devel < chirp_devel@intrepid.danplanet.com> wrote:
OK cool. In that case, I'll leave the bug fix as is and make that the first patch. The goal of the first patch is simply to ensure that if you download from a VX-8R, you don't generate trace back errors and you don't get a Settings menu at all. In other words, ensure that the correct code gets called for a given variant.
Yeah, good plan.
On an administrative note, should we just reject Issue 4881 and have me create a new issue with the scope of work limited to the bug fix?
It's up to you, but I don't think you need to close it. You could call all of your patches "groundwork" for getting to 4881, or open a new bug for the correctness (i.e. fixing the tracebacks) and then any refactors are mostly groundwork for the end goal of settings support for the base driver.
But, your call as you're doing the work. I just granted you permissions to monkey with the issues, so you can close/create/link as you see fit.
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
Hi again,
Attached is patch "vx8-4881-2.patch". This patch modifies the radio memory layout to accommodate differences between the VX-8DR/VX-8GE and VX-8R layouts. (Issue #4881).
The patch divides the original memobj aprs struct into a shorter aprs struct, followed by an aprs_msg_macro[] struct, and then an aprs2 struct. The aprs_msg_macro struct and aprs2 struct are parameterized differently in the _mem_params of the VX8Radio class and the VX8DRadio class. All memory element dereferences that were formerly to the aprs struct but are now in either the aprs2 struct or aprs_msg_macro struct have been updated.
As with the prior patch, there are no changes to Chirp behaviour. At this point all of the necessary groundwork has been laid to add Settings support for the stock VX-8R. The patch for that will follow.
I have tested the attached patch will all three radio image files and all tests pass except that the Settings test continues to be skipped for the VX-8R only.
73's,
Keith
On Tue, Jun 6, 2017 at 10:31 AM, Keith Williamson hkwilliamson@gmail.com wrote:
Hello,
Attached is patch vx8-4881-1.patch. This patch lays some groundwork for adding setting support for the VX-8 (Issue #4881).
The patch simply moves all VX8DRadio class functions that I anticipate will be needed for the VX-8R up to the VX8Radio class.
None of the functions have been modified in any way and there are no changes to Chirp behaviour. I will follow this patch with a second groundwork patch where I will modify the radio memory layout to accommodate differences between the VX-8DR/VX-8GE and VX-8R layouts.
I have tested the attached patch will all three radio image files and all tests pass except that the Settings test continues to be skipped for the VX-8R only.
73's,
Keith
On Mon, Jun 5, 2017 at 5:07 PM, Keith Williamson hkwilliamson@gmail.com wrote:
Hello,
Attached is patch "vx8-4883.patch" which resolves bug issue #4883. This patch simply creates distinct MODELs for each of the supported VX-8 variants and removes the VARIANT constant for each of the radio classes. The result is new Yaesu radio drop down selections for VX-8R, VX-8DR, and VX-8GE. Also attached are test image files for each of the three radios. Running "run-tests" for each of the radios yields all PASSED except for the VX-8R which yields SKIPPED for the Settings test. Running a full "run-tests" shows 735 TOTAL with 624 PASSED and 111 SKIPPED.
The tests/images file Yaesu_VX-8_R.img is replaced by identical file Yaesu_VX-8R.img reflecting the assumed naming convention of MANUFACTURER_MODEL[_VARIANT].i mg since the "R" variant was subsumed into the model.
Cheers,
Keith KF7DRV
On Mon, Jun 5, 2017 at 1:49 PM, Dan Smith via chirp_devel < chirp_devel@intrepid.danplanet.com> wrote:
OK cool. In that case, I'll leave the bug fix as is and make that the first patch. The goal of the first patch is simply to ensure that if you download from a VX-8R, you don't generate trace back errors and you don't get a Settings menu at all. In other words, ensure that the correct code gets called for a given variant.
Yeah, good plan.
On an administrative note, should we just reject Issue 4881 and have me create a new issue with the scope of work limited to the bug fix?
It's up to you, but I don't think you need to close it. You could call all of your patches "groundwork" for getting to 4881, or open a new bug for the correctness (i.e. fixing the tracebacks) and then any refactors are mostly groundwork for the end goal of settings support for the base driver.
But, your call as you're doing the work. I just granted you permissions to monkey with the issues, so you can close/create/link as you see fit.
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/pro jects/chirp/wiki/Developers
Hi,
Resubmitting "vx8-4881-2.patch" as "vx8-4881-3.patch" because of PEP-8 error due to line length of 80. My bad..thought max line length was 80. Ensured that all lines are strictly less than 80 chars.
Cheers,
Keith
On Tue, Jun 6, 2017 at 12:49 PM, Keith Williamson hkwilliamson@gmail.com wrote:
Hi again,
Attached is patch "vx8-4881-2.patch". This patch modifies the radio memory layout to accommodate differences between the VX-8DR/VX-8GE and VX-8R layouts. (Issue #4881).
The patch divides the original memobj aprs struct into a shorter aprs struct, followed by an aprs_msg_macro[] struct, and then an aprs2 struct. The aprs_msg_macro struct and aprs2 struct are parameterized differently in the _mem_params of the VX8Radio class and the VX8DRadio class. All memory element dereferences that were formerly to the aprs struct but are now in either the aprs2 struct or aprs_msg_macro struct have been updated.
As with the prior patch, there are no changes to Chirp behaviour. At this point all of the necessary groundwork has been laid to add Settings support for the stock VX-8R. The patch for that will follow.
I have tested the attached patch will all three radio image files and all tests pass except that the Settings test continues to be skipped for the VX-8R only.
73's,
Keith
On Tue, Jun 6, 2017 at 10:31 AM, Keith Williamson hkwilliamson@gmail.com wrote:
Hello,
Attached is patch vx8-4881-1.patch. This patch lays some groundwork for adding setting support for the VX-8 (Issue #4881).
The patch simply moves all VX8DRadio class functions that I anticipate will be needed for the VX-8R up to the VX8Radio class.
None of the functions have been modified in any way and there are no changes to Chirp behaviour. I will follow this patch with a second groundwork patch where I will modify the radio memory layout to accommodate differences between the VX-8DR/VX-8GE and VX-8R layouts.
I have tested the attached patch will all three radio image files and all tests pass except that the Settings test continues to be skipped for the VX-8R only.
73's,
Keith
On Mon, Jun 5, 2017 at 5:07 PM, Keith Williamson hkwilliamson@gmail.com wrote:
Hello,
Attached is patch "vx8-4883.patch" which resolves bug issue #4883. This patch simply creates distinct MODELs for each of the supported VX-8 variants and removes the VARIANT constant for each of the radio classes. The result is new Yaesu radio drop down selections for VX-8R, VX-8DR, and VX-8GE. Also attached are test image files for each of the three radios. Running "run-tests" for each of the radios yields all PASSED except for the VX-8R which yields SKIPPED for the Settings test. Running a full "run-tests" shows 735 TOTAL with 624 PASSED and 111 SKIPPED.
The tests/images file Yaesu_VX-8_R.img is replaced by identical file Yaesu_VX-8R.img reflecting the assumed naming convention of MANUFACTURER_MODEL[_VARIANT].img since the "R" variant was subsumed into the model.
Cheers,
Keith KF7DRV
On Mon, Jun 5, 2017 at 1:49 PM, Dan Smith via chirp_devel < chirp_devel@intrepid.danplanet.com> wrote:
OK cool. In that case, I'll leave the bug fix as is and make that the first patch. The goal of the first patch is simply to ensure that if you download from a VX-8R, you don't generate trace back errors and you don't get a Settings menu at all. In other words, ensure that the correct code gets called for a given variant.
Yeah, good plan.
On an administrative note, should we just reject Issue 4881 and have me create a new issue with the scope of work limited to the bug fix?
It's up to you, but I don't think you need to close it. You could call all of your patches "groundwork" for getting to 4881, or open a new bug for the correctness (i.e. fixing the tracebacks) and then any refactors are mostly groundwork for the end goal of settings support for the base driver.
But, your call as you're doing the work. I just granted you permissions to monkey with the issues, so you can close/create/link as you see fit.
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/pro jects/chirp/wiki/Developers
Resubmitting "vx8-4881-2.patch" as "vx8-4881-3.patch" because of PEP-8 error due to line length of 80. My bad..thought max line length was 80. Ensured that all lines are strictly less than 80 chars.
It's already in tree, so I can't apply this unless I revert the other one. Can you just send a teensy incremental change rebased on the tip?
Thanks!
--Dan
Ah, I see. I figured if a patch "failed" the build it was yanked.
No problem. I'll send a patch that just fixes the PEP-8 error.
On Tue, Jun 6, 2017 at 6:14 PM, Dan Smith via chirp_devel < chirp_devel@intrepid.danplanet.com> wrote:
Resubmitting "vx8-4881-2.patch" as "vx8-4881-3.patch" because of PEP-8 error due to line length of 80. My bad..thought max line length was 80. Ensured that all lines are strictly less than 80 chars.
It's already in tree, so I can't apply this unless I revert the other one. Can you just send a teensy incremental change rebased on the tip?
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
Hi,
Attached is patch "vx8-4881-4.patch" which corrects the line > 79 chars violation. Also, I discovered that I left out the pad value of one of the new #seekto format strings I had added (had 0x%0X instead of 0x%04X). That's also corrected with this patch.
Cheers,
Keith
On Tue, Jun 6, 2017 at 7:32 PM, Keith Williamson hkwilliamson@gmail.com wrote:
Ah, I see. I figured if a patch "failed" the build it was yanked.
No problem. I'll send a patch that just fixes the PEP-8 error.
On Tue, Jun 6, 2017 at 6:14 PM, Dan Smith via chirp_devel < chirp_devel@intrepid.danplanet.com> wrote:
Resubmitting "vx8-4881-2.patch" as "vx8-4881-3.patch" because of PEP-8 error due to line length of 80. My bad..thought max line length was 80. Ensured that all lines are strictly less than 80 chars.
It's already in tree, so I can't apply this unless I revert the other one. Can you just send a teensy incremental change rebased on the tip?
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
participants (4)
-
Dan Smith -
Keith Williamson -
ray c -
Robert Terzi