March 2023 - Users - lists.chirpmyradio.com

[chirp_users] KG-UV9D Mate issues, debug, and proposed change
by Jonathan Johnson 25 Mar '23

25 Mar '23

Hi, first off I want to say thank you for this excellent software! I'd like to report some issues with the KG-UV9D Mate support. I have debugged some channel memory loading issues and would like to report my findings and suggested changes. I can report what works for my scenario but of course you may have more information about previously reported issues with this radio so my proposed changes are only suggestions on how to deal with the issues. My testing and debug has all been done with CHIRP-next from github.com/kk7ds/chirp, commit 60f989ccb337ad4a36a24bcc964948ae453c47cf and using the "KG-UV9D Plus" driver as recommended on a table I found on the website. There are 2 separate but related issues I've seen while using CHIRP-next. Issue #1: There are some valid channels in my radio that CHIRP doesn't see as valid. Example channels shown below that should be valid but aren't interpreted as valid by CHIRP: 1, 3, 4 The "valid" or "state" information for each of those channels is found in the second to last column of rows 1, 3, and 4 of the following: DEBUG: Config read (0xa00): 0x0a00: 00 dd d1 28 00 dc e6 c8 04 0b 04 0b 03 d0 01 00 ...(............ 0x0a10: 02 a6 71 a4 02 ae 12 c4 03 e8 03 e8 03 d0 02 00 ..q............. 0x0a30: 02 a1 d4 00 02 a9 75 20 03 e8 03 e8 03 d0 01 00 ......u ........ 0x0a60: 02 a1 63 b2 02 a9 04 d2 04 30 04 30 03 d0 80 00 ..c......0.0.... In other words, this dump shows that "state" values of 0x01 and 0x80 can be considered valid. In chirp/drivers/kguv9dplus.py I see the following related code starting at line 1423: if (_valid != MEM_VALID and _valid != 0 and _valid != 2 and _valid != 0x40): # In Issue #6995 we can find _valid values of 0 and 2 in the IMG # so these values should be treated like MEM_VALID. # state value of 0x40 found in deleted memory - still shows in CPS mem.empty = True return mem For context, MEM_VALID and MEM_INVALID definitions are: MEM_VALID = 0xfc MEM_INVALID = 0xff So it seems that CHIRP already has some exceptions to the idea that only a "state" value of 0xFC means a valid memory channel. Values 0, 2, and 0x40 were previously made exceptions and counted as valid memory channels. My memory dump shows that 0x1 and 0x80 should also be added to that list. Issue #2: I also encountered what is essentially the opposite problem. In my radio I don't have any valid channels after channel 314. However, CHIRP is interpreting the download from the radio as having channels 998 and 999 valid. This results in errors because the rest of the data for those channels is invalid. Channels 998 and 999 correspond to rows 2 and 3 of the below output (again, the "state" byte is the second to last column): DEBUG: Config read (0x4840): 0x4840: ff ff ff ff ff ff ff ff ff ff ff ff ff fd ff ff ................ 0x4850: ff ff ff ff ff ff ff ff 00 00 00 00 0f 5d 00 00 .............].. 0x4870: ff ff ff ff ff ff ff ff 00 00 00 00 0f 5d 00 00 .............].. 0x48a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ So now we have an example of "state" value of 0 being used for an invalid channel memory. This is in contradiction to the existing code shown above that makes "state" value of 0 be interpreted as a valid channel. What I would propose here is that the exception for "state" values of 0, 2, 0x40 (and now 0x1 and 0x80) only be applied if the receive frequency is valid (i.e. not 0xFFFFFFFF) and the channel memory name is not blank. There is precedent for something very similar in some existing code at line 1417 of the same file: # Override Mem Valid state to handle quirky 9PX CPS New codeplug # issue where there is a channel programmed but the CPS # "state" value is 0xFF indicating an invalid memory if _valid == MEM_INVALID and _mem.rxfreq != 0xFFFFFFFF and _nam != '': _valid = MEM_VALID So my overall patch to fix both issues (at least for my particular memory dump) is as follows: diff --git a/chirp/drivers/kguv9dplus.py b/chirp/drivers/kguv9dplus.py index cc0f3df8..77df32e0 100644 --- a/chirp/drivers/kguv9dplus.py +++ b/chirp/drivers/kguv9dplus.py @@ -1420,8 +1420,7 @@ class KGUV9DPlusRadio(chirp_common.CloneModeRadio, if _valid == MEM_INVALID and _mem.rxfreq != 0xFFFFFFFF and _nam != '': _valid = MEM_VALID - if (_valid != MEM_VALID and _valid != 0 and _valid != 2 and - _valid != 0x40): + if (_valid != MEM_VALID and not (_valid in [0, 2, 0x40, 0x3, 0x1, 0x80] and _mem.rxfreq != 0xFFFFFFFF and _nam != '')): # In Issue #6995 we can find _valid values of 0 and 2 in the IMG # so these values should be treated like MEM_VALID. # state value of 0x40 found in deleted memory - still shows in CPS Again, thank you for your efforts developing this software and I hope this report is useful. Jonathan KI5RRE

