Looks similar to the Baofeng UV-82 and nearly identical to Pofung P15UV (which shares a close model number with the P10UV/Radioddity GA-510). Perhaps try connoting with Boafeng UV-82 or Radioddity P10UV to see what happens and provide debug log per instructions at https://chirp.danplanet.com/projects/chirp/wiki/How_To_Report_Issues

Is also branded by TIDRADIO TD-H5

This radio is nearly identical to the TYT UV-88 externally, however internally there seem to be some substantial differences. I don't know if the communications protocols are similar, but the UV-88 is supported by Chirp. I believe the Pofung P15UV is essentially the same radio as the GM-30, but can't confirm as I don't have the Pofung. Other than the P15UV, there is not much similarity between the GM-30 radios and the Baofeng models.

Attempted yo upload as a TYT UV-88. It would not start/complete the clone.

Dirk Bridgedale wrote:

Attempted yo upload as a TYT UV-88. It would not start/complete the clone.

As expected. From what little work I have done with the GM-30, it's cloning protocol is not like any other radio I have seen. It will most likely have to be reverse engineered from scratch.

Jim KC9HI

I just obtained a pair of Tidradio TD-H5 GMRS radios, and they are nearly identical to the GM-30. I was able to successfully use the GM-30 software to read and write to the TD-H5. I expect the same would be true of the Pofung P15UV, but I still cannot confirm this as I don't have a P15UV radio.

Can confirm Pofung P15UV is indeed a rebranded Radioddity GM-30 as well. Was able to use the GM-30 software to read and write.

Update: Just a note, unrelated to Chirp but advice for anyone reading this later. The Pofung 15UV's keypad number keys have the wrong 'menu functions' on them so my assumption is that it's a limited supply run or something of the GM-30 using old components or something. Not a radio I would necessarily recommend given that it is pretty close in price with the GM-30.

This is an update regarding Alex Martin's post about the Pofung P15UV. I saw a new listing for the radio and it looks like it now has a keypad identical to the GM30 keypad.

Just for clarification:

It seems there are two almost identical Baofeng/Pofung models: P15UV and UV-15R.
The P15UV is a clone of the Radioddity GM-30/Tidradio TD-H5.

The UV-15R looks identical, but is seemingly different. On Amazon, it's listed as a GMRS radio, but the display clearly shows (non-GMRS) UHF and VHF frequencies. It also is not currently available.

On Banggood, the UV-15R is shown as a 10W, 999 channel, dual-band ham radio, not a GMRS radio. This would be more similar to the TYT UV-88/Retevis RT85 twins, but with higher power and more channels. The TYT and Retevis radios are already supported by Chirp.

Hi,

I also have a UV-15R. I tried the TYT UV88 and Retevis RT85 profile in Chirp, and neither of them works. Even though they are physically similar, I don't think they are the same device. The UV-15R has 999 channels, the other two have 200.

