[chirp_devel] Call for help
Hi all,
In case you haven't been seeing the activity lately, much progress is being made on the py3 branch in github:
https://github.com/kk7ds/chirp/commits/py3
Thanks to a lot of help from @sv1 and @KC9HI, all of the drivers are now at least syntax-compatible with python3, running automated tests, and progress is being made to test (with real hardware) as many as possible to iron out remaining incompatibilities:
https://github.com/kk7ds/chirp/blob/py3/tests/Python3_Driver_Testing.md
As of today, about 38% have been tested, so we've got some work to do. I think it's unrealistic to get all of them tested in the short term, but we should at least shoot for the major brands and popular models as much as possible. So, the first call for help item is:
1. If you have a radio in that list not marked as tested, please test and record it in tests/py3_driver_testers.txt with a PR
At the end of this email is a list of radios we have leads on for testing. Feel free to claim one of those, but the real prizes are the major models not on that list.
Next up is UI parity. I've been doing a lot of work on the wx UI lately and I'm pretty happy with it, so much that I've been using it exclusively for my personal programming for a while now. There are still some gaps missing that I need to take care of, and my current todo list is wrapped up here:
https://chirp.danplanet.com/versions/21
There are some things I'm not planning to pull into the new UI at all, and some things that can come later. So, the second call for help item is:
2. Please test the new UI, help brainstorm what needs to be implemented (or fixed) before we start looking for more regular users to start using it
I've got one-off test builds here:
https://trac.chirp.danplanet.com/chirp_next/
and will continue to generate those regularly until we get to the point of doing them automatically. The new macos build is much better than it has ever been, IMHO. It feels very native and will have universal2 intel/arm support the next time I roll it. Testing the bundled builds is important for sure, but getting a development environment running is also easier. You pretty much just need a recent python3 (3.10 recommended) and:
$ pip install -r requirements.txt
...should get you there. Please file issues for things you find, and select "chirp-py3" for "target version" and "chirp version" to help keep track of bugs only in the py3 version.
I've been keeping the py3 branch in sync with changes to master for several months and even though it's doable, it's majorly not fun. I think the light is visible at the end of the tunnel at this point, so I'd really like to make 2023 the year we freeze work on the current py2 branch and get people moving to the new stuff. I'd like to be able to start getting "power users" testing the new builds early next year, which hopefully will help fill out the model testing edges.
Thoughts on the plan?
If you've got a radio on the list that needs testing, please speak up here so we at least know which ones are potentially testable.
Thanks!
--Dan
List of drivers for which there is known likely tester already:
Abbree_AR-518 iradio_uv_5118.py AnyTone_OBLTR-8R anytone_ht.py AnyTone_TERMN-8R anytone_ht.py BTECH_GMRS-V1 gmrsvu1.py BTECH_GMRS-V2 gmrsv2.py BTECH_MURS-V1 mursv1.py BTECH_UV-50X3 vgc.py BTECH_UV-5X3 uv5x3.py Baofeng_BF-T1 bf-t1.py Baofeng_UV-6R uv6r.py Explorer_QRZ-1 th_uv88.py LUITON_LT-316 retevis_rt22.py LUITON_LT-580_UHF th9000.py LUITON_LT-580_VHF th9000.py LUITON_LT-725UV lt725UV.py MTC_UV-5R-3 uv5x3.py Radioddity_GA-2S h777.py Radioddity_R2 radioddity_r2.py Retevis_H777_Plus h777.py Retevis_RB15 retevis_rb15.py Retevis_RB17P retevis_rb17p.py Retevis_RB615 retevis_rb15.py Retevis_RT1 retevis_rt1.py Retevis_RT22 retevis_rt22.py Retevis_RT22FRS retevis_rt22.py Retevis_RT23 retevis_rt23.py Retevis_RT26 retevis_rt26.py Retevis_RT6 baofeng_wp970i.py Retevis_RT622 retevis_rt22.py Retevis_RT76P retevis_rt76p.py Retevis_RT85 th_uv88.py Retevis_RT87 retevis_rt87.py Retevis_RT9000D_136-174 th9000.py Retevis_RT9000D_136-174 th9000.py Retevis_RT9000D_136-174 th9000.py Retevis_RT98 retevis_rt98.py Rugges_RH5R-V2 rh5r_v2.py TDXone_TD-Q8A tdxone_tdq8a.py TID_TD-M8 retevis_rt22.py TYT_TH-UV88 th_uv88.py TYT_TH9000_144 th9000.py TYT_TH9000_220 th9000.py TYT_TH9000_440 th9000.py WLN_KD-C1 retevis_rt22.py Wouxun_KG-UV6 wouxun.py Yaesu_FT70D ft70.py Yaesu_FTM350 ftm350.py Zastone_ZT-X6 retevis_rt22.py
Hello Dan,
I think I can help out here on a few radios but I have a question:
- If you have a radio in that list not marked as tested, please test and record it in tests/py3_driver_testers.txt with a PR
Can you define what you mean by "test"? Do you want me to just read from the radio? Write say one memory location? Can you be specific here so there can be some testing consistency?
--David KI6ZHD
Can you define what you mean by "test"? Do you want me to just read from the radio? Write say one memory location? Can you be specific here so there can be some testing consistency?
Sorry, that was dumb of me, thanks for pointing out the ambiguity.
What I mean by test is cover the things we can't really test for in the automated tests. That *mostly* means read and write the radio over the serial port. However, since we load the memory map slightly differently after a clone than we do when loading from file, it's best to also test editing a memory between download and upload, to make sure we got our types set properly. That, and the settings (for radios that have them) can also be problem areas. So, in summary, the following would probably be a good baseline, and I think it's in line what what Jim and I have both been doing:
1. Download from the radio 2. Make a change to a memory 3a. If the driver has settings, load the settings tab, and 3b. Make some settings change 4. Upload to the radio 5. Confirm that the changes look right (and if not, see if it's more broken than the py2 release)
Make sense?
--Dan
I have a Yaesu FT-991A. I don't see it on the list. Is it expected to be compatible? I've never tried using Chirp with it.
Joe Pizzi KI5LST
-----Original Message----- From: chirp_devel-bounces@intrepid.danplanet.com chirp_devel-bounces@intrepid.danplanet.com On Behalf Of Dan Smith via chirp_devel Sent: Sunday, December 4, 2022 12:13 PM To: chirp-devel chirp_devel@intrepid.danplanet.com Subject: Re: [chirp_devel] Call for help
Can you define what you mean by "test"? Do you want me to just read from
the radio? Write say one memory location? Can you be specific here so there can be some testing consistency?
Sorry, that was dumb of me, thanks for pointing out the ambiguity.
What I mean by test is cover the things we can't really test for in the automated tests. That *mostly* means read and write the radio over the serial port. However, since we load the memory map slightly differently after a clone than we do when loading from file, it's best to also test editing a memory between download and upload, to make sure we got our types set properly. That, and the settings (for radios that have them) can also be problem areas. So, in summary, the following would probably be a good baseline, and I think it's in line what what Jim and I have both been doing:
1. Download from the radio 2. Make a change to a memory 3a. If the driver has settings, load the settings tab, and 3b. Make some settings change 4. Upload to the radio 5. Confirm that the changes look right (and if not, see if it's more broken than the py2 release)
Make sense?
--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
I have a Yaesu FT-991A. I don't see it on the list. Is it expected to be compatible? I've never tried using Chirp with it.
There's no driver for it yet, that I know of, nope. I actually have local access to one, so I could work on it at some point, but it'll be after this effort :)
--Dan
Hi Dan,
I logget into github to see what I could do to contribute; and there's a chirp py3 repository I was already part of at https://github.com/mpoletiek/py3-CHIRP
Is this abandoned now? I don't think I actually ever made any contributions to it; but just checking to make sure that two groups aren't doing near identical work twice.
Thanks,
-Mark
On 2022-12-04 08:58, Dan Smith via chirp_devel wrote:
Hi all,
In case you haven't been seeing the activity lately, much progress is being made on the py3 branch in github:
https://github.com/kk7ds/chirp/commits/py3
Thanks to a lot of help from @sv1 and @KC9HI, all of the drivers are now at least syntax-compatible with python3, running automated tests, and progress is being made to test (with real hardware) as many as possible to iron out remaining incompatibilities:
https://github.com/kk7ds/chirp/blob/py3/tests/Python3_Driver_Testing.md
As of today, about 38% have been tested, so we've got some work to do. I think it's unrealistic to get all of them tested in the short term, but we should at least shoot for the major brands and popular models as much as possible. So, the first call for help item is:
- If you have a radio in that list not marked as tested, please test and record it in tests/py3_driver_testers.txt with a PR
At the end of this email is a list of radios we have leads on for testing. Feel free to claim one of those, but the real prizes are the major models not on that list.
Next up is UI parity. I've been doing a lot of work on the wx UI lately and I'm pretty happy with it, so much that I've been using it exclusively for my personal programming for a while now. There are still some gaps missing that I need to take care of, and my current todo list is wrapped up here:
https://chirp.danplanet.com/versions/21
There are some things I'm not planning to pull into the new UI at all, and some things that can come later. So, the second call for help item is:
- Please test the new UI, help brainstorm what needs to be implemented (or fixed) before we start looking for more regular users to start using it
I've got one-off test builds here:
https://trac.chirp.danplanet.com/chirp_next/
and will continue to generate those regularly until we get to the point of doing them automatically. The new macos build is much better than it has ever been, IMHO. It feels very native and will have universal2 intel/arm support the next time I roll it. Testing the bundled builds is important for sure, but getting a development environment running is also easier. You pretty much just need a recent python3 (3.10 recommended) and:
$ pip install -r requirements.txt
...should get you there. Please file issues for things you find, and select "chirp-py3" for "target version" and "chirp version" to help keep track of bugs only in the py3 version.
I've been keeping the py3 branch in sync with changes to master for several months and even though it's doable, it's majorly not fun. I think the light is visible at the end of the tunnel at this point, so I'd really like to make 2023 the year we freeze work on the current py2 branch and get people moving to the new stuff. I'd like to be able to start getting "power users" testing the new builds early next year, which hopefully will help fill out the model testing edges.
Thoughts on the plan?
If you've got a radio on the list that needs testing, please speak up here so we at least know which ones are potentially testable.
Thanks!
--Dan
List of drivers for which there is known likely tester already:
Abbree_AR-518 iradio_uv_5118.py AnyTone_OBLTR-8R anytone_ht.py AnyTone_TERMN-8R anytone_ht.py BTECH_GMRS-V1 gmrsvu1.py BTECH_GMRS-V2 gmrsv2.py BTECH_MURS-V1 mursv1.py BTECH_UV-50X3 vgc.py BTECH_UV-5X3 uv5x3.py Baofeng_BF-T1 bf-t1.py Baofeng_UV-6R uv6r.py Explorer_QRZ-1 th_uv88.py LUITON_LT-316 retevis_rt22.py LUITON_LT-580_UHF th9000.py LUITON_LT-580_VHF th9000.py LUITON_LT-725UV lt725UV.py MTC_UV-5R-3 uv5x3.py Radioddity_GA-2S h777.py Radioddity_R2 radioddity_r2.py Retevis_H777_Plus h777.py Retevis_RB15 retevis_rb15.py Retevis_RB17P retevis_rb17p.py Retevis_RB615 retevis_rb15.py Retevis_RT1 retevis_rt1.py Retevis_RT22 retevis_rt22.py Retevis_RT22FRS retevis_rt22.py Retevis_RT23 retevis_rt23.py Retevis_RT26 retevis_rt26.py Retevis_RT6 baofeng_wp970i.py Retevis_RT622 retevis_rt22.py Retevis_RT76P retevis_rt76p.py Retevis_RT85 th_uv88.py Retevis_RT87 retevis_rt87.py Retevis_RT9000D_136-174 th9000.py Retevis_RT9000D_136-174 th9000.py Retevis_RT9000D_136-174 th9000.py Retevis_RT98 retevis_rt98.py Rugges_RH5R-V2 rh5r_v2.py TDXone_TD-Q8A tdxone_tdq8a.py TID_TD-M8 retevis_rt22.py TYT_TH-UV88 th_uv88.py TYT_TH9000_144 th9000.py TYT_TH9000_220 th9000.py TYT_TH9000_440 th9000.py WLN_KD-C1 retevis_rt22.py Wouxun_KG-UV6 wouxun.py Yaesu_FT70D ft70.py Yaesu_FTM350 ftm350.py Zastone_ZT-X6 retevis_rt22.py _______________________________________________ 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
I logget into github to see what I could do to contribute; and there's a chirp py3 repository I was already part of at https://github.com/mpoletiek/py3-CHIRP
Is this abandoned now? I don't think I actually ever made any contributions to it; but just checking to make sure that two groups aren't doing near identical work twice.
Yeah, I don't know anything about that fork. Looks like some work was done there, but I dunno how well it works or what the state of it is...
--Dan
That is the repo that Matthew Poletiek created, back before August of 2021. He agreed to abandon it in November of 2021.
Joe Pizzi KI5LST
-----Original Message----- From: chirp_devel-bounces@intrepid.danplanet.com chirp_devel-bounces@intrepid.danplanet.com On Behalf Of Dan Smith via chirp_devel Sent: Monday, December 5, 2022 8:36 AM To: chirp-devel chirp_devel@intrepid.danplanet.com Subject: Re: [chirp_devel] Call for help
I logget into github to see what I could do to contribute; and there's a chirp py3 repository I was already part of at https://github.com/mpoletiek/py3-CHIRP
Is this abandoned now? I don't think I actually ever made any contributions to it; but just checking to make sure that two groups aren't doing near identical work twice.
Yeah, I don't know anything about that fork. Looks like some work was done there, but I dunno how well it works or what the state of it is...
--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
Hey folks!
Yeah, that's mine. Sorry, life and all.
I'll make it private now.
On Mon, Dec 5, 2022, 19:44 Joe Pizzi via chirp_devel < chirp_devel@intrepid.danplanet.com> wrote:
That is the repo that Matthew Poletiek created, back before August of 2021. He agreed to abandon it in November of 2021.
Joe Pizzi KI5LST
-----Original Message----- From: chirp_devel-bounces@intrepid.danplanet.com chirp_devel-bounces@intrepid.danplanet.com On Behalf Of Dan Smith via chirp_devel Sent: Monday, December 5, 2022 8:36 AM To: chirp-devel chirp_devel@intrepid.danplanet.com Subject: Re: [chirp_devel] Call for help
I logget into github to see what I could do to contribute; and there's a chirp py3 repository I was already part of at https://github.com/mpoletiek/py3-CHIRP
Is this abandoned now? I don't think I actually ever made any contributions to it; but just checking to make sure that two groups aren't doing near identical work twice.
Yeah, I don't know anything about that fork. Looks like some work was done there, but I dunno how well it works or what the state of it is...
--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
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
My repo is now private.
Hanging onto it as it's how I program my radio currently (baofeng). If I have a moment this weekend I'll test the new "official" github repo.
Glad to finally see forward progress on py3!! ------------------------------------------- Matthew Poletiek 303.810.9082 matthew.poletiek@gmail.com www.matthewpoletiek.com
On Mon, Dec 5, 2022 at 7:49 PM Matthew Poletiek matthew.poletiek@gmail.com wrote:
Hey folks!
Yeah, that's mine. Sorry, life and all.
I'll make it private now.
On Mon, Dec 5, 2022, 19:44 Joe Pizzi via chirp_devel chirp_devel@intrepid.danplanet.com wrote:
That is the repo that Matthew Poletiek created, back before August of 2021. He agreed to abandon it in November of 2021.
Joe Pizzi KI5LST
-----Original Message----- From: chirp_devel-bounces@intrepid.danplanet.com chirp_devel-bounces@intrepid.danplanet.com On Behalf Of Dan Smith via chirp_devel Sent: Monday, December 5, 2022 8:36 AM To: chirp-devel chirp_devel@intrepid.danplanet.com Subject: Re: [chirp_devel] Call for help
I logget into github to see what I could do to contribute; and there's a chirp py3 repository I was already part of at https://github.com/mpoletiek/py3-CHIRP
Is this abandoned now? I don't think I actually ever made any contributions to it; but just checking to make sure that two groups aren't doing near identical work twice.
Yeah, I don't know anything about that fork. Looks like some work was done there, but I dunno how well it works or what the state of it is...
--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
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
I haven't seen a lot of response to this (specifically the radio testing effort) this week. Jim has been plugging away at testing what he has in his museum of radios and is making us all look bad (in a good way). But, there's a lot of stuff on the list that he doesn't have in his collection, and I've exhausted mine.
I know David spoke up that he might be able to do some testing, but other than that I'm thinking we might need to rope in a larger audience.
If you think you have radios on the list that you can test locally:
https://github.com/kk7ds/chirp/blob/py3/tests/Python3_Driver_Testing.md
Please speak up, even if you won't be able to do it right away. Knowing who has (or has access) to what at least gives an idea of how much more we're likely to be able to do.
If I haven't heard much by Monday I think I'll try to send out a similar call for help to the users list and various other places in hopes that some capable user types can help close that gap. That's a potential large can of worms though. I think almost all the Icom models are likely to "just work", and a bunch of the Yaesu ones will as well. However, many of the others will require work I think.
Thanks!
--Dan
On Dec 4, 2022, at 08:58, Dan Smith via chirp_devel chirp_devel@intrepid.danplanet.com wrote:
Hi all,
In case you haven't been seeing the activity lately, much progress is being made on the py3 branch in github:
https://github.com/kk7ds/chirp/commits/py3
Thanks to a lot of help from @sv1 and @KC9HI, all of the drivers are now at least syntax-compatible with python3, running automated tests, and progress is being made to test (with real hardware) as many as possible to iron out remaining incompatibilities:
https://github.com/kk7ds/chirp/blob/py3/tests/Python3_Driver_Testing.md
As of today, about 38% have been tested, so we've got some work to do. I think it's unrealistic to get all of them tested in the short term, but we should at least shoot for the major brands and popular models as much as possible. So, the first call for help item is:
- If you have a radio in that list not marked as tested, please test and record it in tests/py3_driver_testers.txt with a PR
At the end of this email is a list of radios we have leads on for testing. Feel free to claim one of those, but the real prizes are the major models not on that list.
Next up is UI parity. I've been doing a lot of work on the wx UI lately and I'm pretty happy with it, so much that I've been using it exclusively for my personal programming for a while now. There are still some gaps missing that I need to take care of, and my current todo list is wrapped up here:
https://chirp.danplanet.com/versions/21
There are some things I'm not planning to pull into the new UI at all, and some things that can come later. So, the second call for help item is:
- Please test the new UI, help brainstorm what needs to be implemented (or fixed) before we start looking for more regular users to start using it
I've got one-off test builds here:
https://trac.chirp.danplanet.com/chirp_next/
and will continue to generate those regularly until we get to the point of doing them automatically. The new macos build is much better than it has ever been, IMHO. It feels very native and will have universal2 intel/arm support the next time I roll it. Testing the bundled builds is important for sure, but getting a development environment running is also easier. You pretty much just need a recent python3 (3.10 recommended) and:
$ pip install -r requirements.txt
...should get you there. Please file issues for things you find, and select "chirp-py3" for "target version" and "chirp version" to help keep track of bugs only in the py3 version.
I've been keeping the py3 branch in sync with changes to master for several months and even though it's doable, it's majorly not fun. I think the light is visible at the end of the tunnel at this point, so I'd really like to make 2023 the year we freeze work on the current py2 branch and get people moving to the new stuff. I'd like to be able to start getting "power users" testing the new builds early next year, which hopefully will help fill out the model testing edges.
Thoughts on the plan?
If you've got a radio on the list that needs testing, please speak up here so we at least know which ones are potentially testable.
Thanks!
--Dan
List of drivers for which there is known likely tester already:
Abbree_AR-518 iradio_uv_5118.py AnyTone_OBLTR-8R anytone_ht.py AnyTone_TERMN-8R anytone_ht.py BTECH_GMRS-V1 gmrsvu1.py BTECH_GMRS-V2 gmrsv2.py BTECH_MURS-V1 mursv1.py BTECH_UV-50X3 vgc.py BTECH_UV-5X3 uv5x3.py Baofeng_BF-T1 bf-t1.py Baofeng_UV-6R uv6r.py Explorer_QRZ-1 th_uv88.py LUITON_LT-316 retevis_rt22.py LUITON_LT-580_UHF th9000.py LUITON_LT-580_VHF th9000.py LUITON_LT-725UV lt725UV.py MTC_UV-5R-3 uv5x3.py Radioddity_GA-2S h777.py Radioddity_R2 radioddity_r2.py Retevis_H777_Plus h777.py Retevis_RB15 retevis_rb15.py Retevis_RB17P retevis_rb17p.py Retevis_RB615 retevis_rb15.py Retevis_RT1 retevis_rt1.py Retevis_RT22 retevis_rt22.py Retevis_RT22FRS retevis_rt22.py Retevis_RT23 retevis_rt23.py Retevis_RT26 retevis_rt26.py Retevis_RT6 baofeng_wp970i.py Retevis_RT622 retevis_rt22.py Retevis_RT76P retevis_rt76p.py Retevis_RT85 th_uv88.py Retevis_RT87 retevis_rt87.py Retevis_RT9000D_136-174 th9000.py Retevis_RT9000D_136-174 th9000.py Retevis_RT9000D_136-174 th9000.py Retevis_RT98 retevis_rt98.py Rugges_RH5R-V2 rh5r_v2.py TDXone_TD-Q8A tdxone_tdq8a.py TID_TD-M8 retevis_rt22.py TYT_TH-UV88 th_uv88.py TYT_TH9000_144 th9000.py TYT_TH9000_220 th9000.py TYT_TH9000_440 th9000.py WLN_KD-C1 retevis_rt22.py Wouxun_KG-UV6 wouxun.py Yaesu_FT70D ft70.py Yaesu_FTM350 ftm350.py Zastone_ZT-X6 retevis_rt22.py _______________________________________________ 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 Dan.
I have a Baofeng_BF-F8HP. I might be able to find some time this weekend!
On Fri, Dec 9, 2022, 09:45 Dan Smith via chirp_devel < chirp_devel@intrepid.danplanet.com> wrote:
I haven't seen a lot of response to this (specifically the radio testing effort) this week. Jim has been plugging away at testing what he has in his museum of radios and is making us all look bad (in a good way). But, there's a lot of stuff on the list that he doesn't have in his collection, and I've exhausted mine.
I know David spoke up that he might be able to do some testing, but other than that I'm thinking we might need to rope in a larger audience.
If you think you have radios on the list that you can test locally:
https://github.com/kk7ds/chirp/blob/py3/tests/Python3_Driver_Testing.md
Please speak up, even if you won't be able to do it right away. Knowing who has (or has access) to what at least gives an idea of how much more we're likely to be able to do.
If I haven't heard much by Monday I think I'll try to send out a similar call for help to the users list and various other places in hopes that some capable user types can help close that gap. That's a potential large can of worms though. I think almost all the Icom models are likely to "just work", and a bunch of the Yaesu ones will as well. However, many of the others will require work I think.
Thanks!
--Dan
On Dec 4, 2022, at 08:58, Dan Smith via chirp_devel <
chirp_devel@intrepid.danplanet.com> wrote:
Hi all,
In case you haven't been seeing the activity lately, much progress is
being made on the py3 branch in github:
https://github.com/kk7ds/chirp/commits/py3
Thanks to a lot of help from @sv1 and @KC9HI, all of the drivers are now
at least syntax-compatible with python3, running automated tests, and progress is being made to test (with real hardware) as many as possible to iron out remaining incompatibilities:
https://github.com/kk7ds/chirp/blob/py3/tests/Python3_Driver_Testing.md
As of today, about 38% have been tested, so we've got some work to do. I
think it's unrealistic to get all of them tested in the short term, but we should at least shoot for the major brands and popular models as much as possible. So, the first call for help item is:
- If you have a radio in that list not marked as tested, please test
and record it in tests/py3_driver_testers.txt with a PR
At the end of this email is a list of radios we have leads on for
testing. Feel free to claim one of those, but the real prizes are the major models not on that list.
Next up is UI parity. I've been doing a lot of work on the wx UI lately
and I'm pretty happy with it, so much that I've been using it exclusively for my personal programming for a while now. There are still some gaps missing that I need to take care of, and my current todo list is wrapped up here:
https://chirp.danplanet.com/versions/21
There are some things I'm not planning to pull into the new UI at all,
and some things that can come later. So, the second call for help item is:
- Please test the new UI, help brainstorm what needs to be implemented
(or fixed) before we start looking for more regular users to start using it
I've got one-off test builds here:
https://trac.chirp.danplanet.com/chirp_next/
and will continue to generate those regularly until we get to the point
of doing them automatically. The new macos build is much better than it has ever been, IMHO. It feels very native and will have universal2 intel/arm support the next time I roll it. Testing the bundled builds is important for sure, but getting a development environment running is also easier. You pretty much just need a recent python3 (3.10 recommended) and:
$ pip install -r requirements.txt
...should get you there. Please file issues for things you find, and
select "chirp-py3" for "target version" and "chirp version" to help keep track of bugs only in the py3 version.
I've been keeping the py3 branch in sync with changes to master for
several months and even though it's doable, it's majorly not fun. I think the light is visible at the end of the tunnel at this point, so I'd really like to make 2023 the year we freeze work on the current py2 branch and get people moving to the new stuff. I'd like to be able to start getting "power users" testing the new builds early next year, which hopefully will help fill out the model testing edges.
Thoughts on the plan?
If you've got a radio on the list that needs testing, please speak up
here so we at least know which ones are potentially testable.
Thanks!
--Dan
List of drivers for which there is known likely tester already:
Abbree_AR-518 iradio_uv_5118.py AnyTone_OBLTR-8R anytone_ht.py AnyTone_TERMN-8R anytone_ht.py BTECH_GMRS-V1 gmrsvu1.py BTECH_GMRS-V2 gmrsv2.py BTECH_MURS-V1 mursv1.py BTECH_UV-50X3 vgc.py BTECH_UV-5X3 uv5x3.py Baofeng_BF-T1 bf-t1.py Baofeng_UV-6R uv6r.py Explorer_QRZ-1 th_uv88.py LUITON_LT-316 retevis_rt22.py LUITON_LT-580_UHF th9000.py LUITON_LT-580_VHF th9000.py LUITON_LT-725UV lt725UV.py MTC_UV-5R-3 uv5x3.py Radioddity_GA-2S h777.py Radioddity_R2 radioddity_r2.py Retevis_H777_Plus h777.py Retevis_RB15 retevis_rb15.py Retevis_RB17P retevis_rb17p.py Retevis_RB615 retevis_rb15.py Retevis_RT1 retevis_rt1.py Retevis_RT22 retevis_rt22.py Retevis_RT22FRS retevis_rt22.py Retevis_RT23 retevis_rt23.py Retevis_RT26 retevis_rt26.py Retevis_RT6 baofeng_wp970i.py Retevis_RT622 retevis_rt22.py Retevis_RT76P retevis_rt76p.py Retevis_RT85 th_uv88.py Retevis_RT87 retevis_rt87.py Retevis_RT9000D_136-174 th9000.py Retevis_RT9000D_136-174 th9000.py Retevis_RT9000D_136-174 th9000.py Retevis_RT98 retevis_rt98.py Rugges_RH5R-V2 rh5r_v2.py TDXone_TD-Q8A tdxone_tdq8a.py TID_TD-M8 retevis_rt22.py TYT_TH-UV88 th_uv88.py TYT_TH9000_144 th9000.py TYT_TH9000_220 th9000.py TYT_TH9000_440 th9000.py WLN_KD-C1 retevis_rt22.py Wouxun_KG-UV6 wouxun.py Yaesu_FT70D ft70.py Yaesu_FTM350 ftm350.py Zastone_ZT-X6 retevis_rt22.py _______________________________________________ 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
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
I’ll test the Quansheng tg-uv2, hopefully this week
Ran
On 9 Dec 2022, at 18:13, Dan Smith via chirp_devel chirp_devel@intrepid.danplanet.com wrote:
I have a Baofeng_BF-F8HP. I might be able to find some time this weekend!
Sweet, not on the list nor in Jim's museum, that'll be a good one :)
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 Matthew,
On Fri, Dec 9, 2022 at 11:10 AM Matthew Poletiek via chirp_devel chirp_devel@intrepid.danplanet.com wrote:
HI Dan.
I have a Baofeng_BF-F8HP. I might be able to find some time this weekend!
Thank you for your willingness to help. Just so that you are aware, all of the radios that are supported by the uv5r.py driver (which includes the Baofeng BF-F8HP) have been tested.
Jim KC9HI
I have a Baofeng_BF-F8HP. I might be able to find some time this weekend!
Thank you for your willingness to help. Just so that you are aware, all of the radios that are supported by the uv5r.py driver (which includes the Baofeng BF-F8HP) have been tested.
Oops, I must have been looking at the wrong row in the matrix, my bad.
--Dan
Awesome! Disregard then!
On Fri, Dec 9, 2022, 11:17 Jim Unroe rock.unroe@gmail.com wrote:
Hi Matthew,
On Fri, Dec 9, 2022 at 11:10 AM Matthew Poletiek via chirp_devel chirp_devel@intrepid.danplanet.com wrote:
HI Dan.
I have a Baofeng_BF-F8HP. I might be able to find some time this weekend!
Thank you for your willingness to help. Just so that you are aware, all of the radios that are supported by the uv5r.py driver (which includes the Baofeng BF-F8HP) have been tested.
Jim KC9HI
I will test: Baojie BJ-218, The Luiton LT 725UV should be implied from the Baojie BJ-218 IC-2730A FT-450D TYT TH-UV8000 Kenwood TS-480_Clone and Live modes Kenwood TS-590S Clone and Live mode eventually; have to get access to the radios
On 12/9/2022 7:45 AM, Dan Smith via chirp_devel wrote:
I haven't seen a lot of response to this (specifically the radio testing effort) this week. Jim has been plugging away at testing what he has in his museum of radios and is making us all look bad (in a good way). But, there's a lot of stuff on the list that he doesn't have in his collection, and I've exhausted mine.
I know David spoke up that he might be able to do some testing, but other than that I'm thinking we might need to rope in a larger audience.
If you think you have radios on the list that you can test locally:
https://github.com/kk7ds/chirp/blob/py3/tests/Python3_Driver_Testing.md
Please speak up, even if you won't be able to do it right away. Knowing who has (or has access) to what at least gives an idea of how much more we're likely to be able to do.
If I haven't heard much by Monday I think I'll try to send out a similar call for help to the users list and various other places in hopes that some capable user types can help close that gap. That's a potential large can of worms though. I think almost all the Icom models are likely to "just work", and a bunch of the Yaesu ones will as well. However, many of the others will require work I think.
Thanks!
--Dan
On Dec 4, 2022, at 08:58, Dan Smith via chirp_develchirp_devel@intrepid.danplanet.com wrote:
Hi all,
In case you haven't been seeing the activity lately, much progress is being made on the py3 branch in github:
https://github.com/kk7ds/chirp/commits/py3
Thanks to a lot of help from @sv1 and @KC9HI, all of the drivers are now at least syntax-compatible with python3, running automated tests, and progress is being made to test (with real hardware) as many as possible to iron out remaining incompatibilities:
https://github.com/kk7ds/chirp/blob/py3/tests/Python3_Driver_Testing.md
As of today, about 38% have been tested, so we've got some work to do. I think it's unrealistic to get all of them tested in the short term, but we should at least shoot for the major brands and popular models as much as possible. So, the first call for help item is:
- If you have a radio in that list not marked as tested, please test and record it in tests/py3_driver_testers.txt with a PR
At the end of this email is a list of radios we have leads on for testing. Feel free to claim one of those, but the real prizes are the major models not on that list.
Next up is UI parity. I've been doing a lot of work on the wx UI lately and I'm pretty happy with it, so much that I've been using it exclusively for my personal programming for a while now. There are still some gaps missing that I need to take care of, and my current todo list is wrapped up here:
https://chirp.danplanet.com/versions/21
There are some things I'm not planning to pull into the new UI at all, and some things that can come later. So, the second call for help item is:
- Please test the new UI, help brainstorm what needs to be implemented (or fixed) before we start looking for more regular users to start using it
I've got one-off test builds here:
https://trac.chirp.danplanet.com/chirp_next/
and will continue to generate those regularly until we get to the point of doing them automatically. The new macos build is much better than it has ever been, IMHO. It feels very native and will have universal2 intel/arm support the next time I roll it. Testing the bundled builds is important for sure, but getting a development environment running is also easier. You pretty much just need a recent python3 (3.10 recommended) and:
$ pip install -r requirements.txt
...should get you there. Please file issues for things you find, and select "chirp-py3" for "target version" and "chirp version" to help keep track of bugs only in the py3 version.
I've been keeping the py3 branch in sync with changes to master for several months and even though it's doable, it's majorly not fun. I think the light is visible at the end of the tunnel at this point, so I'd really like to make 2023 the year we freeze work on the current py2 branch and get people moving to the new stuff. I'd like to be able to start getting "power users" testing the new builds early next year, which hopefully will help fill out the model testing edges.
Thoughts on the plan?
If you've got a radio on the list that needs testing, please speak up here so we at least know which ones are potentially testable.
Thanks!
--Dan
List of drivers for which there is known likely tester already:
Abbree_AR-518 iradio_uv_5118.py AnyTone_OBLTR-8R anytone_ht.py AnyTone_TERMN-8R anytone_ht.py BTECH_GMRS-V1 gmrsvu1.py BTECH_GMRS-V2 gmrsv2.py BTECH_MURS-V1 mursv1.py BTECH_UV-50X3 vgc.py BTECH_UV-5X3 uv5x3.py Baofeng_BF-T1 bf-t1.py Baofeng_UV-6R uv6r.py Explorer_QRZ-1 th_uv88.py LUITON_LT-316 retevis_rt22.py LUITON_LT-580_UHF th9000.py LUITON_LT-580_VHF th9000.py LUITON_LT-725UV lt725UV.py MTC_UV-5R-3 uv5x3.py Radioddity_GA-2S h777.py Radioddity_R2 radioddity_r2.py Retevis_H777_Plus h777.py Retevis_RB15 retevis_rb15.py Retevis_RB17P retevis_rb17p.py Retevis_RB615 retevis_rb15.py Retevis_RT1 retevis_rt1.py Retevis_RT22 retevis_rt22.py Retevis_RT22FRS retevis_rt22.py Retevis_RT23 retevis_rt23.py Retevis_RT26 retevis_rt26.py Retevis_RT6 baofeng_wp970i.py Retevis_RT622 retevis_rt22.py Retevis_RT76P retevis_rt76p.py Retevis_RT85 th_uv88.py Retevis_RT87 retevis_rt87.py Retevis_RT9000D_136-174 th9000.py Retevis_RT9000D_136-174 th9000.py Retevis_RT9000D_136-174 th9000.py Retevis_RT98 retevis_rt98.py Rugges_RH5R-V2 rh5r_v2.py TDXone_TD-Q8A tdxone_tdq8a.py TID_TD-M8 retevis_rt22.py TYT_TH-UV88 th_uv88.py TYT_TH9000_144 th9000.py TYT_TH9000_220 th9000.py TYT_TH9000_440 th9000.py WLN_KD-C1 retevis_rt22.py Wouxun_KG-UV6 wouxun.py Yaesu_FT70D ft70.py Yaesu_FTM350 ftm350.py Zastone_ZT-X6 retevis_rt22.py _______________________________________________ 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
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
I will test: Baojie BJ-218, The Luiton LT 725UV should be implied from the Baojie BJ-218 IC-2730A FT-450D TYT TH-UV8000 Kenwood TS-480_Clone and Live modes Kenwood TS-590S Clone and Live mode eventually; have to get access to the radios
Awesome, thanks Rick. I've already tested your D710 clone mode driver and it seems to be doing well.
--Dan
Hi Rick,
On Fri, Dec 9, 2022 at 11:19 AM Rick (AA0RD) DeWitt via chirp_devel chirp_devel@intrepid.danplanet.com wrote:
I will test: Baojie BJ-218, The Luiton LT 725UV should be implied from the Baojie BJ-218
I have the Luiton LT-725UV and can test it directly. The Baojie BJ-318 cloning is the same as the Baojie BJ-218 (it just has some additional settings). So it can definitely be implied from the BJ-218.
Jim KC9HI
Hi Rick,
On Fri, Dec 9, 2022 at 11:19 AM Rick (AA0RD) DeWitt via chirp_devel chirp_devel@intrepid.danplanet.com wrote:
I will test: Baojie BJ-218, The Luiton LT 725UV should be implied from the Baojie BJ-218 IC-2730A FT-450D TYT TH-UV8000 Kenwood TS-480_Clone and Live modes Kenwood TS-590S Clone and Live mode eventually; have to get access to the radios
Since I have a Luiton LT-725UV, I just "fixed" the lt725.py driver. So you should be able to do a quick test with the Baojie BJ-218 and then add it and the implied BJ-318 to the matrix.
Jim KC9HI
Hey Dan,
Curious, what is the risk to the radios under test if things don't "work"? I really don't want to brick anything. The radios I could test include:
- Icom IC-80AD Dstar HT (hot sure if this is supported though) - Kenwood TM-D710A analog mobile - Yaesu FT1DR YSF HT
I have other radios but they already seem to have been tested. Is there any point in re-testing those?
--David KI6ZHD
On 12/09/2022 07:45 AM, Dan Smith via chirp_devel wrote:
I haven't seen a lot of response to this (specifically the radio testing effort) this week. Jim has been plugging away at testing what he has in his museum of radios and is making us all look bad (in a good way). But, there's a lot of stuff on the list that he doesn't have in his collection, and I've exhausted mine.
I know David spoke up that he might be able to do some testing, but other than that I'm thinking we might need to rope in a larger audience.
If you think you have radios on the list that you can test locally:
https://github.com/kk7ds/chirp/blob/py3/tests/Python3_Driver_Testing.md
Please speak up, even if you won't be able to do it right away. Knowing who has (or has access) to what at least gives an idea of how much more we're likely to be able to do.
If I haven't heard much by Monday I think I'll try to send out a similar call for help to the users list and various other places in hopes that some capable user types can help close that gap. That's a potential large can of worms though. I think almost all the Icom models are likely to "just work", and a bunch of the Yaesu ones will as well. However, many of the others will require work I think.
Thanks!
--Dan
On Dec 4, 2022, at 08:58, Dan Smith via chirp_devel chirp_devel@intrepid.danplanet.com wrote:
Hi all,
In case you haven't been seeing the activity lately, much progress is being made on the py3 branch in github:
https://github.com/kk7ds/chirp/commits/py3
Thanks to a lot of help from @sv1 and @KC9HI, all of the drivers are now at least syntax-compatible with python3, running automated tests, and progress is being made to test (with real hardware) as many as possible to iron out remaining incompatibilities:
https://github.com/kk7ds/chirp/blob/py3/tests/Python3_Driver_Testing.md
As of today, about 38% have been tested, so we've got some work to do. I think it's unrealistic to get all of them tested in the short term, but we should at least shoot for the major brands and popular models as much as possible. So, the first call for help item is:
- If you have a radio in that list not marked as tested, please test and record it in tests/py3_driver_testers.txt with a PR
At the end of this email is a list of radios we have leads on for testing. Feel free to claim one of those, but the real prizes are the major models not on that list.
Next up is UI parity. I've been doing a lot of work on the wx UI lately and I'm pretty happy with it, so much that I've been using it exclusively for my personal programming for a while now. There are still some gaps missing that I need to take care of, and my current todo list is wrapped up here:
https://chirp.danplanet.com/versions/21
There are some things I'm not planning to pull into the new UI at all, and some things that can come later. So, the second call for help item is:
- Please test the new UI, help brainstorm what needs to be implemented (or fixed) before we start looking for more regular users to start using it
I've got one-off test builds here:
https://trac.chirp.danplanet.com/chirp_next/
and will continue to generate those regularly until we get to the point of doing them automatically. The new macos build is much better than it has ever been, IMHO. It feels very native and will have universal2 intel/arm support the next time I roll it. Testing the bundled builds is important for sure, but getting a development environment running is also easier. You pretty much just need a recent python3 (3.10 recommended) and:
$ pip install -r requirements.txt
...should get you there. Please file issues for things you find, and select "chirp-py3" for "target version" and "chirp version" to help keep track of bugs only in the py3 version.
I've been keeping the py3 branch in sync with changes to master for several months and even though it's doable, it's majorly not fun. I think the light is visible at the end of the tunnel at this point, so I'd really like to make 2023 the year we freeze work on the current py2 branch and get people moving to the new stuff. I'd like to be able to start getting "power users" testing the new builds early next year, which hopefully will help fill out the model testing edges.
Thoughts on the plan?
If you've got a radio on the list that needs testing, please speak up here so we at least know which ones are potentially testable.
Thanks!
--Dan
List of drivers for which there is known likely tester already:
Abbree_AR-518 iradio_uv_5118.py AnyTone_OBLTR-8R anytone_ht.py AnyTone_TERMN-8R anytone_ht.py BTECH_GMRS-V1 gmrsvu1.py BTECH_GMRS-V2 gmrsv2.py BTECH_MURS-V1 mursv1.py BTECH_UV-50X3 vgc.py BTECH_UV-5X3 uv5x3.py Baofeng_BF-T1 bf-t1.py Baofeng_UV-6R uv6r.py Explorer_QRZ-1 th_uv88.py LUITON_LT-316 retevis_rt22.py LUITON_LT-580_UHF th9000.py LUITON_LT-580_VHF th9000.py LUITON_LT-725UV lt725UV.py MTC_UV-5R-3 uv5x3.py Radioddity_GA-2S h777.py Radioddity_R2 radioddity_r2.py Retevis_H777_Plus h777.py Retevis_RB15 retevis_rb15.py Retevis_RB17P retevis_rb17p.py Retevis_RB615 retevis_rb15.py Retevis_RT1 retevis_rt1.py Retevis_RT22 retevis_rt22.py Retevis_RT22FRS retevis_rt22.py Retevis_RT23 retevis_rt23.py Retevis_RT26 retevis_rt26.py Retevis_RT6 baofeng_wp970i.py Retevis_RT622 retevis_rt22.py Retevis_RT76P retevis_rt76p.py Retevis_RT85 th_uv88.py Retevis_RT87 retevis_rt87.py Retevis_RT9000D_136-174 th9000.py Retevis_RT9000D_136-174 th9000.py Retevis_RT9000D_136-174 th9000.py Retevis_RT98 retevis_rt98.py Rugges_RH5R-V2 rh5r_v2.py TDXone_TD-Q8A tdxone_tdq8a.py TID_TD-M8 retevis_rt22.py TYT_TH-UV88 th_uv88.py TYT_TH9000_144 th9000.py TYT_TH9000_220 th9000.py TYT_TH9000_440 th9000.py WLN_KD-C1 retevis_rt22.py Wouxun_KG-UV6 wouxun.py Yaesu_FT70D ft70.py Yaesu_FTM350 ftm350.py Zastone_ZT-X6 retevis_rt22.py _______________________________________________ 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
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
Curious, what is the risk to the radios under test if things don't "work"? I really don't want to brick anything.
Not really any different than normal, with one caveat. If you try to upload to the radio and hit some py3-related issue in the clone routine, the clone will stop and most radios will reset themselves. If you capture an image with the current regular build so you can restore the radio in that case, not much concern.
For the radios that aren't tested and need work, it's likely that download will fail first, and so no harm in that. But, if someone is fixing issues for you and they don't get upload quite right, that's when you'd want an image of the radio to restore.
The radios I could test include:
- Icom IC-80AD Dstar HT (hot sure if this is supported though)
Is that different than the ID-80? The latter is on the list.
- Kenwood TM-D710A analog mobile
I tested the GA, which probably means the A is fine, but if it's easy to try, then go for it. You could test it in both live and clone mode (live being uber safe, FWIW).
- Yaesu FT1DR YSF HT
Cool, this uses some of the standardized yaesu clone stuff, so this might be a "just works" one.
I have other radios but they already seem to have been tested. Is there any point in re-testing those?
Not so much for the checking off things on the list, but certainly worthwhile in general!
--Dan
I don't have many radios, and only one on the list that's not accounted for yet: a Yaesu VX-6R. I didn't speak up because I didn't have time right away, but I should be able to test it sometime this weekend or next, if nobody else beats me to it.
Also, I've been watching from the sidelines for a while now, regretting not being able to help more, so I want to say thanks to everyone who's put in effort to get the py3 branch to where it is. I know it's been a lot of work, and probably pretty thankless.
Nick
On Fri, Dec 9, 2022, at 10:45 AM, Dan Smith via chirp_devel wrote:
I haven't seen a lot of response to this (specifically the radio testing effort) this week. Jim has been plugging away at testing what he has in his museum of radios and is making us all look bad (in a good way). But, there's a lot of stuff on the list that he doesn't have in his collection, and I've exhausted mine.
I know David spoke up that he might be able to do some testing, but other than that I'm thinking we might need to rope in a larger audience.
If you think you have radios on the list that you can test locally:
https://github.com/kk7ds/chirp/blob/py3/tests/Python3_Driver_Testing.md
Please speak up, even if you won't be able to do it right away. Knowing who has (or has access) to what at least gives an idea of how much more we're likely to be able to do.
If I haven't heard much by Monday I think I'll try to send out a similar call for help to the users list and various other places in hopes that some capable user types can help close that gap. That's a potential large can of worms though. I think almost all the Icom models are likely to "just work", and a bunch of the Yaesu ones will as well. However, many of the others will require work I think.
Thanks!
--Dan
On Dec 4, 2022, at 08:58, Dan Smith via chirp_devel chirp_devel@intrepid.danplanet.com wrote:
Hi all,
In case you haven't been seeing the activity lately, much progress is being made on the py3 branch in github:
https://github.com/kk7ds/chirp/commits/py3
Thanks to a lot of help from @sv1 and @KC9HI, all of the drivers are now at least syntax-compatible with python3, running automated tests, and progress is being made to test (with real hardware) as many as possible to iron out remaining incompatibilities:
https://github.com/kk7ds/chirp/blob/py3/tests/Python3_Driver_Testing.md
As of today, about 38% have been tested, so we've got some work to do. I think it's unrealistic to get all of them tested in the short term, but we should at least shoot for the major brands and popular models as much as possible. So, the first call for help item is:
- If you have a radio in that list not marked as tested, please test and record it in tests/py3_driver_testers.txt with a PR
At the end of this email is a list of radios we have leads on for testing. Feel free to claim one of those, but the real prizes are the major models not on that list.
Next up is UI parity. I've been doing a lot of work on the wx UI lately and I'm pretty happy with it, so much that I've been using it exclusively for my personal programming for a while now. There are still some gaps missing that I need to take care of, and my current todo list is wrapped up here:
https://chirp.danplanet.com/versions/21
There are some things I'm not planning to pull into the new UI at all, and some things that can come later. So, the second call for help item is:
- Please test the new UI, help brainstorm what needs to be implemented (or fixed) before we start looking for more regular users to start using it
I've got one-off test builds here:
https://trac.chirp.danplanet.com/chirp_next/
and will continue to generate those regularly until we get to the point of doing them automatically. The new macos build is much better than it has ever been, IMHO. It feels very native and will have universal2 intel/arm support the next time I roll it. Testing the bundled builds is important for sure, but getting a development environment running is also easier. You pretty much just need a recent python3 (3.10 recommended) and:
$ pip install -r requirements.txt
...should get you there. Please file issues for things you find, and select "chirp-py3" for "target version" and "chirp version" to help keep track of bugs only in the py3 version.
I've been keeping the py3 branch in sync with changes to master for several months and even though it's doable, it's majorly not fun. I think the light is visible at the end of the tunnel at this point, so I'd really like to make 2023 the year we freeze work on the current py2 branch and get people moving to the new stuff. I'd like to be able to start getting "power users" testing the new builds early next year, which hopefully will help fill out the model testing edges.
Thoughts on the plan?
If you've got a radio on the list that needs testing, please speak up here so we at least know which ones are potentially testable.
Thanks!
--Dan
List of drivers for which there is known likely tester already:
Abbree_AR-518 iradio_uv_5118.py AnyTone_OBLTR-8R anytone_ht.py AnyTone_TERMN-8R anytone_ht.py BTECH_GMRS-V1 gmrsvu1.py BTECH_GMRS-V2 gmrsv2.py BTECH_MURS-V1 mursv1.py BTECH_UV-50X3 vgc.py BTECH_UV-5X3 uv5x3.py Baofeng_BF-T1 bf-t1.py Baofeng_UV-6R uv6r.py Explorer_QRZ-1 th_uv88.py LUITON_LT-316 retevis_rt22.py LUITON_LT-580_UHF th9000.py LUITON_LT-580_VHF th9000.py LUITON_LT-725UV lt725UV.py MTC_UV-5R-3 uv5x3.py Radioddity_GA-2S h777.py Radioddity_R2 radioddity_r2.py Retevis_H777_Plus h777.py Retevis_RB15 retevis_rb15.py Retevis_RB17P retevis_rb17p.py Retevis_RB615 retevis_rb15.py Retevis_RT1 retevis_rt1.py Retevis_RT22 retevis_rt22.py Retevis_RT22FRS retevis_rt22.py Retevis_RT23 retevis_rt23.py Retevis_RT26 retevis_rt26.py Retevis_RT6 baofeng_wp970i.py Retevis_RT622 retevis_rt22.py Retevis_RT76P retevis_rt76p.py Retevis_RT85 th_uv88.py Retevis_RT87 retevis_rt87.py Retevis_RT9000D_136-174 th9000.py Retevis_RT9000D_136-174 th9000.py Retevis_RT9000D_136-174 th9000.py Retevis_RT98 retevis_rt98.py Rugges_RH5R-V2 rh5r_v2.py TDXone_TD-Q8A tdxone_tdq8a.py TID_TD-M8 retevis_rt22.py TYT_TH-UV88 th_uv88.py TYT_TH9000_144 th9000.py TYT_TH9000_220 th9000.py TYT_TH9000_440 th9000.py WLN_KD-C1 retevis_rt22.py Wouxun_KG-UV6 wouxun.py Yaesu_FT70D ft70.py Yaesu_FTM350 ftm350.py Zastone_ZT-X6 retevis_rt22.py _______________________________________________ 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
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
I don't have many radios, and only one on the list that's not accounted for yet: a Yaesu VX-6R. I didn't speak up because I didn't have time right away, but I should be able to test it sometime this weekend or next, if nobody else beats me to it.
That's cool, a VX-6 would be good to knock off the list, and I think it's likely to "just work" because it shares a lot in common with the other radios in that vintage (VX-7, VX-8, etc). That said, I haven't actually tested those since 2019, so I should re-do that just to be sure. I'll try to do that today, but will look forward to your report about the VX-6.
--Dan
That's cool, a VX-6 would be good to knock off the list, and I think it's likely to "just work" because it shares a lot in common with the other radios in that vintage (VX-7, VX-8, etc). That said, I haven't actually tested those since 2019, so I should re-do that just to be sure. I'll try to do that today, but will look forward to your report about the VX-6.
I confirmed that my VX-7 and VX-8DR radios are still good, so I suspect your VX-6 will be no problem.
Also, this morning I scraped some data out of our error reports and added a "Market Share" column to the testing matrix, which gives us an idea of which radios are the most important to get tested.
https://github.com/kk7ds/chirp/blob/py3/tests/Python3_Driver_Testing.md
Luckily, we've got all the major ones already, and even though only 53% of models have been tested as working, that represents 77% of the share of chirp users, which is pretty good. Interestingly, the VX-6 is oddly popular amongst its siblings:
Yaesu_VX-3 0.08% Yaesu_VX-5 0.07% Yaesu_VX-6 0.16% Yaesu_VX-7 0.09% Yaesu_VX-8DR 0.03%
Still tiny compared to the almighty UV-5R, but going strong compared to peers.
I'm also thinking of marking all the Kenwood live radios as implied tested, as these are almost all the same code, and being string-based, pretty solid. That will increase our numbers a bit more. After the initial conversion, I've not encountered any problems with any of those that I've tried.
I think starting to push users to the newer builds (especially if they're on platforms like Linux and MacOS that desperately need a modern platform) when 80% of them will be supported is pretty reasonable.
--Dan
I tried the VX-6R. Downloading, changing a memory, and uploading works. I'm having trouble with the banks and settings though.
For the banks:
I can download them from the radio, add and remove memories from banks, and upload to the radio, but the UI in this tab is a bit glitchy. For one thing, it's very sluggish, especially when scrolling. But also, when trying to add a memory to a bank, it doesn't actually show the checkmark until clicking on another cell in the table (unchecking is slightly slow but otherwise works normally). Lastly, in the py2 release, there's an extra tab to change the bank names. Not sure if it's on purpose, but that tab is missing in the py3 build, and there doesn't seem to be another way to change the names.
For the settings tab:
This one is completely broken for me, raising an exception (see below) and leaving the tab blank. But I tried it in the py2 release and it's broken there too, so it doesn't seem to be a regression. It's possible this exception may be my fault. It's been quite a while since I've done anything with this radio in CHIRP, but I could have sworn the settings page used to work. I do know that I later spent some time trying to reverse engineer some of the settings missing from CHIRP, so I'm wondering if I may have corrupted the image a little.
Here are the exceptions from the settings tab in the py3 branch:
Traceback (most recent call last): File "/home/dominickpastore/chirp/chirp/drivers/vx6.py", line 823, in get_settings return self._get_settings() File "/home/dominickpastore/chirp/chirp/drivers/vx6.py", line 640, in _get_settings val = RadioSettingValueString(0, 16, File "/home/dominickpastore/chirp/chirp/settings.py", line 215, in __init__ self.set_value(current) File "/home/dominickpastore/chirp/chirp/settings.py", line 229, in set_value raise InvalidValueError("Value contains invalid " + chirp.settings.InvalidValueError: Value contains invalid character `'
ERROR: Context raised unexpected_exception Traceback (most recent call last): File "/home/dominickpastore/chirp/chirp/wxui/settingsedit.py", line 49, in _initialize self._load_settings() File "/home/dominickpastore/chirp/chirp/wxui/settingsedit.py", line 59, in _load_settings for group in self._settings: TypeError: 'NoneType' object is not iterable Traceback (most recent call last): File "/usr/lib/python3/dist-packages/wx/core.py", line 3285, in <lambda> lambda event: event.callable(*event.args, **event.kw) ) File "/home/dominickpastore/chirp/chirp/wxui/settingsedit.py", line 49, in _initialize self._load_settings() File "/home/dominickpastore/chirp/chirp/wxui/settingsedit.py", line 59, in _load_settings for group in self._settings: TypeError: 'NoneType' object is not iterable
And here are the exceptions from the settings tab in the py2 build:
Traceback (most recent call last): File "/app/lib/python2.7/site-packages/chirp/drivers/vx6.py", line 823, in get_settings return self._get_settings() File "/app/lib/python2.7/site-packages/chirp/drivers/vx6.py", line 642, in _get_settings _settings.arts_cwid_alpha)) File "/app/lib/python2.7/site-packages/chirp/settings.py", line 212, in __init__ self.set_value(current) File "/app/lib/python2.7/site-packages/chirp/settings.py", line 227, in set_value "character `%s'" % char) InvalidValueError: Value contains invalid character `'
Traceback (most recent call last): File "/app/lib/python2.7/site-packages/chirp/ui/settingsedit.py", line 220, in _build_ui raise Exception("Invalid Radio Settings") Exception: Invalid Radio Settings
On Fri, Dec 9, 2022, at 7:14 PM, Dan Smith via chirp_devel wrote:
That's cool, a VX-6 would be good to knock off the list, and I think it's likely to "just work" because it shares a lot in common with the other radios in that vintage (VX-7, VX-8, etc). That said, I haven't actually tested those since 2019, so I should re-do that just to be sure. I'll try to do that today, but will look forward to your report about the VX-6.
I confirmed that my VX-7 and VX-8DR radios are still good, so I suspect your VX-6 will be no problem.
Also, this morning I scraped some data out of our error reports and added a "Market Share" column to the testing matrix, which gives us an idea of which radios are the most important to get tested.
https://github.com/kk7ds/chirp/blob/py3/tests/Python3_Driver_Testing.md
Luckily, we've got all the major ones already, and even though only 53% of models have been tested as working, that represents 77% of the share of chirp users, which is pretty good. Interestingly, the VX-6 is oddly popular amongst its siblings:
Yaesu_VX-3 0.08% Yaesu_VX-5 0.07% Yaesu_VX-6 0.16% Yaesu_VX-7 0.09% Yaesu_VX-8DR 0.03%
Still tiny compared to the almighty UV-5R, but going strong compared to peers.
I'm also thinking of marking all the Kenwood live radios as implied tested, as these are almost all the same code, and being string-based, pretty solid. That will increase our numbers a bit more. After the initial conversion, I've not encountered any problems with any of those that I've tried.
I think starting to push users to the newer builds (especially if they're on platforms like Linux and MacOS that desperately need a modern platform) when 80% of them will be supported is pretty reasonable.
--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
I tried the VX-6R. Downloading, changing a memory, and uploading works. I'm having trouble with the banks and settings though.
Okay, so that's likely not VX-6 related so I think we can call it tested. Do you want to do a PR to add yourself? If not, I can do it for you. If you have a github id that's how we've been recording them, or I can just use your name.
For the banks:
I can download them from the radio, add and remove memories from banks, and upload to the radio, but the UI in this tab is a bit glitchy. For one thing, it's very sluggish, especially when scrolling. But also, when trying to add a memory to a bank, it doesn't actually show the checkmark until clicking on another cell in the table (unchecking is slightly slow but otherwise works normally). Lastly, in the py2 release, there's an extra tab to change the bank names. Not sure if it's on purpose, but that tab is missing in the py3 build, and there doesn't seem to be another way to change the names.
For the settings tab:
This one is completely broken for me, raising an exception (see below) and leaving the tab blank. But I tried it in the py2 release and it's broken there too, so it doesn't seem to be a regression. It's possible this exception may be my fault. It's been quite a while since I've done anything with this radio in CHIRP, but I could have sworn the settings page used to work. I do know that I later spent some time trying to reverse engineer some of the settings missing from CHIRP, so I'm wondering if I may have corrupted the image a little.
Okay, yeah, if you can file a bug with this info and include your radio image? I'll have a look there.
https://chirp.danplanet.com/projects/chirp/issues/new
You're right, I haven't implemented the bank name editing yet. The bank editor is very fast for me with a test radio with 1000 memories across 26 banks. I'll test with the VX-6 image to see if something about its bank model is causing it heartburn. Yaesus are a bit weird in that banks are many-to-many mappings, unlike basically every other model. Please include your platform details in the bug too so I can try to repro.
Thanks!
--Dan
On Sat, Dec 10, 2022, at 10:36 PM, Dan Smith via chirp_devel wrote:
Okay, so that's likely not VX-6 related so I think we can call it tested. Do you want to do a PR to add yourself? If not, I can do it for you. If you have a github id that's how we've been recording them, or I can just use your name.
Done. I see you got it already.
For the banks:
I can download them from the radio, add and remove memories from banks, and upload to the radio, but the UI in this tab is a bit glitchy. For one thing, it's very sluggish, especially when scrolling. But also, when trying to add a memory to a bank, it doesn't actually show the checkmark until clicking on another cell in the table (unchecking is slightly slow but otherwise works normally). Lastly, in the py2 release, there's an extra tab to change the bank names. Not sure if it's on purpose, but that tab is missing in the py3 build, and there doesn't seem to be another way to change the names.
For the settings tab:
This one is completely broken for me, raising an exception (see below) and leaving the tab blank. But I tried it in the py2 release and it's broken there too, so it doesn't seem to be a regression. It's possible this exception may be my fault. It's been quite a while since I've done anything with this radio in CHIRP, but I could have sworn the settings page used to work. I do know that I later spent some time trying to reverse engineer some of the settings missing from CHIRP, so I'm wondering if I may have corrupted the image a little.
Okay, yeah, if you can file a bug with this info and include your radio image? I'll have a look there.
https://chirp.danplanet.com/projects/chirp/issues/new
You're right, I haven't implemented the bank name editing yet. The bank editor is very fast for me with a test radio with 1000 memories across 26 banks. I'll test with the VX-6 image to see if something about its bank model is causing it heartburn. Yaesus are a bit weird in that banks are many-to-many mappings, unlike basically every other model. Please include your platform details in the bug too so I can try to repro.
I opened these as separate bugs. One for the settings page and one for the sluggishness and checkbox issues on the banks page. I hope that's okay. If there's not enough detail (e.g. about my platform), let me know. https://chirp.danplanet.com/issues/10171 https://chirp.danplanet.com/issues/10172
There was one other UI issue I didn't mention in the last message. The vendor and model dropdowns in the radio download/upload dialogs are cut off for me. I think that's probably due to my high DPI display. I opened a bug for that too. https://chirp.danplanet.com/issues/10173
Thanks, Nick
I opened these as separate bugs. One for the settings page and one for the sluggishness and checkbox issues on the banks page. I hope that's okay. If there's not enough detail (e.g. about my platform), let me know. https://chirp.danplanet.com/issues/10171 https://chirp.danplanet.com/issues/10172
There was one other UI issue I didn't mention in the last message. The vendor and model dropdowns in the radio download/upload dialogs are cut off for me. I think that's probably due to my high DPI display. I opened a bug for that too. https://chirp.danplanet.com/issues/10173
Yep, perfect, thanks. I poked around last night on windows and mac and couldn't get anything resembling sluggishness on those machines with oodles of memories and banks, so it might be a GTK thing. I don't have a hidpi linux machine to test with, but I can run it over remote X which usually highlights pathological UI behavior.
Thanks!
--Dan
I have a Leixen VV-898, and I'll try to get to it this weekend.
On Fri, Dec 09, 2022 at 07:45:28AM -0800, Dan Smith via chirp_devel wrote:
I haven't seen a lot of response to this (specifically the radio testing effort) this week. Jim has been plugging away at testing what he has in his museum of radios and is making us all look bad (in a good way). But, there's a lot of stuff on the list that he doesn't have in his collection, and I've exhausted mine.
I know David spoke up that he might be able to do some testing, but other than that I'm thinking we might need to rope in a larger audience.
If you think you have radios on the list that you can test locally:
https://github.com/kk7ds/chirp/blob/py3/tests/Python3_Driver_Testing.md
Please speak up, even if you won't be able to do it right away. Knowing who has (or has access) to what at least gives an idea of how much more we're likely to be able to do.
If I haven't heard much by Monday I think I'll try to send out a similar call for help to the users list and various other places in hopes that some capable user types can help close that gap. That's a potential large can of worms though. I think almost all the Icom models are likely to "just work", and a bunch of the Yaesu ones will as well. However, many of the others will require work I think.
Thanks!
--Dan
On Dec 4, 2022, at 08:58, Dan Smith via chirp_devel chirp_devel@intrepid.danplanet.com wrote:
Hi all,
In case you haven't been seeing the activity lately, much progress is being made on the py3 branch in github:
https://github.com/kk7ds/chirp/commits/py3
Thanks to a lot of help from @sv1 and @KC9HI, all of the drivers are now at least syntax-compatible with python3, running automated tests, and progress is being made to test (with real hardware) as many as possible to iron out remaining incompatibilities:
https://github.com/kk7ds/chirp/blob/py3/tests/Python3_Driver_Testing.md
As of today, about 38% have been tested, so we've got some work to do. I think it's unrealistic to get all of them tested in the short term, but we should at least shoot for the major brands and popular models as much as possible. So, the first call for help item is:
- If you have a radio in that list not marked as tested, please test and record it in tests/py3_driver_testers.txt with a PR
At the end of this email is a list of radios we have leads on for testing. Feel free to claim one of those, but the real prizes are the major models not on that list.
Next up is UI parity. I've been doing a lot of work on the wx UI lately and I'm pretty happy with it, so much that I've been using it exclusively for my personal programming for a while now. There are still some gaps missing that I need to take care of, and my current todo list is wrapped up here:
https://chirp.danplanet.com/versions/21
There are some things I'm not planning to pull into the new UI at all, and some things that can come later. So, the second call for help item is:
- Please test the new UI, help brainstorm what needs to be implemented (or fixed) before we start looking for more regular users to start using it
I've got one-off test builds here:
https://trac.chirp.danplanet.com/chirp_next/
and will continue to generate those regularly until we get to the point of doing them automatically. The new macos build is much better than it has ever been, IMHO. It feels very native and will have universal2 intel/arm support the next time I roll it. Testing the bundled builds is important for sure, but getting a development environment running is also easier. You pretty much just need a recent python3 (3.10 recommended) and:
$ pip install -r requirements.txt
...should get you there. Please file issues for things you find, and select "chirp-py3" for "target version" and "chirp version" to help keep track of bugs only in the py3 version.
I've been keeping the py3 branch in sync with changes to master for several months and even though it's doable, it's majorly not fun. I think the light is visible at the end of the tunnel at this point, so I'd really like to make 2023 the year we freeze work on the current py2 branch and get people moving to the new stuff. I'd like to be able to start getting "power users" testing the new builds early next year, which hopefully will help fill out the model testing edges.
Thoughts on the plan?
If you've got a radio on the list that needs testing, please speak up here so we at least know which ones are potentially testable.
Thanks!
--Dan
List of drivers for which there is known likely tester already:
Abbree_AR-518 iradio_uv_5118.py AnyTone_OBLTR-8R anytone_ht.py AnyTone_TERMN-8R anytone_ht.py BTECH_GMRS-V1 gmrsvu1.py BTECH_GMRS-V2 gmrsv2.py BTECH_MURS-V1 mursv1.py BTECH_UV-50X3 vgc.py BTECH_UV-5X3 uv5x3.py Baofeng_BF-T1 bf-t1.py Baofeng_UV-6R uv6r.py Explorer_QRZ-1 th_uv88.py LUITON_LT-316 retevis_rt22.py LUITON_LT-580_UHF th9000.py LUITON_LT-580_VHF th9000.py LUITON_LT-725UV lt725UV.py MTC_UV-5R-3 uv5x3.py Radioddity_GA-2S h777.py Radioddity_R2 radioddity_r2.py Retevis_H777_Plus h777.py Retevis_RB15 retevis_rb15.py Retevis_RB17P retevis_rb17p.py Retevis_RB615 retevis_rb15.py Retevis_RT1 retevis_rt1.py Retevis_RT22 retevis_rt22.py Retevis_RT22FRS retevis_rt22.py Retevis_RT23 retevis_rt23.py Retevis_RT26 retevis_rt26.py Retevis_RT6 baofeng_wp970i.py Retevis_RT622 retevis_rt22.py Retevis_RT76P retevis_rt76p.py Retevis_RT85 th_uv88.py Retevis_RT87 retevis_rt87.py Retevis_RT9000D_136-174 th9000.py Retevis_RT9000D_136-174 th9000.py Retevis_RT9000D_136-174 th9000.py Retevis_RT98 retevis_rt98.py Rugges_RH5R-V2 rh5r_v2.py TDXone_TD-Q8A tdxone_tdq8a.py TID_TD-M8 retevis_rt22.py TYT_TH-UV88 th_uv88.py TYT_TH9000_144 th9000.py TYT_TH9000_220 th9000.py TYT_TH9000_440 th9000.py WLN_KD-C1 retevis_rt22.py Wouxun_KG-UV6 wouxun.py Yaesu_FT70D ft70.py Yaesu_FTM350 ftm350.py Zastone_ZT-X6 retevis_rt22.py _______________________________________________ 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
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
I have a Leixen VV-898, and I'll try to get to it this weekend.
Great, thanks! I just took a look and that driver and it will definitely need some love to make it happy, but it seems quite simple and thus should be fairly straightforward. There are lots of recent examples of conversions in the tree to look at. Here are a few:
https://github.com/kk7ds/chirp/commits/fda922775d6f69e8d8f5b93f0f95888b1d7c4...
https://github.com/kk7ds/chirp/commit/adb317bb0db923210ef7253525a6decac8bf7b...
https://github.com/kk7ds/chirp/commit/4c70adca96328acabacd8f4d9a77f464d6b7b2...
--Dan
Sorry for the delay testing the VV-898S, turns out in addition to the radio, you also need the programming cable... ;-) The radio is actually a VV-898S not a VV-898 as I originally thought. I'm not sure if there's any difference as far as programming it.
Bottom line, it looks to me like the python3 build is working properly, and I didn't have to make any changes to the code. I'm using the git py3 branch as of this morning with Python 3.10.8 on Fedora Linux. I didn't do exhaustive testing, but I was able to download an image from the radio, modify memories and all the settings I would normally, upload the modified image, and see my changes take effect.
You mentioned you thought the driver would need some work, so if there are specific things you think might be broken, I'm happy to do further testing, but as far as I'm concerned, it works for what I need.
FWIW, I also like the new widget set better, and I'm so happy to have build that works easily on Linux.
Thanks!
Dave
On Fri, Dec 09, 2022 at 07:14:11PM -0800, Dan Smith via chirp_devel wrote:
I have a Leixen VV-898, and I'll try to get to it this weekend.
Great, thanks! I just took a look and that driver and it will definitely need some love to make it happy, but it seems quite simple and thus should be fairly straightforward. There are lots of recent examples of conversions in the tree to look at. Here are a few:
https://github.com/kk7ds/chirp/commits/fda922775d6f69e8d8f5b93f0f95888b1d7c4...
https://github.com/kk7ds/chirp/commit/adb317bb0db923210ef7253525a6decac8bf7b...
https://github.com/kk7ds/chirp/commit/4c70adca96328acabacd8f4d9a77f464d6b7b2...
--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
Sorry for the delay testing the VV-898S, turns out in addition to the radio, you also need the programming cable... ;-)
Hah, half the work in all of this has been matching radios to programming cables. I have a giant box of each and I suck at labeling one-offs :P
The radio is actually a VV-898S not a VV-898 as I originally thought. I'm not sure if there's any difference as far as programming it.
They're the same in terms of programming
Bottom line, it looks to me like the python3 build is working properly, and I didn't have to make any changes to the code. I'm using the git py3 branch as of this morning with Python 3.10.8 on Fedora Linux. I didn't do exhaustive testing, but I was able to download an image from the radio, modify memories and all the settings I would normally, upload the modified image, and see my changes take effect.
You mentioned you thought the driver would need some work, so if there are specific things you think might be broken, I'm happy to do further testing, but as far as I'm concerned, it works for what I need.
I did. Turns out it's the same as the JT270MH. Turns out I had one of those stashed in a closet. So, I did the conversion of that driver between you volunteering and me discovering that. Sounds like it worked out :)
If you want to submit a PR to convert that from implied to actually tested by you, that would be great, as tested with real hardware is better. I'm also happy to do it for you (tell me your github id if you have one).
FWIW, I also like the new widget set better, and I'm so happy to have build that works easily on Linux.
Fantastic, me too on both counts.
Thanks!
--Dan
Hi, to all
Not much free time on this side, but catching up.
Radios at hand that I will check and the family that will cover:
* Feidaxin FD-268A: all supported Feidaxin listed * Baofeng BF-T1 * Vertex Standard FTL-1011 & 2011: all supported Vertex Standard FTL-****
Also posted a request for help on the local ham group for the Kenwoods 260 family, That's a very common radio family here, once tested that will clear all this models:
* TK-260, TK-270, TK-272, TK-278, TK-360, TK-370, TK-372 & TK-378
Will let you now!
73 Pavel CO7WT.
El 4/12/22 a las 11:58, Dan Smith via chirp_devel escribió:
Hi all,
In case you haven't been seeing the activity lately, much progress is being made on the py3 branch in github:
https://github.com/kk7ds/chirp/commits/py3
Thanks to a lot of help from @sv1 and @KC9HI, all of the drivers are now at least syntax-compatible with python3, running automated tests, and progress is being made to test (with real hardware) as many as possible to iron out remaining incompatibilities:
https://github.com/kk7ds/chirp/blob/py3/tests/Python3_Driver_Testing.md
As of today, about 38% have been tested, so we've got some work to do. I think it's unrealistic to get all of them tested in the short term, but we should at least shoot for the major brands and popular models as much as possible. So, the first call for help item is:
- If you have a radio in that list not marked as tested, please test and record it in tests/py3_driver_testers.txt with a PR
At the end of this email is a list of radios we have leads on for testing. Feel free to claim one of those, but the real prizes are the major models not on that list.
Next up is UI parity. I've been doing a lot of work on the wx UI lately and I'm pretty happy with it, so much that I've been using it exclusively for my personal programming for a while now. There are still some gaps missing that I need to take care of, and my current todo list is wrapped up here:
https://chirp.danplanet.com/versions/21
There are some things I'm not planning to pull into the new UI at all, and some things that can come later. So, the second call for help item is:
- Please test the new UI, help brainstorm what needs to be implemented (or fixed) before we start looking for more regular users to start using it
I've got one-off test builds here:
https://trac.chirp.danplanet.com/chirp_next/
and will continue to generate those regularly until we get to the point of doing them automatically. The new macos build is much better than it has ever been, IMHO. It feels very native and will have universal2 intel/arm support the next time I roll it. Testing the bundled builds is important for sure, but getting a development environment running is also easier. You pretty much just need a recent python3 (3.10 recommended) and:
$ pip install -r requirements.txt
...should get you there. Please file issues for things you find, and select "chirp-py3" for "target version" and "chirp version" to help keep track of bugs only in the py3 version.
I've been keeping the py3 branch in sync with changes to master for several months and even though it's doable, it's majorly not fun. I think the light is visible at the end of the tunnel at this point, so I'd really like to make 2023 the year we freeze work on the current py2 branch and get people moving to the new stuff. I'd like to be able to start getting "power users" testing the new builds early next year, which hopefully will help fill out the model testing edges.
Thoughts on the plan?
If you've got a radio on the list that needs testing, please speak up here so we at least know which ones are potentially testable.
Thanks!
--Dan
List of drivers for which there is known likely tester already:
Abbree_AR-518 iradio_uv_5118.py AnyTone_OBLTR-8R anytone_ht.py AnyTone_TERMN-8R anytone_ht.py BTECH_GMRS-V1 gmrsvu1.py BTECH_GMRS-V2 gmrsv2.py BTECH_MURS-V1 mursv1.py BTECH_UV-50X3 vgc.py BTECH_UV-5X3 uv5x3.py Baofeng_BF-T1 bf-t1.py Baofeng_UV-6R uv6r.py Explorer_QRZ-1 th_uv88.py LUITON_LT-316 retevis_rt22.py LUITON_LT-580_UHF th9000.py LUITON_LT-580_VHF th9000.py LUITON_LT-725UV lt725UV.py MTC_UV-5R-3 uv5x3.py Radioddity_GA-2S h777.py Radioddity_R2 radioddity_r2.py Retevis_H777_Plus h777.py Retevis_RB15 retevis_rb15.py Retevis_RB17P retevis_rb17p.py Retevis_RB615 retevis_rb15.py Retevis_RT1 retevis_rt1.py Retevis_RT22 retevis_rt22.py Retevis_RT22FRS retevis_rt22.py Retevis_RT23 retevis_rt23.py Retevis_RT26 retevis_rt26.py Retevis_RT6 baofeng_wp970i.py Retevis_RT622 retevis_rt22.py Retevis_RT76P retevis_rt76p.py Retevis_RT85 th_uv88.py Retevis_RT87 retevis_rt87.py Retevis_RT9000D_136-174 th9000.py Retevis_RT9000D_136-174 th9000.py Retevis_RT9000D_136-174 th9000.py Retevis_RT98 retevis_rt98.py Rugges_RH5R-V2 rh5r_v2.py TDXone_TD-Q8A tdxone_tdq8a.py TID_TD-M8 retevis_rt22.py TYT_TH-UV88 th_uv88.py TYT_TH9000_144 th9000.py TYT_TH9000_220 th9000.py TYT_TH9000_440 th9000.py WLN_KD-C1 retevis_rt22.py Wouxun_KG-UV6 wouxun.py Yaesu_FT70D ft70.py Yaesu_FTM350 ftm350.py Zastone_ZT-X6 retevis_rt22.py _______________________________________________ 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 Pavel,
Not much free time on this side, but catching up.
Radios at hand that I will check and the family that will cover:
Feidaxin FD-268A: all supported Feidaxin listed Baofeng BF-T1 Vertex Standard FTL-1011 & 2011: all supported Vertex Standard FTL-****
I happen to have a BF-T1 here. Since you have limited time available, I can go ahead and do that one if it is OK with you?
Jim KC9HI
Hi Jim
Go ahead!
I have to pick up the radios at my old house (the entire shack is in storage boxes, radios, tools, interfaces, etc) so you will make it faster than me.
Cheers, Pavel.
El 10/12/22 a las 14:39, Jim Unroe escribió:
Hi Pavel,
Not much free time on this side, but catching up.
Radios at hand that I will check and the family that will cover:
Feidaxin FD-268A: all supported Feidaxin listed Baofeng BF-T1 Vertex Standard FTL-1011 & 2011: all supported Vertex Standard FTL-****
I happen to have a BF-T1 here. Since you have limited time available, I can go ahead and do that one if it is OK with you?
Jim KC9HI
I’ll take the AnyTone 5888UVIII next week
-Brad KØBAS
Sent from my iPhone
On Dec 4, 2022, at 9:58 AM, Dan Smith via chirp_devel chirp_devel@intrepid.danplanet.com wrote:
Hi all,
In case you haven't been seeing the activity lately, much progress is being made on the py3 branch in github:
https://github.com/kk7ds/chirp/commits/py3
Thanks to a lot of help from @sv1 and @KC9HI, all of the drivers are now at least syntax-compatible with python3, running automated tests, and progress is being made to test (with real hardware) as many as possible to iron out remaining incompatibilities:
https://github.com/kk7ds/chirp/blob/py3/tests/Python3_Driver_Testing.md
As of today, about 38% have been tested, so we've got some work to do. I think it's unrealistic to get all of them tested in the short term, but we should at least shoot for the major brands and popular models as much as possible. So, the first call for help item is:
- If you have a radio in that list not marked as tested, please test and record it in tests/py3_driver_testers.txt with a PR
At the end of this email is a list of radios we have leads on for testing. Feel free to claim one of those, but the real prizes are the major models not on that list.
Next up is UI parity. I've been doing a lot of work on the wx UI lately and I'm pretty happy with it, so much that I've been using it exclusively for my personal programming for a while now. There are still some gaps missing that I need to take care of, and my current todo list is wrapped up here:
https://chirp.danplanet.com/versions/21
There are some things I'm not planning to pull into the new UI at all, and some things that can come later. So, the second call for help item is:
- Please test the new UI, help brainstorm what needs to be implemented (or fixed) before we start looking for more regular users to start using it
I've got one-off test builds here:
https://trac.chirp.danplanet.com/chirp_next/
and will continue to generate those regularly until we get to the point of doing them automatically. The new macos build is much better than it has ever been, IMHO. It feels very native and will have universal2 intel/arm support the next time I roll it. Testing the bundled builds is important for sure, but getting a development environment running is also easier. You pretty much just need a recent python3 (3.10 recommended) and:
$ pip install -r requirements.txt
...should get you there. Please file issues for things you find, and select "chirp-py3" for "target version" and "chirp version" to help keep track of bugs only in the py3 version.
I've been keeping the py3 branch in sync with changes to master for several months and even though it's doable, it's majorly not fun. I think the light is visible at the end of the tunnel at this point, so I'd really like to make 2023 the year we freeze work on the current py2 branch and get people moving to the new stuff. I'd like to be able to start getting "power users" testing the new builds early next year, which hopefully will help fill out the model testing edges.
Thoughts on the plan?
If you've got a radio on the list that needs testing, please speak up here so we at least know which ones are potentially testable.
Thanks!
--Dan
List of drivers for which there is known likely tester already:
Abbree_AR-518 iradio_uv_5118.py AnyTone_OBLTR-8R anytone_ht.py AnyTone_TERMN-8R anytone_ht.py BTECH_GMRS-V1 gmrsvu1.py BTECH_GMRS-V2 gmrsv2.py BTECH_MURS-V1 mursv1.py BTECH_UV-50X3 vgc.py BTECH_UV-5X3 uv5x3.py Baofeng_BF-T1 bf-t1.py Baofeng_UV-6R uv6r.py Explorer_QRZ-1 th_uv88.py LUITON_LT-316 retevis_rt22.py LUITON_LT-580_UHF th9000.py LUITON_LT-580_VHF th9000.py LUITON_LT-725UV lt725UV.py MTC_UV-5R-3 uv5x3.py Radioddity_GA-2S h777.py Radioddity_R2 radioddity_r2.py Retevis_H777_Plus h777.py Retevis_RB15 retevis_rb15.py Retevis_RB17P retevis_rb17p.py Retevis_RB615 retevis_rb15.py Retevis_RT1 retevis_rt1.py Retevis_RT22 retevis_rt22.py Retevis_RT22FRS retevis_rt22.py Retevis_RT23 retevis_rt23.py Retevis_RT26 retevis_rt26.py Retevis_RT6 baofeng_wp970i.py Retevis_RT622 retevis_rt22.py Retevis_RT76P retevis_rt76p.py Retevis_RT85 th_uv88.py Retevis_RT87 retevis_rt87.py Retevis_RT9000D_136-174 th9000.py Retevis_RT9000D_136-174 th9000.py Retevis_RT9000D_136-174 th9000.py Retevis_RT98 retevis_rt98.py Rugges_RH5R-V2 rh5r_v2.py TDXone_TD-Q8A tdxone_tdq8a.py TID_TD-M8 retevis_rt22.py TYT_TH-UV88 th_uv88.py TYT_TH9000_144 th9000.py TYT_TH9000_220 th9000.py TYT_TH9000_440 th9000.py WLN_KD-C1 retevis_rt22.py Wouxun_KG-UV6 wouxun.py Yaesu_FT70D ft70.py Yaesu_FTM350 ftm350.py Zastone_ZT-X6 retevis_rt22.py _______________________________________________ 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 (12)
-
Brad & Cindy Schuler -
Dan Smith -
Dave Allan -
David Ranch -
Dominick C. Pastore -
Jim Unroe -
Mark Leigh -
Matthew Poletiek -
Pavel Milanes Costa (CO7WT) -
pizzi.joe＠gmail.com -
Ran Katz -
Rick (AA0RD) DeWitt