New Model #9237

Radioddity GM-30

Added by Dirk Bridgedale about 1 year ago. Updated about 1 month ago.

Status:Feedback Start date:07/22/2021
Priority:Normal Due date:
Assignee:- % Done:

0%

Category:-
Target version:-
Chirp Version:daily Equipment Loan Offered:No

Description

New radio request for Radioddity GM-30
https://www.radioddity.com/products/radioddity-gm-30

20220124_234230.jpg (1.1 MB) волдемар сумкин, 01/24/2022 01:53 pm

20220124_234219.jpg (990.5 kB) волдемар сумкин, 01/24/2022 01:53 pm

20220124_182042.jpg (776.1 kB) волдемар сумкин, 01/24/2022 01:53 pm

gm30ctl.py (6.5 kB) Alexandru Barbur, 05/28/2022 09:37 pm

GM-30_download_dump_#1.txt - Serial port capture from Radioddity GM-30 (245.7 kB) Jim Unroe, 05/28/2022 10:10 pm

gm30ctl.py (8.4 kB) Alexandru Barbur, 05/29/2022 02:00 am

radio-memory.txt (3.6 kB) Alexandru Barbur, 05/29/2022 08:56 pm

oem-data-file.txt (3.4 kB) Alexandru Barbur, 05/29/2022 08:56 pm

gm30ctl.py (12.6 kB) Alexandru Barbur, 05/29/2022 08:56 pm

gm30-f7c7112e.tar.gz (11.4 kB) Alexandru Barbur, 06/04/2022 02:30 am

History

Updated by Alex Martin about 1 year ago

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

Updated by Jim Unroe about 1 year ago

  • Status changed from New to Feedback

Alex Martin wrote:

Looks similar to the Baofeng UV-82

Not even close.

and nearly identical to Pofung P15UV

This does appear to be the case.

(which shares a close model number with the P10UV/Radioddity GA-510).

I just looked at the GA-510 driver module and it doesn't appear to be close to how the GM-30 cloning is initiated. The GA-510 image doesn't seem to compare to the GM-30 memory dump I have.

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

Won't work. Not even close to a UV-82 inmany ways. It does appear to be similar to a P10UV, but CHIRP doesn't support that model either.

I may look into it further once I get past my current project and nothing more important shows up.

Jim KC9HI

Updated by Dirk Bridgedale about 1 year ago

Is also branded by TIDRADIO TD-H5

Updated by Joseph David about 1 year ago

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.

Updated by Dirk Bridgedale about 1 year ago

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

Updated by Jim Unroe about 1 year ago

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

Updated by Joseph David about 1 year ago

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.

Updated by Alex Martin about 1 year ago

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.

Updated by Alex Martin about 1 year ago

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.

Updated by Joseph David 10 months ago

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.

Updated by волдемар сумкин 8 months ago

Alex Martin wrote:

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.

software
GM-30 Programming Software_Original
GM-30_Firmware & Software_V1.05
GM-30_Firmware 20210403 & Software_V2.06
GM-30_Firmware 20210615 & Software_V2.06
Doesn't work with my uv-15r.
only works correctly from http://www.abbree.cn/download/

Updated by Joseph David 8 months ago

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.

Updated by Joe Qin 8 months ago

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.

Updated by волдемар сумкин 8 months ago

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.

Updated by Bartlomiej Zielinski 8 months ago

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.

Updated by Joseph David 5 months ago

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.

Updated by Alexandru Barbur 4 months ago

I have several of these radios and am working on reverse engineering the programming protocol the stock firmware uses. When I have it figured out I'll post the relevant details here in case someone else wants to write a CHIRP plugin. I'm attaching a WIP script to this message which can be used to read the radio's memory to local files. By comparing the regions with the data files saved by the OEM programming software I can already roughly see where channel settings, names, and flags are stored. I'll post more as I make more progress. If anyone else reading this wants to help please reach out to me especially if:

  • You're willing to install the shady OEM software on your PC and work on reverse engineering the data file format. The data files map pretty closely to the representation of channel settings in the radio's memory.
  • You have knowledge of the CH340 USB to Serial adpater USB protocol and can help me write a Wireshark dissector for it.
  • You have a Radioddity GM-30 radio, a Radioddity programming cable, a Linux machine, and are willing to risk bricking the radio.

Updated by Jim Unroe 4 months ago

Alexandru Barbur wrote:

  • You're willing to install the shady OEM software on your PC and work on reverse engineering the data file format. The data files map pretty closely to the representation of channel settings in the radio's memory.

I have had the OEM software installed on my PC for quite some time. I made serial port capture back when I installed it. I can create additional serial port captures as required. I have attached my current capture file.

  • You have knowledge of the CH340 USB to Serial adpater USB protocol and can help me write a Wireshark dissector for it.

I don't. I have been using Windows 7 32-bit for all of my development work. I use the Eltima Serial Port Monitor software to do my serial port capture work. I also have appropriate PC03 style programming cables with Prolific, FTDI, Silicon Labs and WCH Serial-to-UART chips.

  • You have a Radioddity GM-30 radio, a Radioddity programming cable, a Linux machine, and are willing to risk bricking the radio.

I have 2 GM-30 radios (1 still in its factory state and 1 that was donated by someone and I don't know how they have used it). I don't have a "Radioddity" programming cable, but as I mentioned above, I have many appropriate programming cables. I can make a Linux machine available (Linux Mint 20.3), but as I mentioned above, I have been doing all of my CHIRP development using Windows. I am willing to brick my radio but I am confident that it will not come to that. ;-)

Jim KC9HI

Updated by Alexandru Barbur 4 months ago

