Actually the Explorer QRZ-1 look like a TYT TH-UV88 or Retevis RT85. Have you tried either of those vendor/model selections?

Jim KC9HI

Also,

If you spend just a few mins on YouTube and search for QRZ-1, there are some reviews of this radio. It is indeed the same hardware as the models you suggested, but the firmware has been modified. https://youtu.be/Uu7e2PnkSuo

Colin KK7IAH

Colin Pollock wrote:

Hi Jim,

Yesterday I tried the TYT TH-UV88 with no success. Following your reply, I tried the Retevis RT85. Still no success. Both show the same thing, it tries to clone, but then just sits there. I've let it "clone" for 30 mins with no change. I've never used Chirp before, but I suspect it should only take a few sectons to clone the QRZ-1. Attached is a screenshot.

Colin KK7IAH

Yes. Certainly under a minute. Do you know for sure that you have the correct and working programming cable with a compatible device driver installed?

What does the debug.log file show? Would you attach it to this issue?

It appears that there is no "factory" programming software available for the QRZ-1. All I can locate is the RT Systems software.

Jim KC9HI

Hi Jim,

I have a RT-Sytems Cable, part number ZXP-PROG-10. According to all information I can find in the CHIRP wiki and the RT Systems website, I do not need to install any drivers, as this cable is supported by MacOS version 10.15.05 or newer.

Regarding the debug.log file, I have no idea how to locate this and provide it to you. Please advise or provide a link to instructions.

Correct, I believe the only programming software available is the RT Systems software. I have been able to get this software and cable to communicate with my radio. But I've placed the software on my company computer which will eventually get me in trouble with my IT department. It's for this reason I'm looking for CHIRP to function on my personal MacBook.

Colin KK7IAH

How to locate the CHIRP debug.log file is covered in the CHIRP "How to report issues":https://chirp.danplanet.com/projects/chirp/wiki/How_to_report_issues wiki page.

I can't help you beyond that. I have an Apple MacBook Air, but I am not a "mac" user. Apple keeps making it harder to run CHIRP on macOS. I have purposely kept my MacBook on Catalina to maintain compatibility with the various drivers that I need for my more than 40 programming cables.

Jim KC9HI

I don't see any evidence of communication between CHIRP and the radio. At this time I would expect it being an issue with the programming cable. Either the driver being used and/or the connection between the plug of the programming cable and the socket of the radio.

You claim that you are using a programming cable from RT Systems. I find that hard to believe. The reason for this is because my understanding is that all RT Systems programming cables are FTDI chip based (and therefor would use either an OEM FTDI driver or the native Apple FTDI driver (which should already be present on your computer)).

The debug.log file shows...

DEBUG: User selected TYT TH-UV88 on port /dev/cu.usbserial-1410

The /dev/cu.usbserial-1410 would indicate to me that you are selecting a device that has a Prolific type chip.

A programming cable with an FTDI chip would look something like the following (where the 8 character suffix would be unique to your programming cable)...

/dev/cu.usbserial-A6020QSO
/dev/cu.usbserial-AH03HQ2G
/dev/cu.usbserial-DN00RXF8
/dev/cu.usbserial-DN00V4ZI

So you either don't have an RT Systems programming cable, or you do but you also have another device present with a Prolific chip and you are selecting the other device instead of your programming cable. My guess is that it is a programming cable with a Prolific chip, not FTDI chip (and not an RT Systems programming cable).

The problem with programming cables with a Prolific chip is that they are all PL232HXA or PL232TA chips and the Prolific company considers them end-of-life (EOL). They have coded their driver to not function with EOL chips. Since I have many Prolific chip based programming cables that I must use, I use a Prolific driver that was written by a 3rd party. Unfortunately their driver does is not supported on macOS newer than Catalina (the reason I am still using Catalina here).

