Related to #11696 #1350

ojfd · 2025-08-11T04:08:07Z

Adds Baofeng BF-9700 + Stun entries in Browser. Removes 'Scan' checkbox for BF-190x and BF-9700 not present in OEM software. Addresses a few E722 warnings (not 100% sure about them).

Adds Baofeng BF-9700. Removes 'Scan' checkbox for BF-190x and BF-9700 not present in OEM software. Addresses a few E722 warnings (not 100% sure about them).

Adds Baofeng BF-9700 + Stun entries in Browser. Removes 'Scan' checkbox for BF-190x and BF-9700 not present in OEM software. Addresses a few E722 warnings.

Related to #11864. Fixes swapped Last and Main channels in Priority Transmit for RA89/P62/P2. Adds Mic Level for RA89. Adds freq. band reporting in 'Browser' tab.

ojfd · 2025-08-12T03:23:59Z

There are two modules in this PR: h777.py and th_uv88.py
I have no clue how they got uploaded in the same PR.

th_uv88.py is related to #11864.
Many changes for Retevis P2 and P62.
Fixes swapped Last and Main channels in Priority Transmit for Retevis RA89/P62/P2 and their TYT siblings.
Adds Mic Level for RA89. Adds freq. band reporting in 'Browser' tab.

Renumbering 'unkXX' in sequential order. Added 'Eliminate Squelch Tail When No Ctc/Dcs Signaling' entry to be seen in 'Browser'

kk7ds · 2025-08-22T15:14:28Z

You may not have seen the PR guidelines because of how you created this, but this needs some changes to be merge-able. Specifically:

The new model needs to be in its own commit with a proper subject line and a Fixes: #11696 tag below it. The other cleanups should really be in their own PR, but even if they're here, they need to be in a proper commit each with a suitable subject. The subject line of each commit gets sent to the mailing list on each build, so if this merged, they would see a big list of "changes" like:

...
Update th_uv88.py
Cosmetic changes
Update th_uv88.py

Also, the comments here in the PR are not persisted in git history, so most of your changes here have no context about what they're doing. Please put your comments from above (but hopefully with more detail than "many changes") into the commit messages themselves so they stick with the change in the history. The bug system will not notice the reference to bug 11696 if it's in a comment here, it has to be in the commit message.

So in summary, from the look of it, this could be squashed down to three commits, the new model, and one cleanup commit per other driver. If you don't know how to do that I can try to do it for you this time.

Thanks!

ojfd · 2025-08-22T15:46:44Z

Dan, you talk to me like I'm some kind of professional programmer, but in reality I am not and this is my first PR ever!
I did read PR guidelines, but for regular person not in the trade that's double dutch. I have no idea how things are organized on GitHub, what all that lingo mean and where files end up :))
We spoke on your website, you asked me if I want to participate and I said yes. I did some changes to code, you said it is Ok, so that encouraged me to work on. I applied further changes and to best of my knowledge put the files up here. Feel free to do with them whatever you want.

Put two underscores back

kk7ds · 2025-08-22T15:57:44Z

Almost none of the contributors to CHIRP are professional programmers, FWIW :)

And no, I'm talking to you like the obviously intelligent person that you are and trying to point you at the steps we all go through to get stuff into the tree in an organized way. These may seem foreign at first, but they're very doable. You mentioned (what I deduced was) this PR in a comment earlier today in a way that made it seem like you were expecting it to be merged. I had seen it marked as draft before and was still in a state needing to be cleaned up so I figured maybe I'd circle back here and nudge you towards the issues keeping it from being merged in case it wasn't obvious.

I'll pull this down and reformat it the way it should be, but I'll want you to look it over again since I don't have any of these radios to test with.

kk7ds

A couple of comments of things that should change, and questions about the changes being made here so I can split and cleanup the the commit history as noted.

Thanks!

kk7ds · 2025-08-22T16:00:38Z

chirp/drivers/h777.py

+#seekto 0x0250;
+struct {
+    u8 stun_code[7];
+    u8 unused1[1];


An array of 1 doesn't make sense, so this should just be u8 unused1; .. TBH, bitwise should be warning you about this, so I'll check and see why it's not.

kk7ds · 2025-08-22T16:04:21Z

chirp/drivers/h777.py

-        rs = RadioSetting("scan", "Scan",
-                          RadioSettingValueBoolean(_settings.scan))
-        basic.append(rs)
+        if self.PROGRAM_CMD == b'PROGRAM':


It would be better to check something other than this PROGRAM_CMD, but I see you're mirroring another piece of code here that already does that. So maybe let's circle back and clean up both in a subsequent change.

I did as best as I could. Not the most elegant way, I know. Quick and dirty. I just wanted to get rid of "Scan" for radios that do not support it.

kk7ds · 2025-08-22T16:05:59Z

chirp/drivers/h777.py

        self.driver = H777Radio(None)
        self.testdata = bitwise.parse("lbcd foo[2];",
-                                      memmap.MemoryMap("\x00\x00"))
+                                      memmap.MemoryMapBytes("\x00\x00"))


