- Developers - lists.chirpmyradio.com

[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

[chirp_devel] Yaesu memories
by Declan Rieb 18 Jan '23

18 Jan '23

> > So, I think the way to handle this is to expose these memories as "special channels" with everything marked as immutable. If they're not actually in the memory image, we'll just need to store all that data in the ft1d.py file, and return them as memories when requested. Then we can expose those in the memory editor, but they will be un-editable if everything is immutable. That way they can show up in the bank editor (more work may be required here) and then we can reflect those mappings and allow them to be changed. > > Does that sound like a plan? Yes, that sounds quite plausible; I had even experimented with something similar in an earlier toy version. But i had the wrong idea, thinking they were memories and not bank entries. Thanks for the thought you put into this to help me avoid playing with my own mental blocks! How does CHIRP-next GUI handle specials? The old GUI had a way to hide and show specials; Yaesu has some 150 pre-defined addresses! With the thousand memory locations already in the radio, that’s a lot of scrolling (especially since we also cannot hide undefined memory locations now.)

2 1

[chirp_devel] Was: Yaesu question(s)
by Declan Rieb 17 Jan '23

17 Jan '23

Thanks for the replies. Yes, I have a Yaesu FT2D. I’ll try looking at your suggested radios for guidance on the digital-mode settings. I’ll also try to better check the DN and FM settings on the real radio. The FT1 is substantially similar based upon the preexisting FT-1 driver and Yaesu’s manual; FT2D inherits almost everything from FT1. (That looks to be true for the FT-3 as well.) To get CHIRP working on FT-2D, I also made substantial changes to FT-1 driver because they’re so similar I often only needed to tweak the FT-1 to enable any newer stuff. IIRC, most changes were in character representation. I believe the Yaesu FTM3200 also uses the FT-1D driver. You’ve asked some questions whose answers are getting me to suss out some flaws in my understanding of how the FT-numeral series works. There is (in the radio somewhere, but not apparently in CHIRP-accessible memory) non-variable memory describing SW broadcast, WX, and VHF Marine (NOT GMRS as I’d said before.) They’re called “preset receiver memory channels” in the manual. The channels may be registered into a MEMORY BANK (not into the actual volatile memories, AFAICT) and that information used in the A receiver [FT2DR Instruction Manual (APRS Version), p 69 or <https://www.yaesu.com/downloadFile.cfm?FileID=8930&FileCatID=151&FileName=F…> ] A memory bank channel datum includes an index into the actual memories; high-order bits are used to flag that the data should come from any of the preset receiver memory channels. A memory entry CAN be defined to use, say a WX frequency and modulation mode without any reference to the “preset receiver memory channels”; the radio should automagically prevent transmission, but receiver will work. During bank operations, the FT-1D driver uses the memory BANK channel data to index into the CHIRP memory. IF a user has placed a preset into a bank memory, then CHIRP used to use the BANK channel index WITH its flag bits set, which is an address way too large for CHIRP to handle; chirp will abort trying to read or write to that address. To “correct” that behavior (yes, I had submitted a ticket, but that was long ago) I had ANDed out the flags sections, and included a LOG. warn message indicating that CHIRP doesn’t handle this case correctly. See, e.g., ft1d.py line 503 et seq. _update_bank_with_channel_numbers [I got the source file from a git pull just now; there were no changes to ft1d.py] Yaesu Memory banks (there are 24) can each contain 100 entries, which are pointers to either the FT1D memory locations or to the “preset receiver memory channels”, depending upon the flag bits. But memory entries need not be registered into any banks AFAICT, nor should CHIRP memory entries be accessed during the processing of presets. I would like to have CHIRP understand, display and set these bank channels to the preset receiver memory channels. It makes sense to have some of these presets usable in a memory bank for use in a special location (repeaters, weather and VHF for scanning, e.g…. indeed that was the use case prompting the ticket submission; the user had manually entered the preset into a bank set up for camping.) CHIRP’s a fine tool for that, and your easy access to the GMRS/FRS data seems to indicate similar considerations. I think that if I “simply” predefine the data needed, I can fix BANK processing to point to the appropriate “preset receiver memory channels” and avoid memory processing in CHIRP. I’ll have to imagine some way to display a preset memory entry, and to select one if it’s desired. I will have to think about this. I fear refactoring the ft1d.py may break some things, and I only have an FT2D, so won’t be able to check everything. So: no decisions yet, bu I’ve got some studying to do! ______ Declan Rieb WD5EQY wd5eqy(a)arrl.net

2 1

[chirp_devel] Yaesu question: Digital mode
by Declan Rieb 15 Jan '23

15 Jan '23

Thanks for finding and putting in the “DN” mode. Interestingly, on the FT-2D, the “automatic” mode is displayed as DN or FM with a line over the characters, meaning that the radio will default to trying the letter-configured mode but will automagically convert itself to the opposite one if appropriate. (It doesn’t always revert back to that automatic mode after changing itself, AFAICT.) The Yaesu FT-1 and successors are able to handle YSF and Wires-X digital data in the DN or bar-above-FM mode. I have mapped much of the memory space for configuring these (sub?) modes, and even tried to create a settings capability via the old TK GUI interface. Although I doubt there is a burning need for this, wouldn’t it be nice to be able to at least access the settings? Is there any walkthrough to help one use drive the CHIRP data model and GUI to display and configure top-level as well as hierarchical settings? Clearly, Somebody already has done that for the APRS data. and I tried using that as a model, but there’s no easy hierarchy in there. If it looks to be not-useless to others, I may submit a ticket for this and a proposed but incomplete solution. ______ Declan Rieb WD5EQY wd5eqy(a)arrl.net

2 1