- Developers - lists.chirpmyradio.com

[chirp_devel] Call for help
by Dan Smith 19 Dec '22

19 Dec '22

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

12 37

[chirp_devel] Plans to get the users involved
by Dan Smith 18 Dec '22

18 Dec '22

Thanks to everyone that has tried (and/or still plans) to help test the new UI and radios under py3. The testing matrix is looking pretty decent: https://github.com/kk7ds/chirp/blob/py3/tests/Python3_Driver_Testing.md I know there are still things on there that people here have plans to test/fix, so please keep those coming. With the help of some stats, it looks like we're almost at the point at which 90% of the radios that get used regularly are in the "tested" or "probably works" category. Honestly, that's higher than I was really thinking we'd get, so that's cool. I like straight edges, right angles, and easy-to-remember dates. So, I'm thinking that first thing in January would be a good time to send out announcements to the users, looking to expand the testing to a wider audience. I think an initial blast to the chirp_users list would be good, see how that goes, and then start offering both on the download page. I also think the plan should be to effectively freeze the py2 branch for anything other than bug fixes at that point, and expect all new drivers to be against the py3 branch only. I feel like we've got some inertia now and we had better capitalize on it. At one point in the past I tried to say "new stuff has to work in py3" but I don't think we were close enough to really make that work (sorry Rick!). But now I think we've got builds, they're clearly usable, and saying that new radios will only be available in the new builds is actually reasonable. If anyone feels this is premature or not the best plan, speak up here and we can discuss. Actually, please speak up regardless, even if it's "yes, seems reasonable" or "friggin finally". There will be some bumps for sure, but I think if people can continue using the legacy builds for radios that don't yet work on the new stuff, we should be okay. I've started generating periodic builds here: https://trac.chirp.danplanet.com/chirp_next I've also started on a couple of docs on the website for "why are we doing this": https://chirp.danplanet.com/projects/chirp/wiki/ChirpNextBuild as well as explaining some differences between the old and new UI: https://chirp.danplanet.com/projects/chirp/wiki/ChirpNextBuildChanges If you have comments, edits, or suggestions on these, let me know. --Dan

8 9

[chirp_devel] Dialog quirks on Linux(es)
by Martin Cooper 15 Dec '22

15 Dec '22

