Progress of opengd77 on DM1702

SP2ONG
Posts: 45
Joined: Sat Nov 16, 2019 9:47 am

Re: Progress of opengd77 on DM1702

Post by SP2ONG » Fri Mar 17, 2023 6:58 pm

Good luck :D

EA7KFF
Posts: 10
Joined: Wed Nov 20, 2019 9:18 am

Re: Progress of opengd77 on DM1702

Post by EA7KFF » Fri Mar 17, 2023 7:38 pm

Hi, I have a decrypted one. I don't know if it's worth it.
73

YO3VTH
Posts: 19
Joined: Sun Jun 21, 2020 8:59 pm

Re: Progress of opengd77 on DM1702

Post by YO3VTH » Sun May 14, 2023 1:53 pm

https://www.twowayradioforum.com/t/baof ... x-dmr/7249
Here discussion about DM-X/1702/1702B (proud owner) :lol:

OK2MOP
Posts: 61
Joined: Sat Jun 17, 2023 1:21 pm

Re: Progress of opengd77 on DM1702

Post by OK2MOP » Wed Jul 19, 2023 9:09 am

Just a few comments if anybody is still considering the porting/reverse engineering it from an owner of several of these radios and a person who extracted the stock firmware from the radios, wrote a flashing tool in Python, and mapped some of the codeplug memory:

There have been experiments with alternative firmware without DMR for this radio, which partly works (not by me). HW is similar to RT3s, but there are two possible issues which may prevent you from finishing the port:
  • It seems the radios (including its RT72 variant) are now discontinued
  • There seem to be two versions of the model (-V1 and -V2). All radios I had have V1 bootloader and it is possible somebody bricked theirs V2 using the V1 bootloader code from the report.
  • There are no Left/Right buttons and there is no rotary encoder, so the button mapping for usage would have to be redesigned against other OpenMDUV380 like radios
  • The memory structure of the radio (V1) uses sectors where last byte in each sector identifies the sector type ID (probably to ensure wear-leveling and/or journaling of sectors), so the factory calibration values would be placed randomly in codeplug part of SPI flash memory - again, this section would have to be found first by the firmware and copied/moved to some fixed point, or a data file with the stock CPS would have to be loaded which contains the calibration data always on the same position instead. Also the type of calibration data points differs from the other radios, and frequencies are recorded in it in BCD (binary coded decimal) format. For the structure of calibration data I was able to identify in CPS data file refer to the attached image, offsets in the sector are the same, but subtract 0x2000 from the offset (L1* and H1* values are the power settings like those in OpenGD77 for 1/5W) but the chosen frequency for calibration point is not clear.
  • As a side note, the firmware code starts at 0x8008000 not at 0x800C000 like in MDUV380-like radios (plus at 0x8004000 there is a block with some model information, anti-clonning checksum of CPU ID, etc.).
Attachments
DMX-caldata.png
DMX-caldata.png (148.97 KiB) Viewed 751 times

VK3KYY
Posts: 7478
Joined: Sat Nov 16, 2019 3:25 am
Location: Melbourne, Australia

Re: Progress of opengd77 on DM1702

Post by VK3KYY » Wed Jul 19, 2023 9:31 am

OK2MOP wrote:
Wed Jul 19, 2023 9:09 am
Just a few comments if anybody is still considering the porting/reverse engineering it from an owner of several of these radios and a person who extracted the stock firmware from the radios, wrote a flashing tool in Python, and mapped some of the codeplug memory:

There have been experiments with alternative firmware without DMR for this radio, which partly works (not by me). HW is similar to RT3s, but there are two possible issues which may prevent you from finishing the port:
  • It seems the radios (including its RT72 variant) are now discontinued
  • There seem to be two versions of the model (-V1 and -V2). All radios I had have V1 bootloader and it is possible somebody bricked theirs V2 using the V1 bootloader code from the report.
  • There are no Left/Right buttons and there is no rotary encoder, so the button mapping for usage would have to be redesigned against other OpenMDUV380 like radios
  • The memory structure of the radio (V1) uses sectors where last byte in each sector identifies the sector type ID (probably to ensure wear-leveling and/or journaling of sectors), so the factory calibration values would be placed randomly in codeplug part of SPI flash memory - again, this section would have to be found first by the firmware and copied/moved to some fixed point, or a data file with the stock CPS would have to be loaded which contains the calibration data always on the same position instead. Also the type of calibration data points differs from the other radios, and frequencies are recorded in it in BCD (binary coded decimal) format. For the structure of calibration data I was able to identify in CPS data file refer to the attached image, offsets in the sector are the same, but subtract 0x2000 from the offset (L1* and H1* values are the power settings like those in OpenGD77 for 1/5W) but the chosen frequency for calibration point is not clear.
  • As a side note, the firmware code starts at 0x8008000 not at 0x800C000 like in MDUV380-like radios (plus at 0x8004000 there is a block with some model information, anti-clonning checksum of CPU ID, etc.).

Thanks.

Very interesting.

However, I don't know of anyone working on firmware for this radio, and any future ports of the firmware would most likely only to be in radios which are currently in production, as its very difficult to find second hand DMR radios, probably because even if people are not using them, their value is so low that its not worth the trouble of trying to sell them.

Post Reply