Thanks for fixing this to use MemoryMapBytes but this needs to take a byte string (so b"\x00\x00"). But, this little integrated test is not actually run anywhere, the original author was just using it (and I bet it doesn't even work anymore). I'll bytes-ify this string just for consistency, but this too could use a revisit.

kk7ds · 2025-08-22T16:08:54Z

chirp/drivers/th_uv88.py

+                   '4.0S', '4.5S', '5.0S']
+        rx = RadioSettingValueList(options, current_index=_settings.voxDelay)
+        rset = RadioSetting("basicsettings.voxDelay", "VOX Delay", rx)
+        basic.append(rset)


Help me out... this is just moved from below but otherwise unchanged? Is there some reason it was moved or just accidental?

Yes, purely for cosmetic reasons, so that Vox Level and Vox Delay appear in one place in GUI

Okay cool, so this change should be one commit on its own so it's clear that it's just moving (and not changing) anything.

This also moves it into basic from advanced. I assume @KC9HI was mirroring the radio vs. software menu structure which is why this was down below in advanced and not with the other one. So I'll let him comment on whether or not he wants this moved.

It does. But, just FYI, in OEM software all these functions are in one, s.c. "Basic" window

kk7ds · 2025-08-22T16:10:09Z

chirp/drivers/th_uv88.py

+        rx = RadioSettingValueBoolean(_settings.dualWait)
+        rset = RadioSetting("basicsettings.dualWait",
+                            "Dual Wait/Standby", rx)
+        basic.append(rset)


This adds the dual wait setting for all models, where it was restricted to only ones with LCDs before. Is this intentional? I have h777-based radios without displays that I'm sure don't have dual wait since they only have a way to select a single channel.

h777 based radios in uv88 file?

kk7ds · 2025-08-22T16:12:39Z

chirp/drivers/th_uv88.py

+                    [(str(x + 1), x) for x in range(200)], _settings.dwchan)
+                rs = RadioSetting('basicsettings.dwchan',
+                                  'Dual Wait Channel', rsv)
+                basic.append(rs)


I'm guessing these non-display radios have a dedicated "always dual wait for channel X" function? Mine aren't in this list, which means they'll get a dual-wait setting in settings, but won't get this extra setting either. I think the logic should be "if LCD, always add dual-wait. If not LCD but dwchan in _settings then add dual-wait and dual-wait-chanel" right?

This and the question above are still relevant to make sure you intended to change this in this way, however my confidence about whether it's correct or not is irrelevant since I don't know anything about these radios.

@KC9HI can you review the changes being made to this driver to make sure they jive with your understanding of them all?

Yes, in Retevis P62/P2 and TYT TC29, when dual wait is activated, you tell the radio which other, permanently set channel to watch. Range 1 to 200. Dan, you did this piece when we spoke for the first time. See #11864

Yep, and I remember it being too wide a scope in terms of the models it affected, hence it being reverted and hence me asking for someone more familiar with these models to help review :)

Nah, it's just two models. Almost identical. One with display - Retevis RA89/TYT TH-UV99, the other one without - Retevis P62/P2/ TYT TC29.
I've double and triple checked all functions on my radios, everything is working as expected. I have a park of all of these. Found a few firmware bugs too along the way.
I keep filing on this driver and it would be extremely cool if @KC9HI could revisit it. I have a bunch of question to ask

kk7ds · 2025-08-22T16:14:05Z

chirp/drivers/th_uv88.py

+            options = ["Main Channel", "Last Channel"]
+        else:
+            options = ["Main Channel", "Last Channel",
+                       "Active Channel with Lockout Time"]


Are you sure all h777-based radios without LCD support this extra setting? Or do you want to add that only for the subset of models you know have it?

Oops, I just realized this is the second driver, so this comment makes no sense.

I'll look to Jim to review this part since I don't have any of these.

As before, I don't see h777 based radios in th_uv88 file. This setting is for Retevis P62, Retevis P2 and their father - TYT TC29. They have 3 options in OEM software. Third option activates extra "Active Channel with Lockout Time"

KC9HI · 2025-08-22T17:27:55Z

