Project

General

Profile

Actions

New Model #9237

open

Radioddity GM-30

Added by Dirk Bridgedale over 2 years ago. Updated 6 months ago.

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

0%

Estimated time:
Equipment Loan/Gift Offered:
No
I read the instructions above:

Description

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


Files

20220124_234230.jpg (1.12 MB) 20220124_234230.jpg волдемар сумкин, 01/24/2022 01:53 PM
20220124_234219.jpg (990 KB) 20220124_234219.jpg волдемар сумкин, 01/24/2022 01:53 PM
20220124_182042.jpg (776 KB) 20220124_182042.jpg волдемар сумкин, 01/24/2022 01:53 PM
gm30ctl.py (6.49 KB) gm30ctl.py Alexandru Barbur, 05/28/2022 09:37 PM
GM-30_download_dump_#1.txt (246 KB) GM-30_download_dump_#1.txt Serial port capture from Radioddity GM-30 Jim Unroe, 05/28/2022 10:10 PM
gm30ctl.py (8.35 KB) gm30ctl.py Alexandru Barbur, 05/29/2022 02:00 AM
radio-memory.txt (3.59 KB) radio-memory.txt Alexandru Barbur, 05/29/2022 08:56 PM
oem-data-file.txt (3.36 KB) oem-data-file.txt Alexandru Barbur, 05/29/2022 08:56 PM
gm30ctl.py (12.6 KB) gm30ctl.py Alexandru Barbur, 05/29/2022 08:56 PM
gm30-f7c7112e.tar.gz (11.4 KB) gm30-f7c7112e.tar.gz Alexandru Barbur, 06/04/2022 02:30 AM
UV13-Firmware-V06.01.013-20211104_01013.bin (57.7 KB) UV13-Firmware-V06.01.013-20211104_01013.bin Aaron Blankenship, 04/06/2023 05:09 AM

Related issues

Related to New Model #10077: Baofeng GM-15 pro / Radioddty GM-30Closed10/13/2022

Actions
Actions #1

Updated by Alex Martin over 2 years 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

Actions #2

Updated by Jim Unroe over 2 years 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

Actions #3

Updated by Dirk Bridgedale over 2 years ago

Is also branded by TIDRADIO TD-H5

Actions #4

Updated by Joseph David over 2 years 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.

Actions #5

Updated by Dirk Bridgedale over 2 years ago

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

Actions #6

Updated by Jim Unroe over 2 years 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

Actions #7

Updated by Joseph David over 2 years 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.

Actions #8

Updated by Alex Martin over 2 years 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.

Actions #9

Updated by Alex Martin over 2 years 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.

Actions #10

Updated by Joseph David over 2 years 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.

Actions #11

Updated by волдемар сумкин about 2 years 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/

Actions #12

Updated by Joseph David about 2 years 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.

Actions #13

Updated by Joe Qin about 2 years 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.

Actions #14

Updated by волдемар сумкин about 2 years 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.

Actions #15

Updated by Bartlomiej Zielinski about 2 years 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.

Actions #16

Updated by Joseph David almost 2 years 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.

Actions #17

Updated by Alexandru Barbur almost 2 years 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.
Actions #18

Updated by Jim Unroe almost 2 years 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

Actions #19

Updated by Alexandru Barbur almost 2 years 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.

Actions #20

Updated by Alexandru Barbur almost 2 years 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.

Actions #21

Updated by Alexandru Barbur almost 2 years 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.

Actions #22

Updated by Alexandru Barbur almost 2 years 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.

Actions #23

Updated by Jim Unroe almost 2 years 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

Actions #24

Updated by Alexandru Barbur almost 2 years 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.

Actions #25

Updated by Jim Unroe almost 2 years ago

  • File deleted (gm30ctl.py)
Actions #26

Updated by Jim Unroe almost 2 years 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

Actions #27

Updated by Boris K almost 2 years ago

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

Actions #28

Updated by Alexandru Barbur almost 2 years 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.

Actions #29

Updated by Alexandru Barbur almost 2 years 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.

Actions #30

Updated by Alexandru Barbur almost 2 years 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.

Actions #31

Updated by Julie Gilman over 1 year 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.

Actions #32

Updated by Alexandru Barbur over 1 year 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.

Actions #33

Updated by Shane Klingler over 1 year 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!

Actions #34

Updated by Alexandru Barbur over 1 year 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.

Actions #35

Updated by Arch Stanton over 1 year ago

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?

Actions #36

Updated by Alexandru Barbur over 1 year ago

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.

Actions #37

Updated by BJ Badyk over 1 year ago

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.

Actions #38

Updated by Alexandru Barbur over 1 year ago

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.

Actions #39

Updated by Bernhard Hailer about 1 year ago

Actions #40

Updated by Alexandru Barbur about 1 year ago

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.

Actions #41

Updated by Sergii Tkachenko about 1 year ago

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.

Actions #42

Updated by Alexandru Barbur about 1 year ago

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.

Actions #43

Updated by Aaron Blankenship 12 months ago

Posting as I suspect GM-30 is the exact same hardware as UV-13:

Abbree support has provided me with the UV-13 firmware V06.01.013 (attached) to support the TP-8Plus. Firmware can be flashed following the process on https://www.radioddity.com/blogs/all/how-to-update-radioddity-gm-30-firmware

The CPS 1.09 software without the GM-30 restrictions can also be found via Radioddity site via the European model GA-5E. https://www.radioddity.com/pages/radioddity-download

Actions #44

Updated by R D 11 months ago

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

Actions #45

Updated by Joseph Chambers 11 months ago

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.

Actions #46

Updated by Joseph Chambers 11 months ago

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.

Actions #47

Updated by Joseph Chambers 11 months ago

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.

Actions #48

Updated by Ron Kimball 9 months ago

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

Actions #49

Updated by Alex Martin 8 months ago

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.

Actions #50

Updated by Alexandru Barbur 6 months ago

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.

Actions

Also available in: Atom PDF