2 1

[chirp_users] Chirp On Puppy Linux
by John KB2SCS 25 Mar '23

25 Mar '23

Hi All To run the python 2 version of chirp I would download the .tar.gz file and extract it to a directory. I would then open a terminal window in that directory. Then run Chirp with the following command Python Chirpw.py I am trying to run the python 3 version of chirp using the same method. My first problem is there is not any chirps.py file to run so I have no idea which file is the one I should run. My question is how do I run the latest version of chirp running the source code? Thank you all for your time in reading this email. Best regards John

4 3

[chirp_users] Default factory images server…
by Jerry Kuhn 25 Mar '23

25 Mar '23

Hello, Many years back, I remember there being a massive FTP server that had the motherload of default chirp images for many radios, mainly Baofeng/BTech, but other brands as well. The images were cleanly and carefully catalogued not only by brand and model, but by firmware versions. While I don’t need any of them at the moment, I was hoping to relocate this sever and just download (clone) the entire site. While I always do first download from new radios and save their default image, over time my files have become less organized, plus I had a recent drive failure. I’m looking to just make an entirely new index of default factory images and store them in several locations (including clouds). I just started putting a new archive together with what I still have, but if this site still exists it would make for a much easier starting point. Anyone remember the location of this server (if it stop exists)? I can’t find any old bookmarks for it on my systems. Thanks! Sent from my iPhone 13 Pro Max

4 5

[chirp_users] Chirp-Next updates?
by Jerry Rector - K4OAM 22 Mar '23

22 Mar '23

It seems I am stuck at version 3.17 despite running: *sudo snap refresh chirp-snap* I always receive the reply: *snap "chirp-snap" has no updates available* What am I doing wrong? *Jerry - K4OAM*

3 5

[chirp_users] Installing Chirp on Linux (Debian based in this case.)
by Dave B 22 Mar '23

22 Mar '23

FYI. The info at :- https://chirp.danplanet.com/projects/chirp/wiki/ChirpOnLinux Is in error regarding adding a user to a group on Debian based systems. The example terminal command under "Serial port permissions" should be.... *$ sudo adduser $USER dialout* Note: Just $USER and no quotes! The system of couse, will ask for the users password. And then as said, Logout and Log back in again for it to take effect. This has been checked on Linux Mint, a derivative of Ubuntu, from Debian of course. 73. Dave G8KBV. On 18/03/2023 19:00, chirp_users-request(a)intrepid.danplanet.com wrote: > Send chirp_users mailing list submissions to > chirp_users(a)intrepid.danplanet.com > > To subscribe or unsubscribe via the World Wide Web, visit > http://intrepid.danplanet.com/mailman/listinfo/chirp_users > or, via email, send a message with subject or body 'help' to > chirp_users-request(a)intrepid.danplanet.com > > You can reach the person managing the list at > chirp_users-owner(a)intrepid.danplanet.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of chirp_users digest..." > > > Today's Topics: > > 1. Chirp On Puppy Linux (John KB2SCS) > 2. Re: Chirp On Puppy Linux (Jim Unroe) > 3. Re: Chirp On Puppy Linux (Jeffrey Vian) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 17 Mar 2023 17:04:33 -0400 > From: John KB2SCS<kb2scsjb(a)gmail.com> > Subject: [chirp_users] Chirp On Puppy Linux > To: Chirp<chirp_users(a)intrepid.danplanet.com> > Message-ID: > <CAHBPgZGTs-6gr6yoSzeftMoKji6=449b69WkuVGh2sRvrnoaWA(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi All > To run the python 2 version of chirp I would download the .tar.gz > file and extract it to a directory. > I would then open a terminal window in that directory. Then run Chirp with > the following command > Python Chirpw.py > > I am trying to run the python 3 version of chirp using the same method. > My first problem is there is not any chirps.py file to run so I have no > idea which file is the one I should run. > > My question is how do I run the latest version of chirp running the source > code? > > Thank you all for your time in reading this email. > > Best regards > John >