I cut my teeth on the uv5r.py driver which had Basic and Advanced tabs. I don't know of or if there is any published or otherwise standard for which settings go where. For the last couple of years I have just been putting settings that are included in the radio's menus in the Basic tab and putting any settings that only appear in software in the Advanced tab. It would be nice to always have common settings grouped together, but that doesn't always mesh with how the settings are arranged in the OEM software and can be difficult to achieve when the driver you are trying to add too may already support 10 or more radio models. For me it got to the point I was spending more time trying to arrange the settings to accomplish a goal that I felt very few would ever appreciate. So recently I have mostly been adding any settings that aren't already supported in their own group below the existing settings. I am good with anyone that wants to take on a project of reorganizing the settings into a more use-able arrangement.

chirp/drivers/th_uv88.py

ojfd · 2025-08-26T13:26:30Z

I am good with anyone that wants to take on a project of reorganizing the settings into a more use-able arrangement.

Do rearrangements of menu items and changes of terminology like these make sense to you, guys?

I am not applying such changes to current PR, it's just that you can see what I'm working on. It's still work in progress, but, eventually, I'd like to see at least some of it implemented in Chirp. I'm tired of loading modules..

ojfd · 2025-09-18T00:36:07Z

So, what's up with this PR?
It is over a month since I submitted it and nothing have happened.
Honestly, taking part in Chirp project has been nothing but major frustration for me so far.

From about august Quansheng is shipping all UV-K5 variants with new controller chip and new firmware. Radios with previous controller chip are no longer being manufactured. Numbering of new firmware starts with 1.

ojfd added 3 commits August 11, 2025 06:32

Add files via upload

578518c

Related to #11696

df8d743

Adds Baofeng BF-9700. Removes 'Scan' checkbox for BF-190x and BF-9700 not present in OEM software. Addresses a few E722 warnings (not 100% sure about them).

Related to #11696

71b4d70

Adds Baofeng BF-9700 + Stun entries in Browser. Removes 'Scan' checkbox for BF-190x and BF-9700 not present in OEM software. Addresses a few E722 warnings.

ojfd marked this pull request as draft August 11, 2025 04:53

Related to #11696 v2 to test

c65da62

ojfd marked this pull request as ready for review August 11, 2025 05:25

ojfd added 4 commits August 11, 2025 08:46

Related to #11696 v3 to test

dcff99c

Delete h777.py

596524e

th_uv88: adds Dual Watch + other settings for Retevis P2/P62

8dcd0a2

Related to #11864. Fixes swapped Last and Main channels in Priority Transmit for RA89/P62/P2. Adds Mic Level for RA89. Adds freq. band reporting in 'Browser' tab.

th_uv88: to test for Python 3.x drivers

54589b3

ojfd added 3 commits August 12, 2025 10:35

Update th_uv88.py

6a3fbaa

Cosmetic changes.

d4f90d5

Renumbering 'unkXX' in sequential order. Added 'Eliminate Squelch Tail When No Ctc/Dcs Signaling' entry to be seen in 'Browser'

Update th_uv88.py

19622e6

Update th_uv88.py

3bf4353

Put two underscores back

kk7ds reviewed Aug 22, 2025

View reviewed changes

Update th_uv88.py

fad1863

ojfd commented Aug 24, 2025

View reviewed changes

chirp/drivers/th_uv88.py Show resolved Hide resolved

ojfd added 2 commits August 29, 2025 19:25

Removed two arrays of 1

964ee4f

Merge branch 'kk7ds:master' into master

8688eaf

ojfd requested a review from kk7ds August 31, 2025 22:24

ojfd added 3 commits September 7, 2025 09:55

Merge branch 'kk7ds:master' into master

4641234

Merge branch 'kk7ds:master' into master

258dfb1

Merge branch 'kk7ds:master' into master

4639b62

ojfd added 4 commits September 21, 2025 09:30

Merge branch 'kk7ds:master' into master

938e9a2

Merge branch 'kk7ds:master' into master

ac54c91

Merge branch 'kk7ds:master' into master

a9633e6

Add new official firmware for v2 radios

5acdbdf

From about august Quansheng is shipping all UV-K5 variants with new controller chip and new firmware. Radios with previous controller chip are no longer being manufactured. Numbering of new firmware starts with 1.

Related to #11696 #1350

Are you sure you want to change the base?

Related to #11696 #1350

Uh oh!

Conversation

ojfd commented Aug 11, 2025

Uh oh!

ojfd commented Aug 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kk7ds commented Aug 22, 2025

Uh oh!

ojfd commented Aug 22, 2025

Uh oh!

kk7ds commented Aug 22, 2025

Uh oh!

kk7ds left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

KC9HI commented Aug 22, 2025

Uh oh!

Uh oh!

ojfd commented Aug 26, 2025

Uh oh!

ojfd commented Sep 18, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

ojfd commented Aug 12, 2025 •

edited

Loading