- Developers - lists.chirpmyradio.com

[chirp_devel] Naming convention for class fields?
by Craig Jones 16 May '23

16 May '23

I'm looking over the yaesu_clone superclass with FT1D subclass as a suggested example. I'm confused by the conflicting naming conventions. In yaesu_clone.py line 231 the superclass begins with these class fields: VENDOR="Yaesu" NEEDS_COMPAT_SERIAL=False _model =b"ABCDE" Why are the first two all caps, but the third is lowercase with a leading underscore? Is this documented somewhere that I missed? Normally, a leading underscore means the variable is local to the current scope and shouldn't be accessed outside of it. But in this case, VENDOR and _model are both overridden in the subclass. I didn't think that a subclass still counts as local. Also, normally all caps means it's a constant. Yet, again, the VENDOR gets overridden. So, to my mind all of these variables should be lowercase with no leading underscore. Just "vendor", just "model". (Or, leading underscores with corresponding @property accessors.) (signed) Confused in Las Vegas 😮 -- This email has been checked for viruses by AVG antivirus software. www.avg.com

3 4

[chirp_devel] Yaesu FT1DR, multiple comments and questions
by Declan Rieb 16 May '23

16 May '23

Hello CHIRP experts. Thanks for reading, and especially for responding to my questions in bold. 1. I’ve just found that CHIRP-next and CHIRP-source both break when I try to look at the settings data for a radio that’s new (ahem… not quite: when I use a default .ft1d file written by Yaesu’s ADMS software.) The root cause is that no data have (ever yet) been placed into the APRS section, and CHIRP effectively burps on a Null link. I’ve fixed that, I think. I also simplified some of the inheritance “differences”… The FT1, FT2 and FT3 all have 900 memories, and 99 Skip-memories and 100 PMS-memories, so changing the ft1d.py to at least define them (even if not quite handled!) seemed like a no-brainer. Question 1: How to put this branch into the regular tree? Will I need to submit an error report (issue) so I can get a case number and email you the diff file with an appropriately-referenced datum? Or, since things are still being wholesale-changed, should I just push it on up? (I’m loath to do that because y’all are very good at spotting stupid programmer errors and I’m no Python expert.) All of my other changes below will be sequential branches from this one. 2. The GM/WWIRES-X support from the ft70.py is almost drop-in compatible, so I’ve a (separate) ft1d.py that at least displays those data in a settings tab. (I’ve not tried setting them yet; most are pull-down menus.) There is more work desired to enter to support the digital rooms and categories (Yaesu’s ADMS handles those, so I think CHIRP should as well.) This work supports Feature #6151 3. I’ve yet another ft1d.py branch that handles the 99 skip-memories, 100 PMS-memories and 11 Home memories as ‘specials’. So far, they seem to be displaying correctly (yay!) This looks like the same issue as Bug #3951 but for Yaesu FT-1D, FT2D, FT-3D. - One downside for now is that there are ~1200 lines in the CHIRP output page. At least for testing purposes, most are empty, and so a LOT of scrolling is required. Is there any way to have CHIRP [optionally] display only one blank line in a row (skipping others) or to go back to the toggles for “show blanks” and “show specials”?? I can imagine having the UI become sensitive to a radio-specific parameter (e.g. rf.display_blank_lines and rf.display_specials, both set True by default but selectable by the driver and/or in the UI) I can imagine having memory output look like the following for an FT1 (Home frequencies are always set; Specials show at least first and maybe last line, even if blank) 1 freq … 2 freq … 3 (blank line) 10 freq … 11 (blank line) 900 (blank line) S1 freq … S2 (blank line) S99 (blank line) L1 (blank line) U50 (blank line) H1 0.65 H2 … H11 … Question 3a: Can I (optionally) have CHIRP hide some blank lines? - It seems that specials have an execution path that I didn’t expect. When I try to SET a regular memory, my present debug shows ‘set_memory’ is called and works fine. I’ve modified it to handle the special memories, similar to changes in ‘get_memory.’ But when I try to change a special memory, my driver's ‘set_memory’ routine isn’t called at all. Instead, I run into an error (I was able to get debug file from CHIRP_next after loading my driver module; that is attached. I had loaded an ADMS file and touched the settings button, then tried to change Skip901 special memory.) Traceback (most recent call last): File "/Users/declan/chirp/chirp/wxui/common.py", line 452, in run_safe return fn(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^ File "/Users/declan/chirp/chirp/wxui/memedit.py", line 1038, in _memory_edited self._radio.validate_memory(mem)) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/Users/declan/chirp/chirp/chirp_common.py", line 1227, in validate_memory return rf.validate_memory(mem) ^^^^^^^^^^^^^^^^^^^^^^^ File "/Users/declan/chirp/chirp/chirp_common.py", line 976, in validate_memory (mem.number < lo or mem.number > hi) and \ ^^^^^^^^^^^^^^^ TypeError: '<' not supported between instances of 'str' and ‘int' Now AFAICT, the ‘mem.number' that my driver gets can be either an integer (1-900 in FT1D case) or an appropriate string for the specials (e.g.’Home1’). Those names came from my specials list used to set ‘rf.valid_special_chans’ … I don’t think I ever set mem.number, but it seems as if CHIRP is using the names from my specials list (I can’t quite tell… I never put debugs into the memedit.py or chirp_common.py.) I don’t explicitly use ‘extd_number’ anywhere in my drivers. Question 3b: HOW do I correctly allow CHIRP to modify a special memory? ______ Declan Rieb WD5EQY wd5eqy(a)arrl.net

