CHIRP

This radio appears to be electronics similar to that of a UV-17 Pro GPS stuffed in to a case similar to that of the (UV-)5RM. So in reality I would expect it to be closer to the new BF-F8HP PRO with 1000 channels (10 zones of 100 channels) than anything else. You can try both selections (UV-17 Pro GPS and BF-F8HP PRO) but I would not be surprised if neither selection recognizes it.

I recently ordered a UV-5RH PRO GPS to compare with my BF-F8HP PRO.

Hello Jim,
Thank you for your suggestion - however neither of these selections worked. I was only told "The unit did not respond as expected (A)" (words to that effect).

I watched this video by "Big Will" https://www.youtube.com/watch?v=XZsp6oH-j7w - in which he mentions that CPS software has been obtained for this radio, and posted to the "Baofeng Owner's Club" group on Facebook. I've now downloaded that, and will experiment. The software is called "5RH Pro v1.10 EN_CPS.zip", and was obtained from the AliExpress vendor that one group member bought their handheld from.

If it would assist the CHIRP team, I believe I could capture traffic over the USB connection with Wireshark, whilst running this CPS software.

Kind regards,
Matt Gumbley

I have the same model, have tried selecting "5RM" & "UV-5RH" and have tried Jim's suggestions. I either see the same error message as Matt ("Radio did not response as expected (A)" (on the first try to connect to the radio after turning it on) or "No response from radio. Check connector and cabling!" (on subsequent tries).

However, using Baofeng software "5RH Pro v1.10 EN_CPS" and "5RH Pro v1.14" I am can sucessfully read/write to the radio.

For what is worth the model name on the front of the unit and on the label on the rear are "5RH PRO". The radio definitely has the GPN/GNSS functionality.

Guys, we need debug logs of you trying the other models. Just telling us what error you see is leaving out 90% of the info we're looking for. Please use the procedure in How_To_Report_Issues to update this bug with debug information after you try each of the other models.

Thanks!

Jim Unroe wrote in #note-1:

This radio appears to be electronics similar to that of a UV-17 Pro GPS stuffed in to a case similar to that of the (UV-)5RM. So in reality I would expect it to be closer to the new BF-F8HP PRO with 1000 channels (10 zones of 100 channels) than anything else. You can try both selections (UV-17 Pro GPS and BF-F8HP PRO) but I would not be surprised if neither selection recognizes it.

I recently ordered a UV-5RH PRO GPS to compare with my BF-F8HP PRO.

I believe they are completely different. Every analog full-color display Baofeng I've seen except for this one is descended from a development model called the BF-H802 which was apparently never sold as an actual product. This includes both the zoned and no-zones models. The UV-G30 Pro / BF-UV20 is probably the closest radio to the H802 ancestor.

The 5RH Pro has a very different CPS, handshakes in binary instead of ASCII "PROGRAMblah", and so forth. The CPS does some very questionable things for a supposedly modern software package - it sets its Windows Application Compatibility version to Windows 2000 in some cases, saves its settings in "setting.ini" in the program installation directory and other behavior that has been discouraged in new designs for many years.