2 1

[chirp_users] Chirp-Snap updates on Raspberry Pi?
by Jerry Rector - K4OAM 22 Mar '23

22 Mar '23

It seems I am stuck at version 3.17 despite running: *sudo snap refresh chirp-snap* I always receive the reply: *snap "chirp-snap" has no updates available* What am I doing wrong? Jerry - K4OAM

2 4

[chirp_users] New chirp-next build
by donotreply＠chirp.danplanet.com 22 Mar '23

22 Mar '23

Greetings, A new build of CHIRP-next is available. This includes changes made directly to the tree since yesterday and may include additional features, bug fixes, etc. Unless you have a reason not to, we recommend using the latest build of CHIRP-next at all times. You can get it from here: http://trac.chirp.danplanet.com/chirp_next/ A list of changes since the last build are here: Changes for Build #93 [3046399+kk7ds] Correct Raw Memory Index [3046399+kk7ds] Fix Power setting for factory CPS [3046399+kk7ds] Install desktop icon on linux [3046399+kk7ds] Fix including locale files in setup-based builds [3046399+kk7ds] Squelch warnings about "Windows bitmap file" Changes for Build #94 No changes --

1 0

[chirp_users] New chirp-next build
by donotreply＠chirp.danplanet.com 21 Mar '23

21 Mar '23

Greetings, A new build of CHIRP-next is available. This includes changes made directly to the tree since yesterday and may include additional features, bug fixes, etc. Unless you have a reason not to, we recommend using the latest build of CHIRP-next at all times. You can get it from here: http://trac.chirp.danplanet.com/chirp_next/ A list of changes since the last build are here: Changes for Build #92 [3046399+kk7ds] Update KG-UV9PX manual channel entry [3046399+kk7ds] Clean Up Wouxun 9 series mem valid checks [3046399+kk7ds] Rename Signus to Cignus for XTR-5 --

1 0

[chirp_users] FT-710?
by Shon Edwards 19 Mar '23

19 Mar '23

Does anyone know if s/w and cable exist for the Yaesu FT-710 AESS? Thx & 73 de Shon, K6QT Shon R. Edwards 1039 N 2575 W Layton, UT, 84041-7709 USA Home phone: +1 (801) 444-3445 Cell phone: +1 (208) 406-0444 E-mail: sre.1966(a)gmail.com or k6qt(a)arrl.net FCC Call: K6QT

2 2

[chirp_users] New chirp-next build
by donotreply＠chirp.danplanet.com 19 Mar '23

19 Mar '23

Greetings, A new build of CHIRP-next is available. This includes changes made directly to the tree since yesterday and may include additional features, bug fixes, etc. Unless you have a reason not to, we recommend using the latest build of CHIRP-next at all times. You can get it from here: http://trac.chirp.danplanet.com/chirp_next/ A list of changes since the last build are here: Changes for Build #91 [3046399+kk7ds] Fix editing entries for TH-D74 [3046399+kk7ds] Fix drivers with special-included memory bounds [3046399+kk7ds] Fix offset problem on Asia version FT-25R/65R [3046399+kk7ds] Convert ft4.py to stricter style standard [3046399+kk7ds] New driver UV68 and TDH8 [3046399+kk7ds] Update tdh8 to stricter style standard [3046399+kk7ds] Add py3 test matrix entries for new ga510 models [3046399+kk7ds] Remove "Language" option from SHX8800 family [3046399+kk7ds] Add Ruyage UV58Plus - fixes #10334 --

1 0