1 0

[chirp_devel] Fwd: Yaesu FTM6000 support - not yet. Perhaps I can help?
by Stephen Hersey 16 May '23

16 May '23

(Originally posted this on chirp_users, but chirp_devel seems more appropriate...) I've used Chirp for my HTs now for many years (thanks, developers!), and recently bought a Yaesu FTM6000 dual-band mobile. Its primary deficiency from my point of view is that it isn't supported by Chirp, for which reason I bought a third-party programming program and serial cable made by RT Systems. I'm not a fan of their business model of "Spend another $60 for a different (but actually near-identical) programming utility for every one of your different radios," so I view this as a one-time thing, and a way to give back by achieving Chirp support for this model. I would be delighted to use this equipment and my embedded hardware/software development skills to bring about Chirp support for this radio, but I would need some help from someone familiar with Chirp internals. In particular, my Python skills are rudimentary; I can write Python, but it's not my best language. Implementing this support on my own seems rather daunting. Here's what I can do well: - Run test cases for reading/writing configurations from and to the radio with the third-party software - Intercept the serial data streams at either the USB driver level or the RS-232 serial link level (it's my understanding that this radio does indeed use RS-232 levels and async serial communications). Wireshark and logic analyzers are my friends! - Analyze the serial data streams for this radio and compare them to samples of known Yaesu programming protocols for other models (I believe they tend to re-use the same protocol for many models) - Compile and run test builds of a modified Chirp build from a Git repo and test them Here's what I would need help with: - Someone familiar with Python, the Chirp drivers, and ideally Yaesu's programming protocols, to work on the Python code to adapt an existing Chirp driver for the FTM6000. Is there someone on the list who would be interested in working with me on adding support for this radio to Chirp? Regards, Steve Hersey -- Steve Hersey N1XNX n1xnxham(a)gmail.com ----- "Any sufficiently advanced technology is indistinguishable from magic." -- Clarke's Third Law "Any technology distinguishable from magic is insufficiently advanced." -- Benford's Corollary "Any sufficiently advanced magic is indistinguishable from technology." -- Charles Stross, *Dead Lies Dreaming* “It's still magic even if you know how it's done.” -- Terry Pratchett

1 0

[chirp_devel] Before I commit my improvements to anytone.py (wrt Powerwerx DB-750X)
by Craig Jones 15 May '23

15 May '23