Found this report online (https://fcc.report/FCC-ID/2AJGM-P15UV/5201604.pdf). The P15UV and the UV-15R seem to be the same.

Joe Qin wrote:

Hi,

I also have a UV-15R. I tried the TYT UV88 and Retevis RT85 profile in Chirp, and neither of them works. Even though they are physically similar, I don't think they are the same device. The UV-15R has 999 channels, the other two have 200.

Found this report online (https://fcc.report/FCC-ID/2AJGM-P15UV/5201604.pdf). The P15UV and the UV-15R seem to be the same.

I support it, I also have this radio UV-15R, and I tried this connection. none of them work.

Funny thing, my P15UV came in a box that said "200 channels and 24 FM radio" (like in TYT), but that't obviously not the truth; the radio has 999 channels and only one FM radio, also the menu is different and the software is different (e.g., memory channel change is slower than in TYT). It looks that the producer does not know exactly what he produces ;)
My P15UV in a ham radio handheld, not a GMRS one.

It looks like there are a few more GM-30 clones coming to the market. The Rugged GMR2 looks like the same radio as does the Baofeng GM-15 Pro. I suspect these are essentially the same radio internally as the GM-30, with only cosmetic exterior differences that set them apart.

DO NOT RUN THE SCRIPT ABOVE !

I figured it out. The registers 0x1FFF to 0xFFFF read near the start actually define a mapping between memory pages and what data they are supposed to store. I was writing data to the wrong pages in memory which apparently did not break the radio. Still, until I can fix the script to parse the addresses correctly running it could overwrite memory pages with invalid data and potentially break the radio. I'll update the script and post it once I can confirm writing works correctly here. I think I'm really close to having something that can read, modify, and write the settings correctly.

Alexandru Barbur wrote:

DO NOT RUN THE SCRIPT ABOVE !

I figured it out. The registers 0x1FFF to 0xFFFF read near the start actually define a mapping between memory pages and what data they are supposed to store. I was writing data to the wrong pages in memory which apparently did not break the radio. Still, until I can fix the script to parse the addresses correctly running it could overwrite memory pages with invalid data and potentially break the radio. I'll update the script and post it once I can confirm writing works correctly here. I think I'm really close to having something that can read, modify, and write the settings correctly.

I would recommend that you remove the script. If you don't have the privileges required to delete it, I can do it for you.

Jim KC9HI

I don't think I can remove it. If you can then go for it. I'll look into hosting it in a public repository on GitHub at some point soon so I don't keep spamming this issue with attachments.

P.S. The serial capture you posted above was really useful to figuring out the memory segment mapping. It gave me the third data point I needed to see the pattern.

Alexandru Barbur wrote:

I don't think I can remove it. If you can then go for it. I'll look into hosting it in a public repository on GitHub at some point soon so I don't keep spamming this issue with attachments.

P.S. The serial capture you posted above was really useful to figuring out the memory segment mapping. It gave me the third data point I needed to see the pattern.

I removed it. To me what you are doing is not spamming. It is logging and keeping the history of the development in one place.

Let me know if you want me to create and attach a serial capture of an upload to the radio.

Jim KC9HI

With all the development happening, will the GM-30 be integrated with the next Chirp release.

Oh, I disabled the two write commands in the code, so no one else breaks their radio unless they really intend to take the risk. Writing does seem to work but I think the firmware has some logic of it's own that happens after a reboot. On one radio I overwrote the 0x02 segment with 0xFC0 x 0xFF bytes and now I can't seem to change it anymore. I took a complete read of the radio memory before this so I thought I could just write the data back to fix it. The radio accepts the write commands and reboots as usual but when I read the memory back it's still 0xFF. It seems to be stuck in VFO mode with a frequency of 666.500 and behaves very erratically. I think that segment contains factory calibration data because it's almost identical between the radios I have and the CPS doesn't seem to change it. So yeah, long story, but the short version is there's more to this protocol than I've figured out just yet.

I'm slowly working on this but I'm a little stuck. I've broken another radio by trying to write to it. There's something I'm missing in the way I send write commands or the sequence of them I think. Once I have a few hours to look at this again I plan to capture back to back reads and writes between the CPS and one of the working radios I have then go through them carefully to see if I can figure out what I'm doing wrong. I'm also tempted to look into the firmware flashing mode to see if there's a way to recover the radios I've messed up. The first one I wrote garbage to it so I'm not surprised there but the second one I only tried to overwrite the general and frequency memory regions (and left the DTMF and calibration data alone) and that didn't seem to work either. When reading the radio's memory (using the "mr" command above) I can see the calibration data is still there but the rest of the memory pages seem to be filled with placeholder data.

I'm not sure if there's a faster way to figure this out; maybe someone could start trying to reverse engineer the CPS or the radio firmware in parallel or just capture a few writes and compare them to my implementation from the ZIP above. Regardless I'll post again here if or when I make more progress.

@Alexandru: I'd like to offer some help working on this. I've got a Baofeng GM-15 Pro which appears to be the same hardware. I tried to reverse engineer the CPS a bit but I'm not a coder so my adventure in Ghidra was short lived. I have been doing some poking around in a save file from the CPS in a hex editor and discovered a few of the same things you did.

Let me know where you need a hand.

If you've got a codeplug you'd like me to test with I can capture the USB read/writes to the radio with Wireshark and send them over to save you a little bit of work.

Julie Gilman wrote:

@Alexandru: I'd like to offer some help working on this. I've got a Baofeng GM-15 Pro which appears to be the same hardware. I tried to reverse engineer the CPS a bit but I'm not a coder so my adventure in Ghidra was short lived. I have been doing some poking around in a save file from the CPS in a hex editor and discovered a few of the same things you did.

Let me know where you need a hand.

If you've got a codeplug you'd like me to test with I can capture the USB read/writes to the radio with Wireshark and send them over to save you a little bit of work.

I haven't had a chance to work on this for the last few weeks due to moving. The code I posted above can:

• Read all memory segments from the radio (mr command).
• Read the memory segments used to store the current configuration data (read command).
• Read the configuration data from an CPS data file.
• Write the configuration data to a CPS data file.
• Parse or modify most of the configuration settings.

All that's really missing is writing the configuration to the radio. Someone probably needs to capture a dozen writes to the radio and stare at them long enough until they figure out what part of the protocol I'm missing. The code is currently in a private GitHub repository but I will make it public shortly, type up a series of steps for capturing a write using Wireshark, and then post it here.

I've been trying to connect the dots on the various models of this radio. Just documenting it here for clarity and a little encouragement for those working on support.

Here's the FCC ID statement declaring the GM30 the equivalent of the P15UV.
https://fccid.io/2AN62-GM30/Letter/Requesttochangeinidentification-5209558

Here's the document declaring the P15UV the equivalent of the UV-15R and others.
https://fcc.report/FCC-ID/2AJGM-P15UV/5201617

If you look at the labels for the UV-15R and others, it looks like they are all based on the UV-13.
https://fcc.report/FCC-ID/2AJGM-P15UV/5201615

The last page of the user manual for the TP8 indicates that it is the amateur radio version of the UV13.
https://fccid.io/2AJGM-TP8/Users-Manual/User-manual-5590778

Based on all of this, it looks like the UV13 is the generic name of the radio and the UV-15R and variations are the GMRS version of it. The TP8 is the amateur radio version of it. The Radioddity GM30 is a rebranded UV-15R.

The existing software at http://www.abbree.cn/download/ under the Baofeng section is labelled UV-15R UV-13 PRO

It would appear that if you get this working for one of these models, you'll have them all supported!

Yeah and I suspect this is why the programming protocol is such a mess; the firmware is likely the result of copy-and-pasting one for the HAM radio variant and then hastily adding in some checks to limit the feature set to GMRS. The protocol is essentially meant to let you read and write arbitrary parts of the radio's memory but if you don't do it correctly (on the GM30) you break it because the firmware is not very robust.

Alexandru Barbur wrote:

Someone probably needs to capture a dozen writes to the radio and stare at them long enough until they figure out what part of the protocol I'm >missing. The code is currently in a private GitHub repository but I will make it public shortly, type up a series of steps for capturing a write >using Wireshark, and then post it here.

I've got a GM-30, and I'd like to have a go at this, but I'm not sure how to do it. Can you post your code here?

I cleaned up the code from above and published it on GitHub at https://github.com/CtrlC-Root/gm30. I apologize this took so long. I was working in a private repository and I needed to extract just the parts I can share. Anyways, I disassembled a radio and I plan to try dumping the firmware from the flash chip, just waiting on some equipment to arrive. In the meantime I'd gladly accept any contributions from anyone who wants to try figuring more about how the programming protocol works. Let me know if there's anything I can do to help.

FWIW, if this radio is the same as the UV13 Pro (I’ve heard that it’s very similar) - someone uploaded a trace file for it on here.

Arch Stanton wrote:

Alexandru Barbur wrote:

Someone probably needs to capture a dozen writes to the radio and stare at them long enough until they figure out what part of the protocol I'm >missing. The code is currently in a private GitHub repository but I will make it public shortly, type up a series of steps for capturing a write >using Wireshark, and then post it here.

I've got a GM-30, and I'd like to have a go at this, but I'm not sure how to do it. Can you post your code here?

It's been a while since I did this but I'll share what I can remember at the moment.

Follow the instructions at https://wiki.wireshark.org/CaptureSetup/USB#windows to install Wireshark with USBPcap. If you use the installer available on the Wireshark website it will offer to install USBPcap for you near the end and that worked for me.¶

Connect the USB programming cable, turn on the radio, and wait for it to boot.¶

Start Wireshark, select the USB capture interface, filter by the specific device (manufacturer and product IDs for the Radioddity cable are 0x1A86 and 0x7523), and start the capture.¶

Open the OEM software and connect to the radio.¶

Read or write the configuration using the OEM software. I recommend making a single transfer one way per capture to simplify your life.¶

Stop the capture in Wireshark.¶

The Radioddity programming cable is just a USB to serial adapter. Mine was built with a CH340 IC and the USB protocol is pretty straight-forward to extract reads and writes from. I wrote a Wireshark plugin to highlight the reads and writes at least but I can't find it at the moment; if I find it later I'll upload it to the repository.

Sadly I can no longer find the Radioddity GM-30 for sale online. I have found a few other radios that appear to be the same hardware but don't know if they use the same firmware or not. I plan to come back to this at some point, if someone else doesn't beat me to it, and try to finish reverse engineering the programming prototocol since I own a half-dozen of them. Not sure if it makes sense to go further than that though if these will be discontinued like the GD-77 was.

Hey Alexandru,

First, thanks for the excellent notes here and comments in the code.
I believe I'm slowly making some progress on disassembly the software, and understanding the protocol. After a few evenings, I was able to identify places where the SYSINFO/PSEARCH commands are sent over serial, and what functions call them in what order.
While I'm new to disassembly and have never done Windows programming, I am a software engineer and am decent at Python. I also have people at work who are excellent at C and can answer my questions.
I have two TP8+/UV13 Pro radios, and I really like them. They do use the same CPS, so your findings are relevant to them as well.
I'm planning to continue working on this project, but I don't know how much time I'll be able to dedicate to it.
But let me know if you decide to resume your work, and we might collaborate on figuring out the protocol.

Sergii

Alexandru Barbur wrote in #note-40:

Sadly I can no longer find the Radioddity GM-30 for sale online. I have found a few other radios that appear to be the same hardware but don't know if they use the same firmware or not. I plan to come back to this at some point, if someone else doesn't beat me to it, and try to finish reverse engineering the programming prototocol since I own a half-dozen of them. Not sure if it makes sense to go further than that though if these will be discontinued like the GD-77 was.

Sergii Tkachenko wrote in #note-41:

Hey Alexandru,

First, thanks for the excellent notes here and comments in the code.
I believe I'm slowly making some progress on disassembly the software, and understanding the protocol. After a few evenings, I was able to identify places where the SYSINFO/PSEARCH commands are sent over serial, and what functions call them in what order.
While I'm new to disassembly and have never done Windows programming, I am a software engineer and am decent at Python. I also have people at work who are excellent at C and can answer my questions.
I have two TP8+/UV13 Pro radios, and I really like them. They do use the same CPS, so your findings are relevant to them as well.
I'm planning to continue working on this project, but I don't know how much time I'll be able to dedicate to it.
But let me know if you decide to resume your work, and we might collaborate on figuring out the protocol.

Sergii

Alexandru Barbur wrote in #note-40:

Sadly I can no longer find the Radioddity GM-30 for sale online. I have found a few other radios that appear to be the same hardware but don't know if they use the same firmware or not. I plan to come back to this at some point, if someone else doesn't beat me to it, and try to finish reverse engineering the programming prototocol since I own a half-dozen of them. Not sure if it makes sense to go further than that though if these will be discontinued like the GD-77 was.

I would love to help. I've had my spare GM-30 on my desk on standby for the last few weeks waiting for the opportunity to get back to it. As I mentioned above I disassembled another one that I bricked earlier in an attempt to dump the firmware and start reversing it but I haven't gotten that far. My ultimate goal is to write custom firmware for these so I'd love to get involved with the firmware reversing in any way I can. Learning the stock firmware programming protocol is just a nice side benefit for my friends who have these but will not be as interested in running custom firmware :).

My email address is public on my GitHub profile. Send me an email and we can follow up from there. I have a few memory dumps and packet captures I could share in addition to what's in the public repository and I'd be happy to explain what I've learned about the protocol so far.

Also comes rebranded NewVision NV-13A
(User manual points to "CPS-P15UV" software from pofungshop)
Sadly, archive.org overlooked the download center (https://web.archive.org/web/20220225213901/http://pofungshop.com/download.asp)

But PSEARCH command returns UV15999 instead of P13GMRS

R D

Are you saying the UV13 firmware can be flashed to the GM-15 pro also? I tried the GA-5E software and it fails to communicate with the BaoFeng GM-15 pro, which was shipped with firmware v06.03.009 from Abbree.

I did flash the UV13 over to the GM-15 pro, as well as trying the GM-30 firmware which matched (and kept the baofeng logo). With the UV13 firmware you can use the P15uv cps (kind of hard to find the main links are broken) to do pretty much anything... but having it in chirp would be nice.

Using the UV13 firmware on the GM-15 pro has a few flaws. You loose the Weather Radio (holding the button with the cloud will flash the voltage not change to weather). The menu short cut keys are off. That is button 3 (VOX) will not jump you to VOX but button 4 (WN) will jump you to the VOX menu.

Just a note that this radio is limited to transmitting on the first 54 channels. You can hex edit the .dat file to add transmit frequencies outside of the GMRS bands (3030 offset in reverse order hex digits) - I think they work but haven't verified if simplex frequencies added are that (the "+" displays on them).

Alexandru Barbur wrote in #note-40:

Sadly I can no longer find the Radioddity GM-30 for sale online. I have found a few other radios that appear to be the same hardware but don't know if they use the same firmware or not. I plan to come back to this at some point, if someone else doesn't beat me to it, and try to finish reverse engineering the programming prototocol since I own a half-dozen of them. Not sure if it makes sense to go further than that though if these will be discontinued like the GD-77 was.

It's still being sold in the USA on Amazon by the way and highly recommended on /r/gmrs on reddit.

Anyway, I am working on actually moving your code into chirp (even if it is just read for now since that seems to be as far as you got). However, I'm getting all kinds of errors in the script.
RuntimeError: Unexpected read size || RuntimeError: No response received || RuntimeError: Failed to receive ACK

The radio is going into 'Program...' mode but seems to be crashing and rebooting during the read.

The furthest I ever got was this:
Using serial device: /dev/cu.usbserial-0001
Entering programming mode
00 00 00 15 ca 00 08 01
00 00 00 15 ca 00 08 01
00 00 00 15 ca 00 08 01
00 00 ff ff 00 00
Detecting memory segments
Reading unknown memory from segment 0x0 @ 0x1000
Reading frequency memory from segment 0xd @ 0xe000
:b'\x00', found b'i'!
Reading channel memory from segment 0x2 @ 0x3000
Reading general memory from segment 0xc @ 0xd000
Reading phone memory from segment 0xe @ 0xf000
Traceback (most recent call last):
File "/Users/alexmartin/Desktop/gm-30/gm30/env/bin/gm30", line 8, in
sys.exit(main())
^{^}
File "/Users/alexmartin/Desktop/gm-30/gm30/radioddity_gm30/cli.py", line 161, in main
read_config(device_path=device_path, config_file=args.config_file)
File "/Users/alexmartin/Desktop/gm-30/gm30/radioddity_gm30/cli.py", line 81, in read_config
radio_config.read_radio(device_path)
File "/Users/alexmartin/Desktop/gm-30/gm30/radioddity_gm30/radio_config.py", line 160, in read_radio
data = protocol.read_memory_range(

File "/Users/alexmartin/Desktop/gm-30/gm30/radioddity_gm30/protocol.py", line 169, in read_memory_range
data += self.read_memory(read_address, read_size)

File "/Users/alexmartin/Desktop/gm-30/gm30/radioddity_gm30/protocol.py", line 132, in read_memory
raise RuntimeError("Read memory response invalid header")
RuntimeError: Read memory response invalid header
4bf0e08c5cfdcd321edf5a0e6b0194f13514a24a5f5d4941701d6d6459389757 output.txt
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 config.bin

The radio works fine with the software from Radioddity. Any advice? My next step is to try and get Wireshark working but seeing if you can help out any as well.

Alex Martin wrote in #note-49:

Alexandru Barbur wrote in #note-40:

Sadly I can no longer find the Radioddity GM-30 for sale online. I have found a few other radios that appear to be the same hardware but don't know if they use the same firmware or not. I plan to come back to this at some point, if someone else doesn't beat me to it, and try to finish reverse engineering the programming prototocol since I own a half-dozen of them. Not sure if it makes sense to go further than that though if these will be discontinued like the GD-77 was.

It's still being sold in the USA on Amazon by the way and highly recommended on /r/gmrs on reddit.

Yeah I've seen it come back in stock and bought a few more as development spares. I think I have 7-8 total now. Additionally one of my friends has one and has recently gotten his GMRS license in order to use it. The lack of CHIRP support really annoys me so I will try and get back to reverse engineering the programming protocol soon.

Anyway, I am working on actually moving your code into chirp (even if it is just read for now since that seems to be as far as you got). However, I'm getting all kinds of errors in the script.
RuntimeError: Unexpected read size || RuntimeError: No response received || RuntimeError: Failed to receive ACK

The radio is going into 'Program...' mode but seems to be crashing and rebooting during the read.

The furthest I ever got was this:
Using serial device: /dev/cu.usbserial-0001
Entering programming mode
00 00 00 15 ca 00 08 01
00 00 00 15 ca 00 08 01
00 00 00 15 ca 00 08 01
00 00 ff ff 00 00
Detecting memory segments
Reading unknown memory from segment 0x0 @ 0x1000
Reading frequency memory from segment 0xd @ 0xe000
:b'\x00', found b'i'!
Reading channel memory from segment 0x2 @ 0x3000
Reading general memory from segment 0xc @ 0xd000
Reading phone memory from segment 0xe @ 0xf000
Traceback (most recent call last):
File "/Users/alexmartin/Desktop/gm-30/gm30/env/bin/gm30", line 8, in
sys.exit(main())
^{^}
File "/Users/alexmartin/Desktop/gm-30/gm30/radioddity_gm30/cli.py", line 161, in main
read_config(device_path=device_path, config_file=args.config_file)
File "/Users/alexmartin/Desktop/gm-30/gm30/radioddity_gm30/cli.py", line 81, in read_config
radio_config.read_radio(device_path)
File "/Users/alexmartin/Desktop/gm-30/gm30/radioddity_gm30/radio_config.py", line 160, in read_radio
data = protocol.read_memory_range(

File "/Users/alexmartin/Desktop/gm-30/gm30/radioddity_gm30/protocol.py", line 169, in read_memory_range
data += self.read_memory(read_address, read_size)

File "/Users/alexmartin/Desktop/gm-30/gm30/radioddity_gm30/protocol.py", line 132, in read_memory
raise RuntimeError("Read memory response invalid header")
RuntimeError: Read memory response invalid header
4bf0e08c5cfdcd321edf5a0e6b0194f13514a24a5f5d4941701d6d6459389757 output.txt
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 config.bin

The radio works fine with the software from Radioddity. Any advice? My next step is to try and get Wireshark working but seeing if you can help out any as well.

That reads like the protocol has changed somehow. What we really need to start doing is qualifying all of these messages with the firmware version. I'm going to reorganize the GitHub repository soon to start documenting what I know about each hardware and firmware revision. I suspect this will pave the way for quickly figuring out how the related variants (i.e. from BaoFeng) work as well.