Jim Unroe wrote:

I have had the OEM software installed on my PC for quite some time. I made serial port capture back when I installed it. I can create additional serial port captures as required. I have attached my current capture file.

Excellent. Well like I mentioned when the OEM software reads from and writes to the radio it seems to basically write to or read from it's data file. I ran the software, read a factory radio, filled in as many fields as I could with unique values, and cross referenced the captures I have to narrow down which regions are which. I'm attaching an updated script that implements the writing portion of the protocol although I haven't tested it yet. I've annotated which region corresponds to what offset in the OEM software data file as best as I can guess.

  • You have knowledge of the CH340 USB to Serial adpater USB protocol and can help me write a Wireshark dissector for it.

I don't. I have been using Windows 7 32-bit for all of my development work. I use the Eltima Serial Port Monitor software to do my serial port capture work. I also have appropriate PC03 style programming cables with Prolific, FTDI, Silicon Labs and WCH Serial-to-UART chips.

As far as I know all you need to reproduce my work is Python 3.8+ and the pyserial package from pypi.

I have 2 GM-30 radios (1 still in its factory state and 1 that was donated by someone and I don't know how they have used it). I don't have a "Radioddity" programming cable, but as I mentioned above, I have many appropriate programming cables. I can make a Linux machine available (Linux Mint 20.3), but as I mentioned above, I have been doing all of my CHIRP development using Windows. I am willing to brick my radio but I am confident that it will not come to that. ;-)

Most of the programming cables are interchangeable but a few are not. If the cable works with the OEM software and radios then I'd guess it's the former.

Well I've tested the read functionality and that seems to work but I want to try and learn more about how the data is structured before I try the write functionality. I was planning to basically:

1. Open the OEM software.
2. Load a reference data file.
3. Change one setting.
4. Save the settings to a different data file.
5. Compare the two using a hex editor to figure out what's changed.
6. Rinse repeat until I've figured out all the settings.

Unless you have a better idea we could divide and conquer the memory regions to figure out how they are structured.

Updated by Alexandru Barbur 4 months ago

I've figured out the `General Settings` and `Phone System` parts. I'm attaching two text files that document the relevant encoding for these settings in the OEM data file and radio's memory. I'm going to work on updating my script to generate the correct memory data and then test it using the write command next. I made a brief attempt at decoding the VFO A and VFO B settings and it seems to be much more complicated (changing a single thing in the OEM software changes like ~ 8 bytes in the data file) so I'll leave that for later. Meanwhile I did a bit more reverse engineering on the serial protocol and documented what I learned in the python script which I've attached here.

Updated by Alexandru Barbur 4 months ago

  • File gm30ctl.py added

Ok I've implemented reading and writing the general settings of the radio through this script. Reading seems to work fine but writing doesn't work. The radio seems to enter programming mode and acknowledges the write commands but when it reboots afterwards the settings haven't changed. It seems to matter which commands you send it and the sequence you send them in to enter programming mode. It may be the case that the order in which the memory segments are written also matters in order to confirm the new settings. I'm attaching the updated script here. Note that it now depends on pyserial and mrcorwbar libraries (the latter is used to decode/encode settings from memory data). I'll work on implementing support for decoding the DTMF settings I've already reverse engineered above and then do some testing against the OEM software to see if I can figure out why the write doesn't work. There are also still several commands used to enter programming mode which I don't understand so one of those may be part of the problem.

Updated by Alexandru Barbur 4 months ago

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.

Updated by Jim Unroe 4 months ago

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

Updated by Alexandru Barbur 4 months ago

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.

Updated by Jim Unroe 4 months ago

  • File deleted (gm30ctl.py)

Updated by Jim Unroe 4 months ago

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

Updated by Boris K 4 months ago

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

Updated by Alexandru Barbur 4 months ago

I'm making slow progress reverse engineering the memory structure the radio and CPS uses to encode settings. Unfortunately I already broke one radio attempting to write modified settings to it before I fully understood how the memory segments are laid out. It's not a huge deal; I have more and as long as they are relatively cheap and available I'll keep working on this and buying replacements if I break one. Still I am going to be moving more slowly going forward. This could take weeks and then someone will still need to write a plugin.

On related news I'm attaching what I have so far. If you have Python 3 w/ pip installed you can unzip the archive then:

python -m venv env
source env/bin/activate
pip install -e .
gm30 -d /dev/ttyUSB0 mr -f full_memory.bin         # read all memory from the radio and save it to disk
gm30 -d /dev/ttyUSB0 read -c cps_config_file.data  # read active radio memory segments to local file in CPS format

assuming your programming cable shows up as

/dev/ttyUSB0
on your machine. You can use the Python library to test modifying settings:

from radioddity_gm30.memory import *
from radioddity_gm30.radio_config import *

rc = RadioConfig()

with open('cps_config_file.data', 'rb') as input_file:
  rc.read_file(input_file)

rc.bootscreen_mode = BootscreenMode.MESSAGE
rc.bootscreen_line1 = 'Hello'
rc.bootscreen_line2 = 'World'

with open('cps_config_file.data', 'wb') as output_file:
  rc.write_file(output_file)

I just figured out how frequency data is encoded but I'm struggling to get the

mrcrowbar
library to decode it correctly. I may need to strip it out and switch to something else.

Updated by Alexandru Barbur 4 months ago

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.

Updated by Alexandru Barbur 3 months ago

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.

Updated by Julie Gilman 2 months ago

@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.

Updated by Alexandru Barbur 2 months ago

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.

Updated by Shane Klingler about 1 month ago

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!

Updated by Alexandru Barbur about 1 month ago

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.

Also available in: Atom PDF