(I'm finally getting back to this issue I started working on last year.) First of all, who on this list has an *AnyTone 5888UV*, a *Polmar DB-50M*, or a *Intek HR-2040*? The *anytone.py* driver currently claims to support 4 radios (the 3 above, plus the *PowerWerx DB-750X*, which is what I have). I have found a half dozen discrepancies between my actual images and what the driver specifies -- differences in locations and/or field sizes within the image map. For the moment, I copied anytone.py as powerwerx_db750x.py and made the necessary changes. I also *added bank support* *plus a number of settings options *(programming lockout, RBG colors, etc.) while I was at it. That is all working for me. My question is, how I should proceed to commit my work? I see a number of options, here: 1. Add my powerwerx_db750x.py to the drivers and remove the DB-750X registration from anytone.py. I'd include copious comments in both files pointing to each other. 2. Merge my changes back into anytone.py, and work out the logic to make my changes conditional between the models. 3. Do #1 first, but plan on getting to #2 soon. Since I don't have access to the 3 other radios, *I can't personally test that my changes are benign *for them. So, adding powerwerx_db750x.py as a separate driver is the safest route. But that would unnecessarily duplicate 700 lines of code. Also, it would be a shame if the new features I added (banks, settings) would be useful for those other models but only appeared in the DB-750X driver. Please advise. P.S. I'm curious. Does Chirp send back usage telemetry? Do we know if anyone is even using Chirp with those other radio models anymore? NOTE: The biggest discrepancy, BTW, is that the flags map changed from 4 bits per channel to 8, to accommodate a bank assignment 0-10 (A-J). -- This email has been checked for viruses by AVG antivirus software. www.avg.com

2 1

[chirp_devel] tox
by Bernhard Hailer 21 Feb '23

21 Feb '23

Hi all, in the Mercurial days, we used tox to check for code problems in Chirp. Is this still something we do? Thanks, Bernhard

3 7

[chirp_devel] Icom IC-9700
by Mike Markowski 12 Feb '23

12 Feb '23

Is anyone working on adding the IC-9700 to Chirp? I've never added a rig to Chirp but would enjoy learning to (just read the 'How to add a new radio driver' page). I spend my workdays in an RF lab writing python and hopefully there will be plenty of overlap. Tnx es 73! Mike ab3ap

2 2

[chirp_devel] Invalid version: 'py3dev' breaks build.
by Barry Jackson 31 Jan '23

31 Jan '23

Hi Dan, Since our (Mageia) most recent python3 updates sometime this month chirp-next builds fail with: packaging.version.InvalidVersion: Invalid version: 'py3dev' The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/usr/lib/rpm/pythondistdeps.py", line 626, in <module> raise RuntimeError("Error: pythondistdeps.py generator encountered an unhandled exception and was terminated.") from exc RuntimeError: Error: pythondistdeps.py generator encountered an unhandled exception and was terminated. error: Dependency tokens must begin with alpha-numeric, '_' or '/': *** PYTHONDISTDEPS_GENERATORS_FAILED *** Provides: application() application(chirp.desktop) chirp = 1:0.4.0-0.20230101.1.mga Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PartialHardlinkSets) <= 4.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 Requires: python(abi) = 3.10 python3.10dist(future) python3.10dist(pyserial) python3.10dist(requests) python3.10dist(six) python3.10dist(yattag) /-------------------------------------- For now I have used: sed -i 's/py3dev/%{version}/' chirp/__init__.py .. in our spec. to fix the above issue for our package. Since you do not make releases it's difficult to decide on any sort of versioning that makes sense for our packages. I use 0.4.0 as version and add the date from git into the release, which keeps our packages in order but means little outside of the distro. e.g. chirp-0.4.0-0.20230125.2 I really wish you actually made releases. /OT Today's package works fine with my test radio. (UV5RE) :) Cheers, Barry

5 12

[chirp_devel] Missing svg from release tarball/whl
by Tony Fuller 30 Jan '23

30 Jan '23

Hey Dan, I'm working on the snapcraft build script again, and I need a small bit of help on thi In the git repository, there's a chirp.svg file that makes the snap icon look great (the png file does not look so good on Ubuntu's application menu) but it appears that neither the release tarballs or the whl files contain the SVG file in the share directory -- just an ICO and a PNG. Would you be able to add this to the tarball and/or whl releases? Thanks, Tony

3 2

Re: [chirp_devel] chirp_devel Digest, Vol 141, Issue 10
by Mel Terechenok 22 Jan '23

22 Jan '23

Read and write is what Wouxun CPS uses.... but at least adding "To radio " or "From Radio" would help clarify direction of transfer for those less radio/computer literate. As upload and download are dependent on your perspective. On Sat, Jan 21, 2023, 3:02 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. Thoughts on upload/download terminology (Dan Smith) > 2. Re: Thoughts on upload/download terminology (Matthew Poletiek) > 3. Re: Thoughts on upload/download terminology (David Boucha) > 4. Re: Thoughts on upload/download terminology (Dan Smith) > 5. Re: Thoughts on upload/download terminology (Jim Unroe) > 6. Re: Thoughts on upload/download terminology (Dan Smith) > 7. Re: Thoughts on upload/download terminology (Martin Cooper) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 20 Jan 2023 15:34:14 -0800 > From: Dan Smith <dsmith(a)danplanet.com> > Subject: [chirp_devel] Thoughts on upload/download terminology > To: chirp devel <chirp_devel(a)intrepid.danplanet.com> > Message-ID: <021DF205-CBA7-4BE1-AC1B-F41499FEACB2(a)danplanet.com> > Content-Type: text/plain; charset=us-ascii > > Hi all, > > Someone just filed a bug about the fact that CHIRP-next uses only "upload" > and "download" in the Radio menu. This wasn't intentional, but is a > departure from what it used to be, which is "Upload TO radio" and "Download > FROM radio". Changing that completely now *might* catch some users > off-guard, but I think he's probably right that the single-word options are > too vague. > > Any strong opinions on moving from upload/download (to/from radio), to > "Read from Radio" and "Write to Radio"? Even "Read" and "Write" might be > okay, given they're under the "Radio" menu. > > https://chirp.danplanet.com/issues/10303?next_issue_id=10301 > > I initially knee-jerked in my usual hates-change way to moving to > read/write but perhaps that would be better, and does (I think) match other > software. > > --Dan > > ------------------------------ > > Message: 2 > Date: Fri, 20 Jan 2023 18:22:35 -0600 > From: Matthew Poletiek <matthew.poletiek(a)gmail.com> > Subject: Re: [chirp_devel] Thoughts on upload/download terminology > To: Dan Smith <dsmith(a)danplanet.com>, chirp devel > <chirp_devel(a)intrepid.danplanet.com> > Message-ID: > < > CAJhSV8uTqcoAk6+HDMA5P789t2mw547CETRiqSHSdot6ze6wcQ(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Probably thinking about it too hard myself, but here are some thoughts. > > Upload and download infer a temporary, potentially unstable connection or a > remote/temporary target. > > Read and write infer something less remote and much more stable and > consistent. > > I think upload and download make the most sense for this use case > considering protocols in use and the temporary connection or potentially > unstable one. > > Read and write might set expectations too high for some users. > > 2cents. > > On Fri, Jan 20, 2023, 17:34 Dan Smith via chirp_devel < > chirp_devel(a)intrepid.danplanet.com> wrote: > > > Hi all, > > > > Someone just filed a bug about the fact that CHIRP-next uses only > "upload" > > and "download" in the Radio menu. This wasn't intentional, but is a > > departure from what it used to be, which is "Upload TO radio" and > "Download > > FROM radio". Changing that completely now *might* catch some users > > off-guard, but I think he's probably right that the single-word options > are > > too vague. > > > > Any strong opinions on moving from upload/download (to/from radio), to > > "Read from Radio" and "Write to Radio"? Even "Read" and "Write" might be > > okay, given they're under the "Radio" menu. > > > > https://chirp.danplanet.com/issues/10303?next_issue_id=10301 > > > > I initially knee-jerked in my usual hates-change way to moving to > > read/write but perhaps that would be better, and does (I think) match > other > > software. > > > > --Dan > > _______________________________________________ > > chirp_devel mailing list > > chirp_devel(a)intrepid.danplanet.com > > http://intrepid.danplanet.com/mailman/listinfo/chirp_devel > > Developer docs: > http://chirp.danplanet.com/projects/chirp/wiki/Developers > > >

2 1

[chirp_devel] Thoughts on upload/download terminology
by Dan Smith 21 Jan '23

21 Jan '23

Hi all, Someone just filed a bug about the fact that CHIRP-next uses only "upload" and "download" in the Radio menu. This wasn't intentional, but is a departure from what it used to be, which is "Upload TO radio" and "Download FROM radio". Changing that completely now *might* catch some users off-guard, but I think he's probably right that the single-word options are too vague. Any strong opinions on moving from upload/download (to/from radio), to "Read from Radio" and "Write to Radio"? Even "Read" and "Write" might be okay, given they're under the "Radio" menu. https://chirp.danplanet.com/issues/10303?next_issue_id=10301 I initially knee-jerked in my usual hates-change way to moving to read/write but perhaps that would be better, and does (I think) match other software. --Dan

7 8