December 2020 - Developers - lists.chirpmyradio.com

[chirp_devel] chirp-py3 status?
by Matthew Poletiek 09 Dec '20

09 Dec '20

Hi Everyone, Anyone know what the current status of the py3 branch is? Gentoo Linux has dropped this package from it's main repo due to lack of movement, but I cloned this branch, made a few adjustments ( https://chirp.danplanet.com/issues/8475) and everything seemed to work great! I'm assuming it's a few driver iterations behind the main branch, but it would be really nice to get py3 moving since Python2 is practically EOL'ed. If it helps others test a bit easier I created a fork of the py3 branch with my patch already applied on github. https://github.com/mpoletiek/py3-CHIRP The documentation on how to contribute to the main project using Mercurial was a bit out of date and went against recommendations being made to me in the #mercurial IRC channel on Freenode. I figured moving this to github might help get the ball moving again as more and more developers prefer git and aren't very interested in anything else. I was planning on testing this in a few different linux environments and windows 10 before New Years. I'll definitely be using CHIRP for years to come, it's a great tool and really helps lower the barrier to entry for HAMers who can't afford the more expensive radio's & software. However, it's only getting more and more difficult and frankly unwise to maintain a Python 2 environment on modern systems. I really appreciate all the work that's been put into this so far. I'd love to help speed things up if I can. Thanks, ------------------------------------------- Matthew Poletiek 303.810.9082 matthew.poletiek(a)gmail.com www.matthewpoletiek.com

3 4

[chirp_devel] TYT TH-8600 Programming Protocol Reverse Engineering
by Hisen Zhang 07 Dec '20

07 Dec '20

Hi, I wonder if anyone is working on (or interested in) deciphering TH8600 programming protocol. It looks rather weird to me. First of all, the downloaded bit stream for each request does not correspond to each channel. Modifying channel 2 for instance, may result in the fifth request response change. Second, even the same channel setting will result in different bit stream, despite the address and check sum. Third, I don’t really get the frequency representation. It’s neither lbcd nor uint (I think). I cannot assert here because I am still very confused about the two issues above. I am new to protocol reverse engineering so I would like to learn if I just made the problem complicated. If anyone is interested in I will share captured serial bit stream. Big thanks. Best regards, Hisen (Zhemin) Zhang

2 1

[chirp_devel] [senhaix_8800] New Model #7997
by Nicolas Pike 06 Dec '20

06 Dec '20

First version for SenHaix 8800 Please be gentle. Mercurial is struggle enough. Thanks! Nicolas

3 6

[chirp_devel] [PATCH] [rt22] patch radio ID for RT-622
by Dmitry Baryshkov 04 Dec '20

04 Dec '20

# HG changeset patch # User Dmitry Baryshkov <dbaryshkov(a)gmail.com> # Date 1603075401 -10800 # Mon Oct 19 05:43:21 2020 +0300 # Node ID 1552c486144d10aff7a63ff6d0a14b38c2c52544 # Parent de5d23f4a4235f42a3dee54e2054def2ac224572 [rt22] patch radio ID for RT-622 For RT-622 to update memory correctly, radio ID has to be written at the address 0x1b8. When reading this address reads as 0. So, patch the data during write operation to stop Chirp from overwriting radio ID on these radios. I don't know if this operation has to be performed for other radio IDs as well, so this patching is limited to RT-622. diff --git a/chirp/drivers/retevis_rt22.py b/chirp/drivers/retevis_rt22.py --- a/chirp/drivers/retevis_rt22.py +++ b/chirp/drivers/retevis_rt22.py @@ -205,7 +205,15 @@ serial = radio.pipe cmd = struct.pack(">cHb", 'W', block_addr, block_size) - data = radio.get_mmap()[block_addr:block_addr + block_size] + mmap = radio.get_mmap() + data = mmap[block_addr:block_addr + block_size] + + # For some radios (RT-622) memory at 0x1b8 reads as 0, but radio ID should + # be written instead + if block_addr == radio._patch_addr: + for fp in radio._patch_id: + if fp in mmap[0:radio._patch_len]: + data = mmap[0:radio._patch_len] + data[radio._patch_len:] LOG.debug("Writing Data:") LOG.debug(util.hexprint(cmd + data)) @@ -298,6 +306,9 @@ _memsize = 0x0400 _block_size = 0x40 _fileid = ["P32073", "P3" + "\x00\x00\x00" + "3", "P3207!"] + _patch_id = ["P3207!"] + _patch_len = 8 + _patch_addr = 0x1b8 def get_features(self): rf = chirp_common.RadioFeatures()

2 5

Re: [chirp_devel] [CHIRP - Feature #8503] Naming convention cleanup
by Brad & Cindy Schuler 04 Dec '20

04 Dec '20

Is there something unclear about the names? They are consistent with the other Anytone and BTech drivers written by Dan, Joe, Jim, and Pavel. Brad Schuler On Dec 3, 2020, at 2:19 PM, "donotreply(a)chirp.danplanet.com" <donotreply(a)chirp.danplanet.com> wrote: Issue #8503 has been updated by Tony Ling. "Download from radio" and "Upload to radio" should be renamed as "Read from radio" and "Write to radio" consecutively ________________________________ Feature #8503: Naming convention cleanup<https://chirp.danplanet.com/issues/8503#change-28721> * Author: Brad Schuler * Status: New * Priority: Normal * Assignee: Brad Schuler * Category: * Target version: chirp-daily * Chirp Version: daily * Model affected: anytone_iii Make variable and function names consistent with other Chirp drivers ________________________________ You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://chirp.danplanet.com/my/account

1 0

[chirp_devel] [PATCH] [KT-8R] Add New MCU Version
by Jim Unroe 03 Dec '20

03 Dec '20

# HG changeset patch # User Jim Unroe <rock.unroe(a)gmail.com> # Date 1607001407 18000 # Thu Dec 03 08:16:47 2020 -0500 # Node ID 85201b8b39fb8c4581f10a89e5edbf294d410f91 # Parent 8d906ccd00db039eee18a8af23c87ed4d2d6f127 [KT-8R] Add New MCU Version This patch adds an additional MCU Version to the support for the QYT KT-8R fixes #8513 diff -r 8d906ccd00db -r 85201b8b39fb chirp/drivers/btech.py --- a/chirp/drivers/btech.py Thu Nov 26 21:59:58 2020 -0500 +++ b/chirp/drivers/btech.py Thu Dec 03 08:16:47 2020 -0500 @@ -252,6 +252,7 @@ # QYT KT-8R (quad band ht) KT8R_fp = "MCB264" KT8R_fp1 = "MCB284" +KT8R_fp2 = "MC5264" # ### MAGICS @@ -4641,6 +4642,6 @@ _uhf_range = (400000000, 481000000) _350_range = (350000000, 391000000) _magic = MSTRING_KT8R - _fileid = [KT8R_fp1, KT8R_fp, ] + _fileid = [KT8R_fp2, KT8R_fp1, KT8R_fp, ] _power_levels = [chirp_common.PowerLevel("High", watts=5), chirp_common.PowerLevel("Low", watts=1)]

1 0

[chirp_devel] [PATCH] [anytone_iii] Naming convention cleanup (issue #8503)
by Brad & Cindy Schuler 02 Dec '20

02 Dec '20

Brad Schuler K0BAS

1 0