The 5RH Pro has gone through 100 firmware versions already (my unit came with 1.0.56, new ones apparently ship with 1.0.94, and there's now a 1.1.0). I mention this because programming the radio is likely to be a moving target. I know of 3 different, slightly incompatible CPS versions - 1.04, 1.10. and 1.14.

Several versions of the 5RH Pro firmware update utility are detected as malware by VirusTotal. This is unlikely to be a false positive as the same detections persist across multiple versions of the utility.

If you want the decompiled CPS, contact me. However, when I offered the same for the UV-17 Pro GPS, you didn't find it helpful.

It seems that Baofeng now has its own version of 5RH PRO for sale, it is called UV-5RM Plus GPS.
https://www.baofengradio.com/collections/analog/products/uv-5rm-plus-gps

Hi,
I have a In Line Hardware FPGA Sniffer for USB Devices. If you need more captures of the USB/Serial communication of the CPS Software working with the UV-5RH PRO GPS Unit let me know. It will be low level USB Communication and all the data above the PHY. I suspect this is all just a serial RS232 communication over USB Serial emulator.

Adam Nowak wrote in #note-11:

I've managed to capture 3 times in a row (dump in zip file - pcapng-3timesRow.zip) communication using CPS and USBpcap on FTDI cable. Wireshark filter below is really helpful

(ftdi-ft ) && (ftdi-ft.if_a_rx_payload || ftdi-ft.if_a_tx_payload)

What I observed:

1. After com port setup, payload 000000000000000000000000ffffffff is send to radio

2. Radio responds: 41 (letter A)

3. next payload 11130e0613000c41 xor (random mask) is sent -> examples in my dump:
   A TX payload: 02001d1500131f52 => 11130e0613000c41 xor 1313131313131313 = 02001d1500131f52 - here in example mask is 13
   A TX payload: 6b69747c697a763b - here mask is 7a
   A TX payload: 65677a7267747835 - here mask is 74

4. Radio responds with detected mask

5. Then to radio is send string "bebebebebebebebe" xor mask
   A TX payload: adadadadadadadad => bebebebebebebebe xor 1313131313131313 = adadadadadadadad
   A TX payload: c4c4c4c4c4c4c4c4 => bebebebebebebebe xor 7a7a7a7a7a7a7a7a = c4c4c4c4c4c4c4c4
   A TX payload: cacacacacacacaca => bebebebebebebebe xor 7474747474747474 = cacacacacacacaca

6. Radio again respond with mask same as in point 4

7. Then string 80f070e130c0015080e0f xor mask is send to radio ???put radio in program mode???
   A TX payload: 1b1c141d001f13061b1d1c => 80f070e130c0015080e0f xor 1313131313131313131313 = 1b1c141d001f13061b1d1c
   A TX payload: 72757d7469767a6f727475 => 80f070e130c0015080e0f xor 7a7a7a7a7a7a7a7a7a7a7a = 72757d7469767a6f727475

8. Radio is sending back 3076c741309bebe41bebebebebebebe xor mask by byte.

9. the 00 is sent to radio
   10 Radio response: 13

10. Radio flash read is initiated by 13414141 xor mask ???read flash command???
    A TX payload: 00525252 => 13414141 xor 13131313 = 00525252

11. Radio sent flash content

I hope that above analysis will help to add support for this radio.

I'm also having this same problem. Have tried multiple different cables (all of which work for other radios) and multiple firmwares with 2 of these radios, but always get the "Radio did not respond as expected (A)" error on read.

Model as sold on Amazon: 5RH Pro GPS
https://www.amazon.com/dp/B0DKNHG7DF

If you need any more debug/trace info than is above, please let us know and we'll provide.

Hi guys! Any news about chirp compatibility with 5RH pro?

Terry Kennedy wrote in #note-9:

The 5RH Pro has gone through 100 firmware versions already (my unit came with 1.0.56, new ones apparently ship with 1.0.94, and there's now a 1.1.0). I mention this because programming the radio is likely to be a moving target. I know of 3 different, slightly incompatible CPS versions - 1.04, 1.10. and 1.14.

And is now at firmware 2.0.9.

If you want the decompiled CPS, contact me. However, when I offered the same for the UV-17 Pro GPS, you didn't find it helpful.

I still have the decompiled CPS 1.14 - all of the later versions are encrypted and protected from debug mode because they're full of viruses/malware (as is the firmware update utility). It is written in Visual Studio 2019 C# with .NET 4.0. I know that's not an area of expertise for the CHIRP developers (you're Python users), but it might be helpful if somebody wanders by and wants to take a look at it to make a start on a CHIRP driver, like Sander did for the UV-17 Pro GPS amd other UV-17 models. The latest CPS is 1.19 and is needed to access the new radio features in 2.x. However, the 1.14 CPS can still talk to the radio and read/write the pieces it knows about. So it would at least be a good start, and might help understand the data being sent to/from the radio. I'm following this issue now, so I'll see a reply if anybody wants the 1.14 CPS source.

Note: this is for 2_0_09, I have 2 radios, one at 1_1_04 and this one at 2_0_9. The 2_0_09 is supposed to fix APRS issue, hoping this can be working as well. I also submitted 1_1_04 error.

This radio is such a moving target that even the factory CPS (malware and all) can't keep up with the firmware changes.

I'd suggest concentrating driver efforts on working with firmware 2.0.2 (what TIDRADIO ships) and above, and use CPS 1.19 (in an isolated VM due to the malware) to see what the CPS is doing differently than the experimental driver here.

Probably not relevant for programming, but the bootloader (which is never overwritten by a firmware update) runs at two different baud rates. The factory changed it early in production to 115200 because they got tired of how slowly the firmware updated on finished radios that were old revs by the time they were completed. When the board is out of the case, they can program it nearly instantly with the pogo pins, but once it's in the case it is too much effort to take apart, so they upped the programming speed.

I have an in development fork of chirp with preliminary 5rhpro support: https://github.com/kholdfuzion/chirp/tree/5rhpro
the last few 2.0.x FW have moved some of the APRS data around so I am pausing on this briefly to give baofeng a chance to finish. Also I have discovered the "protection" on this radios FW and can flash my own modified ones now.