I'm seeing some differences in how the Edit Memory dialog is displayed on different platforms. Since I'm not in a position to isolate the source, I thought perhaps others could chime in with what they see. On MacOS / Python 3.7.0 / wxPython 4.2.0, the dialog looks good. On Xubuntu 18.04 / Python 3.7.5 / wxPython 4.1.1, the left column is not wide enough for the labels, and the dialog is too _short_, so that it needs to be scrolled to see the last few entries. (The dialog is not resizable, but it shouldn't need to be.) On Linux Mint 20.04 / Python 3.8.10 / wxPython 4.2.0, the left column is not wide enough for the labels (as with Xubuntu, above), and the dialog is too _tall_, with quite a bit of whitespace below the entries. The issue with the label column being too narrow seems like FitColumns just not working on Linux. The height issue could be a difference between wxPython versions - or something else. Any other data points, or perhaps thoughts on how to fix the rendering? Martin. KD6YAM

4 9

[chirp_devel] py3 File Open problem
by Declan Rieb 15 Dec '22

15 Dec '22

I finally (FINALLY) figured out what my problem was with py3 on macintosh MacOSX. I must have XQuartz running (an X windows application.) Whew! It looks as if the Yaesu FT2D is at least partially working with GUI (I know it works with the CLI options.) Thanks. I’ll be trying it out RSN. I can use the menus to get to recent files (File -> Open Recent). But I’ve run into a problem when I ask to open a file (File -> Open…) An error message shows up in my console indicating > File "/Users/declan/chirp/chirp/wxui/main.py", line 814, in _menu_open > with wx.FileDialog(self, _('Open a file'), > TypeError: FileDialog(): argument 3 has unexpected type ‘PosixPath’ and no dialog box ensues. The code in question is > 806 def _menu_open(self, event): > 807 formats = [_('Chirp Image Files') + ' (*.img)|*.img', > 808 _('All Files') + ' (*.*)|*.*'] > 809 for name, pattern, readonly in directory.AUX_FORMATS: > 810 formats.insert(1, '%s %s (%s)|%s' % ( > 811 name, _('Files'), pattern, pattern)) > 812 > 813 wildcard = '|'.join(formats) > 814 with wx.FileDialog(self, _('Open a file'), > 815 chirp_platform.get_platform().get_last_dir(), > 816 wildcard=wildcard, > 817 style=wx.FD_OPEN | wx.FD_FILE_MUST_EXIST) as fd: > 818 if fd.ShowModal() == wx.ID_CANCEL: > 819 return > 820 filename = fd.GetPath() > 821 d = fd.GetDirectory() > 822 chirp_platform.get_platform().set_last_dir(d) > 823 CONF.set('last_dir', d, 'state') > 824 config._CONFIG.save() > 825 self.open_file(str(filename)) I’ve no clue where or how “PosixPath” shows up in here, so I’m supposing there’s something wrong with Python or chirp that I’ve caused to get things running. Has anybody any ideas to fix the File Open dialog on MacOS, please?

5 8

[chirp_devel] Default way to start chirp on py3 branch?
by Pavel Milanes Costa (CO7WT) 14 Dec '22

14 Dec '22

Hi, I'm trying to start chip from github on the py3 branch and I got this: ====================%<============================================ pavel@agatha:~/Documentos/Software/Github/chirp$ ./chirpw Traceback (most recent call last): File "/home/pavel/Documentos/Software/Github/chirp/./chirpw", line 42, in <module> directory.safe_import_drivers() AttributeError: module 'chirp.directory' has no attribute 'safe_import_drivers'. Did you mean: 'import_drivers'? pavel@agatha:~/Documentos/Software/Github/chirp$ ====================%<============================================ If I change it to import_drivers it will pop up but crash on "read from radio" I'm missing something or that branch it's a wild moving target?, I'm tying to test the Feidaxin radios now.

2 4

Re: [chirp_devel] Call for help
by Tony Fuller 13 Dec '22

13 Dec '22

I have a Radioddity GA-2S and a Baofeng 777 (with the older firmware) on it that I can test out this Monday. Tony

3 3

Re: [chirp_devel] chirp_devel Digest, Vol 140, Issue 7
by Mel Terechenok 10 Dec '22

10 Dec '22

I can test the Wouxun KG-935G. mrtjr1 Mel On Sat, Dec 10, 2022, 3:00 PM <chirp_devel-request(a)intrepid.danplanet.com> wrote: > Send chirp_devel mailing list submissions to > chirp_devel(a)intrepid.danplanet.com > > To subscribe or unsubscribe via the World Wide Web, visit > http://intrepid.danplanet.com/mailman/listinfo/chirp_devel > or, via email, send a message with subject or body 'help' to > chirp_devel-request(a)intrepid.danplanet.com > > You can reach the person managing the list at > chirp_devel-owner(a)intrepid.danplanet.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of chirp_devel digest..." > > > Today's Topics: > > 1. Re: Call for help (Matthew Poletiek) > 2. Re: Call for help (Dan Smith) > 3. Re: Call for help (Dave Allan) > 4. Re: Call for help (Dan Smith) > 5. Re: Call for help (Ran Katz) > 6. Re: Call for help (Pavel Milanes Costa (CO7WT)) > 7. Re: Call for help (Jim Unroe) > 8. Re: Call for help (Pavel Milanes Costa (CO7WT)) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 9 Dec 2022 16:09:03 -0600 > From: Matthew Poletiek <matthew.poletiek(a)gmail.com> > Subject: Re: [chirp_devel] Call for help > To: Jim Unroe <rock.unroe(a)gmail.com> > Cc: chirp devel <chirp_devel(a)intrepid.danplanet.com> > Message-ID: > < > CAJhSV8vzDCYE-xBJJAx27UuuN6_+p1ayabtrcd2xaqeyEe9KhA(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Awesome! Disregard then! > > On Fri, Dec 9, 2022, 11:17 Jim Unroe <rock.unroe(a)gmail.com> wrote: > > > Hi Matthew, > > > > On Fri, Dec 9, 2022 at 11:10 AM Matthew Poletiek via chirp_devel > > <chirp_devel(a)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 > > >

1 0

[chirp_devel] #7223 Patch
by Mel Terechenok 08 Dec '22

08 Dec '22

Add Support for Wouxun KG-UV980P and KG1000G Removed Alias

1 0

[chirp_devel] Wouxun KG-UV980P driver addition - # 7223
by Mel Terechenok 08 Dec '22

08 Dec '22

The image file is attached to New Model Request 7223

1 0

[chirp_devel] [PATCH] [GMRS-V2] DTMF Settings aren't being stored in radio
by Jim Unroe 06 Dec '22

06 Dec '22

1 0