So it would seem to me that if you want to use macOS, you need to come up with a Kenwood 2-pin style programming cable that definitely has an FTDI chip inside. To use the programming cable that you have, you would need to either use Linux (the Prolific drivers for Linux are not written by Prolific and don't care if the chips are EOL or not) or use Windows with the older v3.2.0.0 driver that was available before the chips were considered EOL.

Jim KC9HI

It still appears to be a communications problem. When I attempt to download from a TYT TH-UV88 with no radio attached to the programming cable, the resulting debug.log file is virtually the same as yours. I used Windows, but I am sure the result would be the same if I used Linux or macOS.

That is not "my" wiki. Sorry. However the link that you mentioned works fine for me. If you want links to the various USB-to-Serial chip vendors, I suggest you get them from the Miklor "USB Cable Drivers":https://www.miklor.com/COM/UV_Drivers.php page. Or use google to find each chip vendor's download page.

I can't say that any one FTDI chip based programming cable is better than another. I've used them from Baofeng Tech (the radio dealer in the USA, Valley Enterprises, bluemax49ers, etc. I see various FTDI chip based programming cables for the Baofeng UV-5R (which will work for your radio) on Amazon ranging in price from $13 to $23.

Jim KC9HI

Hello, I am a brand new forum user. I stumbled on this thread because I also received my QRZ-1 a few days ago.

I am making this progress using CHIRP with the QRZ-1 radio as follows, not fully working yet for unclear reasons, advice is welcome and I hope my writeup is helpful in finding out a solution

I am doing the following:

Manjaro Linux
Installed chirp by following the flatpak instructions
Using the programming cable I bought at the same time with the giveaway radio, the one they recommend on the checkout screen.
I am starting the chirp flatpak as sudo: 'sudo -i flatpak run com.dansplanet.chirp
I am specifying the device as /dev/ttyUSB0
I am choosing the model TYT TH-UV88 (have also tried the Retevis RT85) the Download from Radio screen.
The Cloning window pops up, but does not progress.
The radio LCD screen lights up as soon as I start the download, indicating something is sent down the cable.

I have waited on the Cloning window for several minutes without anything happening.

That's all I know so far! Will keep this thread bookmarked and let y'all know if I make any headway.

Perhaps you have to put the radio in a programming mode? I do not see any way to do this through the menu system on the device. Perhaps there are secret key-presses to access such a function.

June Taylor wrote:

Hello, I am a brand new forum user. I stumbled on this thread because I also received my QRZ-1 a few days ago.

I am making this progress using CHIRP with the QRZ-1 radio as follows, not fully working yet for unclear reasons, advice is welcome and I hope my writeup is helpful in finding out a solution

I am doing the following:

Manjaro Linux
Installed chirp by following the flatpak instructions
Using the programming cable I bought at the same time with the giveaway radio, the one they recommend on the checkout screen.
I am starting the chirp flatpak as sudo: 'sudo -i flatpak run com.dansplanet.chirp
I am specifying the device as /dev/ttyUSB0
I am choosing the model TYT TH-UV88 (have also tried the Retevis RT85) the Download from Radio screen.
The Cloning window pops up, but does not progress.
The radio LCD screen lights up as soon as I start the download, indicating something is sent down the cable.

I have waited on the Cloning window for several minutes without anything happening.

That's all I know so far! Will keep this thread bookmarked and let y'all know if I make any headway.

When/If this gets sorted out, download/upload will start almost instantly and take way under a minute.

Please provide a clean debug.log file by...

close CHIRP¶

open CHIRP¶

attempt download¶

close CHIRP¶

attach the debug.log file to this issue¶

How to locate the CHIRP debug.log file is covered in the CHIRP "How to report issues":https://chirp.danplanet.com/projects/chirp/wiki/How_to_report_issues wiki page.

You can click the "Watch" link at the top (or bottom) of this issue to get an email whenever there is activity.

Jim KC9HI

June Taylor wrote:

Perhaps you have to put the radio in a programming mode? I do not see any way to do this through the menu system on the device. Perhaps there are secret key-presses to access such a function.

No. There is no need (or way) to do that.

Jim KC9HI

I have not found the log file with the flatpak version. I will try to get the non-flatpak version installed and post again once I have a debug log.

June Taylor wrote:

I have not found the log file with the flatpak version. I will try to get the non-flatpak version installed and post again once I have a debug log.

The debug.log for the flatpak build is in the same place that it is shown for Linux on the "How to report issues":https://chirp.danplanet.com/projects/chirp/wiki/How_to_report_issues page.

For the snap build it is located in ~/snap/chirp-snap/242/.chirp/

Remember that folders that start with a "." (period), as in this case ".chirp", are hidden.

Jim KC9HI

We've pretty much established that the TH-UV88 and RT85 selections will not work. This means that the "magic" is different and or the cloning protocol is different.

Unless someone wants to donate a radio and compatible programming to the cause or someone with the radio and programming software can perform a serial port capture of a successful download from the QRZ-1, there isn't much more that can be done.

Jim KC9HI

Rory Banks wrote:

Ok so if you can't already tell, I have absolutely no idea what I'm doing here, but I'm trying, so please bear with me. Attached are my attempts at serial port captures of both a download from radio and an upload to radio, using the official QRZ-1 Programmer software (I compressed and broke them into parts to meet the max size restriction; if easier, I can also email them). The capture was done using the Serial Port Monitor application. If I did it wrong (and I'm almost certain I did), please let me know how to perform this correctly. Thank you.

Best,
Rory

Hi Rory,

Thank you for your effort but please try again. The capture that I made from my TYT TH-UV88 using Serial Port Monitor is only 104KB.

Once you have completed the capture using Serial Port Monitor, right click in the "Dump view" visualizer (it is the only visualizer that I bother to enable) and choose "Export to..." Next change the "Save as type:" to "ANSI Text file (@*.txt@)" and save the captured transfer to some place convenient. Watch the green progress bar as it grows in the lower right part of the window to know when the capture has been fully saved (it can take a minute or so). Once complete, clear the visualizers and then repeat the process for the upload.

Now attach both "txt" files to this issue. There shouldn't be any reason to need to compress/archive them.

Jim KC9HI

Jim Unroe wrote:

Rory,

Thanks you for the quick testing and feedback. I was able to use this info to uncover and fix a bug in my first proof-of-concept. With what I have learned I have now made additional changes that should now also allow uploading in addition to downloading.

I have noticed in a document from TYT to the FCC (5560447.pdf - attached), the "Brand" for the QRZ-1 is considered to be "Explorer". In order to mesh with this document, CHIRP support for the QRZ-1 will be accessed using the following vendor/model selections.

@Vendor: Explorer
Model : QRZ-1@

This new proof-of-concept has been released as "th_uv88 - grz_1_poc2.py" (attached).

My testing to make sure that support for the TYT TH-UV88 and Retevis RT85 has not been broken is now complete. All continues to work as before for these models.

I now need you (and anyone else with an Explorer QRZ-1) to test "poc2" and provide feedback of success or otherwise. Also please include a new "Explorer_QRZ-1" image.

Thanks,
Jim KC9HI

I just gave this a shot after throwing together a programmer cable from a CP2102 USB UART and some sockets and patch cables.
For reference, 2.5mm: ring to TX, sleeve to GND; 3.5mm: sleeve to RX. That's TX/RX on the UART.

Anyway, both downloading the radio and uploading a new image worked fine, including a couple settings I decided to change the easy way. This seems real close to ready for production.

Thanks,
Sam KK7IGR

Rory Banks wrote:

Hi Jim,

I was also able to upload and that functionality seems to work well (.img attached). Interesting that a dummy load TX test revealed that non-ham frequencies still seem to be locked out. Is that something that can be addressed? Thanks as always.

Best,
Rory

Thanks for the CHIRP image file.

The radio is locked in firmware. There is nothing CHIRP can do about that. I don't have a QRZ-1 to confirm it, but I would assume that you would unlock it in the same manner that you would for a TYT TH-UV88 or Retevis RT85. Just google "th-uv88 unlock".

Since I don't have a QRZ-1, do you want to take some time to verify that the current CHIRP settings for the TYT TH-UV88/Retevis RT85 also work for the QRZ-1 or do you want to just submit a patch for the QRZ-1 based on the current proof-of-concept? I vote for at least running through the "Basic Settings" to see if they all still correspond to a menu in the QRZ-1.

Jim KC9HI

Hi Jim,

I'd be happy to do some testing to make sure that the UV88/RT85 will also work on the QRZ-1. Would the .img files be helpful for each after uploading some different settings? How about any serial port captures, or was that just to sort out the issue of communication initially?

As for the lock, I tried everything I could find, including trying to use the TYT/Retevis software to update the radio firmware, but no luck (I suspect the software wasn't recognizing the QRZ-1 for the same reason CHIRP wasn't initially). Any other suggestions from anyone else looking to test this functionality would be appreciated.

Best,
Rory

If is recall, I believe all of the Basic Settings in CHIRP correspond to a menu in the TYT TH-UV88. The main thing I am looking for is if there are any Basic Settings that don't have a corresponding menu in the QRZ-1. I would then need to suppress that setting in CHIRP so it doesn't show up for the QRZ-1.

Jim KC9HI

Jim Unroe wrote:

If is recall, I believe all of the Basic Settings in CHIRP correspond to a menu in the TYT TH-UV88. The main thing I am looking for is if there are any Basic Settings that don't have a corresponding menu in the QRZ-1. I would then need to suppress that setting in CHIRP so it doesn't show up for the QRZ-1.

Jim KC9HI

Actually after thinking about it, the best way to do this is to have someone provide a list of the radio's menu options. I could then compare this list to CHIRP and then ask for additional details if I see anything that I have questions about.

Jim

Arch,

Thank you for the list and image. This is exactly what I was looking for.

Jim KC9HI

Arch Stanton wrote:

I also grabbed an image using the POC driver, if that helps. This was captured just after a "reset all", so there was only one default channel in memory.

This image doesn't appear to have been downloaded using the POC2 driver. It is recognized as being from a TYT_TH-UV88. Did you happen to use the original POC1 driver by mistake?

Jim KC9HI

Yes, you are correct. I used the POC1 driver. Just tried again with POC2, and when I try to read from the radio, I get the "Cloning Progress" window that appears to hang (the green light on the cable flashes every few seconds).

Switching back to POC1 driver reads the radio no problem.

FWIW, I am using Windows 10, with CHIRP 20220917, and this BTECH PC03 FTDI cable: https://www.amazon.com/dp/B00HUB0ONK

Arch Stanton wrote:

Adding debug.log of attempt with POC2 driver.

I will be looking at this soon. Thanks.

Jim KC9HI

After comparing the QRZ-1 menu list to the TH-UV88 menu list, the following items require additional research:

From the QRZ-1

• Can someone explain the difference between menu 5 (Dual Rx) and menu 25 (Dual Watch)?
• Images for menu 6 (Lamp Mode): 1 for each selected choice Auto, Off and On
• Images for menu 13 (Scan Mode): 1 each for Carrier, Stop and Time
• Images for menu 23 (Lock Mode): 1 each for Key, Key + S, All, PTT

From the CHIRP Basic Settings

• Does Priority Transmit make any difference when the QRZ-1 is in Dual Watch/Dual Rx mode?
• Does Roger Beep make any difference
• Does Auto Key Lock make any difference
• Does Voice Prompts make any difference
• Does Radio Monitor make any difference (I am thinking that broadcast FM reception has been removed in the QRZ-1)

It looks to me that the Advanced Settings and Work Mode Settings tabs have valid data and are functioning as expected. Does anyone have any experience otherwise with these tabs?

Thanks,
Jim KC9HI

Jim Unroe wrote:

After comparing the QRZ-1 menu list to the TH-UV88 menu list, the following items require additional research:

From the QRZ-1

• Can someone explain the difference between menu 5 (Dual Rx) and menu 25 (Dual Watch)?
• Images for menu 6 (Lamp Mode): 1 for each selected choice Auto, Off and On
• Images for menu 13 (Scan Mode): 1 each for Carrier, Stop and Time
• Images for menu 23 (Lock Mode): 1 each for Key, Key + S, All, PTT

From the CHIRP Basic Settings

• Does Priority Transmit make any difference when the QRZ-1 is in Dual Watch/Dual Rx mode?
• Does Roger Beep make any difference
• Does Auto Key Lock make any difference
• Does Voice Prompts make any difference
• Does Radio Monitor make any difference (I am thinking that broadcast FM reception has been removed in the QRZ-1)

It looks to me that the Advanced Settings and Work Mode Settings tabs have valid data and are functioning as expected. Does anyone have any experience otherwise with these tabs?

Thanks,
Jim KC9HI

I can confirm that the Roger Beep does indeed work on the QRZ-1 when enabled in CHIRP and uploaded to the radio.

Arch Stanton wrote:

Adding debug.log of attempt with POC2 driver.

Arch,

Unfortunately the debug info isn't working correctly with this driver. I don't know why by I hacked it some so that at least I get something useful now. So temporarily try this one.

Jim KC9HI

Arch Stanton wrote:

Well, I feel a bit silly. I had not changed the selection to "Explorer" and "QRZ-1" in the Vendor and Model after loading POC2. Once I realized that was an option, it connects fine. Uploading another image.

Thanks for the followup. That makes sense (and it good news). Disregard the "debug" driver I just attached.

Jim KC9HI

OK. From what everyone has provided so far, the only menu that had the choices in a different order was Scan Mode. This will be accounted for in POC3.

We know that Roger Beep works so it will be left alone. Do we want to remove the Priority Transmit, Auto Key Lock, Voice Prompts and Radio Monitor settings or do we want to wait for bit to see if someone can confirm if they work or not?

Another difference that I just noticed is Squelch.

QRZ-1 (from the list)
Choices: 1, 2, 3, 4, 5, 6, 7, 8, 9

TH-UV88 and RT85
Choices: Off, 1, 2, 3, 4, 5, 6, 7, 8, 9

So I need to know if Off was accidentally left off the list as a choice. If not, then I need at least an image for 1 and 9.

Jim KC9HI

Jim Unroe wrote:

So I need to know if Off was accidentally left off the list as a choice. If not, then I need at least an image for 1 and 9.

Yep, I missed the setting for Squelch. There is a "0" option. Setting to zero appears to act like holding the MONI button.

Jim Unroe wrote:

Do we want to remove the Priority Transmit, Auto Key Lock, Voice Prompts and Radio Monitor settings or do we want to wait for bit to see if someone can confirm if they work or not?

I can confirm setting "Voice Prompts" checked does not seem to change anything.¶

I can confirm setting "Auto Key Lock" checked does lock the keyboard after a timeout, and the keypad can be unlocked by holding the "*Lock" button.¶

I checked the box for "Radio Monitor", but I don't see any difference in operation. I am not familiar with what this menu is supposed to do?¶

Arch Stanton wrote:

I checked the box for "Radio Monitor", but I don't see any difference in operation. I am not familiar with what this menu is supposed to do?¶

I can confirm this option works, and mirrors the setting in menu 25 "Dual Watch". When enabled, VHF/UHF signals will interrupt FM broadcast. When disabled, they will not.

Jim Unroe wrote:

Do we want to remove the Priority Transmit....?

I think Priority Transmit can be removed. Changing this option doesn't appear to make any difference. Regardless of the setting Priority Transmit in CHIRP, the radio transmits on the selected band.
There is also no corresponding menu in the QRZ-1 compared to TYT-THUV88 Menu 2, Tx-Sel.

Arch Stanton wrote:

Arch Stanton wrote:

I checked the box for "Radio Monitor", but I don't see any difference in operation. I am not familiar with what this menu is supposed to do?¶

I can confirm this option works, and mirrors the setting in menu 25 "Dual Watch". When enabled, VHF/UHF signals will interrupt FM broadcast. When disabled, they will not.

Great. Here is what I think I have learned.

Radio Monitor (CHIRP) = Radio Moni (factory software) = menu 25 Dual Watch = menu 34 DW

The Radio Monitor setting determines if the radio is permitted to monitor the selected channel/frequency in the background while the user listens to a broadcast FM station. When on/enabled, reception of a signal on the background channel/frequency will override the broadcast FM station and the background signal will be heard.

This also gave me enough information to answer this question.

Jim Unroe Wrote wrote:

• Can someone explain the difference between menu 5 (Dual Rx) and menu 25 (Dual Watch)?

Menu 25 [Dual Watch] is related to broadcast FM reception as described above.

Menu 5 [Dual RX] = menu 6 D.Wait = Dual Wait/Standby (CHIRP)

The Dual Wait/Standby setting determines if the radio only monitors the channel/frequency in the currently selected display line (disabled) or both display lines (enabled). It is basically enables a 2 channel scanner.

Thanks to the great feedback we also now know...

Jim Unroe Wrote wrote:

• Does Roger Beep make any difference
  This has been confirmed to be supported.

• Does Auto Key Lock make any difference
  This has been confirmed to be supported.

• Does Voice Prompts make any difference
  This has been confirmed to not be supported and has been removed.

• Does Radio Monitor make any difference (I am thinking that broadcast FM reception has been removed in the QRZ-1)
  This has been confirmed to be supported.

I have located the bug in the driver that causes CHIRP to go into an endless loop (which also prevents any debug info from showing up in the debug.log file) when the selected radio is not detected.

So I think all but this issue has been resolved/researched.

Jim Unroe Wrote wrote:

• Does Priority Transmit make any difference when the QRZ-1 is in Dual Watch/Dual Rx mode?

When Dual Wait/Standby is enabled and Priority Transmit is set to Main Channel, then pressing the [PTT] button will always TX on the channel/frequency with the black arrow pointing to it.

When Dual Wait/Standby is enabled and Priority Transmit is set to Last Channel, then pressing the [PTT] button will always TX on the channel/frequency with the most recent reception.

I tested this in my TH-UV88 by enabling D.Wait ((Dual Rx in the QRZ-1) and then selecting a channel in the top (A) display line and different channel in the bottom (B) display line. I then tapped the [A/B] key as needed to select the B channel (black arrow point right towards the bottom frequency).

With Priority Transmit set to Main Channel, I used a 2nd radio tuned to the A frequency and transmitted long enough to be detected and heard on the A channel. Then pressing the [PTT] button on the TH-UV88 caused the radio to TX on the B channel.

With Priority Transmit set to Last Channel, I used a 2nd radio tuned to the A frequency and transmitted long enough to be detected and heard on the A channel. Then pressing the [PTT] button on the TH-UV88 caused the radio to TX on the A channel.

This is the way it should behave on the QRZ-1. If someone would test this and determine if this setting works, I will leave alone. It it doesn't, then I will suppress it for the QRZ-1 like I did the Voice Prompts menu.

I have attached POC3 which is up-to-date with everything that we know, so far.

Jim KC9HI

Jim Unroe wrote:

With Priority Transmit set to Last Channel, I used a 2nd radio tuned to the A frequency and transmitted long enough to be detected and heard on the A channel. Then pressing the [PTT] button on the TH-UV88 caused the radio to TX on the A channel.

This is the way it should behave on the QRZ-1. If someone would test this and determine if this setting works, I will leave alone. It it doesn't, then I will suppress it for the QRZ-1 like I did the Voice Prompts menu.

I was able to confirm this works the same on the QRZ-1. If CHIRP Priority Transmit = Last Channel, when I follow the steps you describe, PTT causes transmission on the last Rx Channel A, even if B is selected. If CHIRP Priority Transmit = Main Channel, PTT causes transmission on the selected channel B.

This only applies if menu 5 [Dual Rx] = On. If Dual Rx = OFF, then the radio ignores traffic on channel A when B is selected.

I have attached POC3 which is up-to-date with everything that we know, so far.

Jim KC9HI

I don't see a POC3 attached in the list at the top of the page, is there a limit to how many files are visible?

A/B Select is probably supported. It was likely moved to a different memory location. I would need 2 images (the only difference being one selecting A and the other selecting B) to find out where it is located in the QRZ-1.

So I will "hide" A/B select and see if I can't get this submitted today.

Jim KC9HI

Arch Stanton wrote:

Jim Unroe wrote:

I would need 2 images (the only difference being one selecting A and the other selecting B) to find out where it is located in the QRZ-1.

Attaching the two images - I selected A, and saved an image, then B and saved an image. If I upload the "B" image while "A" is selected on the radio, after rebooting, the radio is on "B", and vice versa.

That is the same memory bit for the the TYT TH-UV88/Retevis RT85. If I read them into CHIRP, the corresponding A or B is selected in the Work Mode Settings tab. Are you sure that changing the setting in CHIRP and then uploading to the QRZ-1 doesn't change it in the radio?

Jim KC9HI

Jim Unroe wrote:

That is the same memory bit for the the TYT TH-UV88/Retevis RT85. If I read them into CHIRP, the corresponding A or B is selected in the Work Mode Settings tab. Are you sure that changing the setting in CHIRP and then uploading to the QRZ-1 doesn't change it in the radio?

Jim KC9HI

This is interesting. I tried again, and agree that the downloaded value correctly matches the radio for the current A or B selection.
If A is selected on the radio before the download, then in the downloaded file, Work Mode Settings>A/B Select = A
If B is selected on the radio before the download, then in the downloaded file, Work Mode Settings>A/B Select = B

If I upload however, the radio always sets the selection to B. If I set the radio selection to A, then upload B, the radio reboots and B is selected.
If I set the selection to B on the radio, and upload the setting with an A, the radio reboots, and B is still selected. Very odd.
I even tried setting the selection to A, and uploading an image with A/B Select = A, and the radio still reboots to B!
I then set the radio to B, and uploaded B, just to cover all combinations - selection is still at B.

Tried this a few more times to confirm this is consistently the same. No matter what, it appears that the radio always sets the A/B selection to B (which is only noticeable if it was at A previously, or if the user notices that the upload setting is at A).

I believe this is a bug in the radio firmware because I attempted the same process using the QRZ-1 Programmer software (it does not show a menu for A/B Select) I switched the setting and downloaded two files, one with the radio set at A, one with B. Uploading either to the radio always results in a selection of B after the end-of-upload reset.

I should note that when I power the radio off and on, the last A/B selection is maintained as expected, so it must be being stored somehow.

I agree with hiding A/B select, though I'm curious if the radio will set A/B to B regardless.

Arch Stanton wrote:

I believe this is a bug in the radio firmware
I agree. I have confirmed the same behavior in the TYT TH-UV88. So I can either remove the setting or leave it alone in case some day TYT fixes the bug.

Jim

Arch Stanton wrote:

I loaded an older "radio data file" using the QRZ-1 Programmer, then re-downloaded in CHIRP with POC4. The Settings menu is not blank, and seems to display accurate info. The old image had only a few memories, and only one frequency saved in the FM list.

The FM Broadcast frequency range check did not match the frequency range that was allowed for the input. So a frequency was considered in-range in one place but but was out_of-range at another. POC5 sets both places to the same frequency range (64.0-108.0 MHz) and will now correctly read your POC3 image. Thanks for noticing and reporting.

Jim KC9HI

Jim Unroe wrote:

POC5 sets both places to the same frequency range (64.0-108.0 MHz) and will now correctly read your POC3 image. Thanks for noticing and reporting.

Thanks, Jim. I am pretty new to CHIRP, so I am enjoying learning about how it works and trying different scenarios. I am not seeing a POC5 python file - did it get dropped again?

-Arch

I've been following the progression of this, I sorely wish I had the technical proficiency to have helped in this effort. I just wanted to extend a profound thank you for your efforts in bring CHIRP support to the QRZ-1.

Jim Unroe wrote:

A patch has been submitted. Support will be in the next CHIRP daily build following approval.

Jim KC9HI

Thank you Jim, and everyone else who contributed to this patch!

I just found this thread in a web search. I have an Explorer QRZ-1 and use a MacBook Pro running Monterey 12.6 and a programming cable that I bought from RT Systems. Did you guys figure out how I can program this HT with CHIRP?