- Users - lists.chirpmyradio.com

[chirp_users] Kenwood 2000 and WFM
by K0LNY_Glenn 30 Mar '23

30 Mar '23

Hey All, I'm working on a CSV file to import into my Kenwood 2000, and I'm putting in a few commercial radio stations, and I am wondering about the FM stations. Will the Kenwood 2000 accept the WFM in the mode column, or do I need to use just FM? Thanks.

3 2

Re: [chirp_users] chirp_users Digest, Vol 171, Issue 23
by Dave Hardy 29 Mar '23

29 Mar '23

3 2

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

28 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. As a reminder, this is different from the "daily" CHIRP builds in that new development and features are happening here. It is the latest and greatest, but also may be less stable than the "daily" builds at this time. If it works for you, we recommend using CHIRP-next, but if your radio is not yet working on it, then you may prefer to use the "daily" builds for the time being. 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 #76 [3046399+kk7ds] Add Retevis RT15 - fixes #6855 --

5 5

[chirp_users] Bug report and an introduction
by zvonimirek222＠yandex.com 28 Mar '23

28 Mar '23

Hi to all list members, I am Zvonimir stanecic from Croatia, 9a5dsz. I am using Crt mikron radio and i am trying to program mit, but i am facing the problem which is called inaccessible interface of the chirp daily. No matter the platform which i am using, Linux or Windows, i have the problem with NVDA screen reader to interact with the program controls via the keyboard. When i am arrowing with the arrow keys, screen reader doesn't read the content of the table in the memory tab, plus i cannot change settings on the settings tab of the chirp interface for the radio itself, because the interface is not accessible to the screen reader. What it should work in the case, is that all actions should be spoken by the screen reader. As i know, the accessibility adaptation can be done, because wx is used here to construct the dialog. Note that i can use the menu, plus select the radio and download from radio, plus upload to it, but for other options i need sighted assistance, which is not the option. I hope that the problem is understandable. Have a nice day, Zvonimir

1 0

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

28 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: aad8664c UV-5R read_block: read requested size from the pipe, not hardcoded 0x40 651c3800 Add Wouxun KG-UV8H support 72a65ec1 Add Wouxun KG-UV9GX --

1 0

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

28 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: 37d8b94d Fix updating repeaterbook cache on windows --

4 6

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

26 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 23 Mar '23

23 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