Baofeng DM-1701/Baofeng DM-1802/Retevis RT-84 running latest OpenMDUV380(openGD77)

[VK3KYY]

BTW.
Did you try the new CPS EXE?

I have not tried yet, I will test it at weekend. I guess there must be no problem, If you didn't forget to change the the output Encrypted file header text following " OutSecurityBin" from "MD-9600" to "DM1701"

CPS directly accesses the DFU client in the bootloader, (via the STM DFUSe driver) it just sends raw (encrypted) data

The only possibly difference is a Custom DFU command, that is required by both the MD9600 and UV380

Code: Select all

		private void SendCustomInitSequence(IntPtr hDevice)
		{
			UInt32 status = 0;
			byte[] customCommand = { 0x91, 0x31 }; // Custom DFU command specific to the MD9600/UV380, which enables reading and writing.

			if ((status = STDFU_SelectCurrentConfiguration(ref hDevice, 0, 0, 0)) == STDFU_NOERROR)
			{
				WaitForDeviceIdle(hDevice);

				if ((status = STDFU_Dnload(ref hDevice, customCommand, (uint)customCommand.Length, 0)) == STDFU_NOERROR)
				{
					WaitForDeviceIdle(hDevice);
				}
				else
				{
                    throw new Exception(FirmwareLoaderUI_STM32.StringsDict["UnableInitialiseRadio"] + " " + status.ToString("X8") + " (STDFU_Dnload)");
				}
			}
			else
			{
                throw new Exception(FirmwareLoaderUI_STM32.StringsDict["UnableInitialiseRadio"] + " " + status.ToString("X8") + " (STDFU_SelectCurrentConfiguration)");
			}
		}

If the Baofeng uses a different custom command, then the CPS would need to be changed, but I looked in RadioTool and I did not see any difference in this command for Baofeng radios.

RadioTool does have different "magic" number defined for the 1701, but I don't know the purpose of this data.
The "magic" number of the MD9600 is not 0x91,0x31 so the "magic" number in RadioTool must be for some other reason

However, I did not have time to analyse the RadioTool code to understand the purpose of that data

[VK3KYY]

Re: Source code

Yes. We will publish it.

The plan was to publish when the firmware was stable and had no major bugs.

Currently there are 2 known bugs

1. Some people report CTCSS + DTMF Tx is not working, but we can't find any problem with this
2. Loud noise from the speaker, when radio is in power saving operation, when radio is in the menus and a key / button is pressed.
I don't know what is causing this. Becuase the same problem does not occur on the VFO or Channel screen, when a key is pressed

Some features are not implemented yet.

1. Safe power on

probably some other features I did not check yet


Also, the code needs to be reviewed to remove unused functions, remove commented out functions etc, becuase at the moment the priority has been to publish some the Beta version and fix bugs, rather than to make the code acceptable to release


I think for Chinese etc version, you will need to make a completely separate version. The UI will need to be changed and also double byte text used, and possibly you will need to load the character map from Flash, and also write some utility to load the character map into Flash.

I know with the official GD77 firmware, the character map is read on the fly from Flash and possibly the same method would need to be used in these radios, because possibly the MCU ROM is not large enough to store all the characters.

I don't know how much ROM space remains unused in the UV380, the linker report is usually not accurate, becuase of the static block for the official firmware.

A lot of space in the ROM is wasted becuase we must merge all the official firmware after the address of the first AMBE function, and the AMBE functions are distributed throughout the official firmware binary, becuase the compiler / linker is not instructed to keep all the AMBE functions in one ROM section.

On the GD77 official firmware i have done detailed analysis of the location all the AMBE functions, but I have not had time to also analyse the location of all the AMBE data.

The linker usually puts global static data at the end of the ROM, but the AMBE functions are in the middle of the ROM.

Luckily in the official MD-9600 V5 firmware which we use as the 'donor' for both the MD9600 and UV380 the AMBE functions are at higher addresses in the binary, so there is more ROM available for our application at the start of the binary.

[VK3KYY]

Is DM-1802 still being manufactured.

I checked AliExpress

https://www.aliexpress.com/w/wholesale- ... -1802.html

But I don't find any DM-1802


DM-1701 does seem to be available

https://www.aliexpress.com/w/wholesale- ... -1701.html


I think I will try to sell two of my many GD-77 so I have money to buy a 1701 or 1802

[VK3KYY]

I ordered this

https://www.aliexpress.com/item/1005001917389029.html?

From Aliexpress

I now need to sell some GD77

[VK3KYY]

After a few days' research, Here is the keypad pinmap of DM1701/DM1802, as a comparison, I also put MDUV380 on it.

I will post a version later with revised key mapping

I modified the code

Code: Select all

#if defined(PLATFORM_MDUV380)
{
		{
				KEYPAD_ROW0_GPIO_Port,
				KEYPAD_ROW0_Pin,
				{
						{ LCD_D0_GPIO_Port, LCD_D0_Pin, KEY_1     },
						{ LCD_D1_GPIO_Port, LCD_D1_Pin, KEY_2     },
						{ LCD_D2_GPIO_Port, LCD_D2_Pin, KEY_3     },
						{ LCD_D3_GPIO_Port, LCD_D3_Pin, KEY_4     },
						{ LCD_D4_GPIO_Port, LCD_D4_Pin, KEY_5     },
						{ LCD_D5_GPIO_Port, LCD_D5_Pin, KEY_6     },
						{ LCD_D6_GPIO_Port, LCD_D6_Pin, KEY_0     },
						{ LCD_D7_GPIO_Port, LCD_D7_Pin, KEY_STAR  }
				}
		},
		{
				KEYPAD_ROW1_GPIO_Port,
				KEYPAD_ROW1_Pin,
				{
						{ LCD_D0_GPIO_Port, LCD_D0_Pin, KEY_GREEN },
						{ LCD_D1_GPIO_Port, LCD_D1_Pin, KEY_FRONT_UP    },
						{ LCD_D2_GPIO_Port, LCD_D2_Pin, KEY_FRONT_DOWN  },
						{ LCD_D3_GPIO_Port, LCD_D3_Pin, KEY_7     },
						{ LCD_D4_GPIO_Port, LCD_D4_Pin, KEY_8     },
						{ LCD_D5_GPIO_Port, LCD_D5_Pin, KEY_9     },
						{ LCD_D6_GPIO_Port, LCD_D6_Pin, KEY_HASH  },
						{ LCD_D7_GPIO_Port, LCD_D7_Pin, KEY_RED   }
				}
		},
		{
				KEYPAD_ROW2_GPIO_Port,
				KEYPAD_ROW2_Pin,
				{
						{ LCD_D0_GPIO_Port, LCD_D0_Pin, KEY_NONE },
						{ LCD_D1_GPIO_Port, LCD_D1_Pin, KEY_NONE    },
						{ LCD_D2_GPIO_Port, LCD_D2_Pin, KEY_NONE  },
						{ LCD_D3_GPIO_Port, LCD_D3_Pin, KEY_NONE     },
						{ LCD_D4_GPIO_Port, LCD_D4_Pin, KEY_NONE     },
						{ LCD_D5_GPIO_Port, LCD_D5_Pin, KEY_NONE     },
						{ LCD_D6_GPIO_Port, LCD_D6_Pin, KEY_NONE  },
						{ LCD_D7_GPIO_Port, LCD_D7_Pin, KEY_NONE   }
				}
		}
};
#elif defined(PLATFORM_DM1701)
{
		{
				KEYPAD_ROW0_GPIO_Port,
				KEYPAD_ROW0_Pin,
				{
						{ LCD_D0_GPIO_Port, LCD_D0_Pin, KEY_1     },
						{ LCD_D1_GPIO_Port, LCD_D1_Pin, KEY_4     },
						{ LCD_D2_GPIO_Port, LCD_D2_Pin, KEY_7     },
						{ LCD_D3_GPIO_Port, LCD_D3_Pin, KEY_STAR    },
						{ LCD_D4_GPIO_Port, LCD_D4_Pin, KEY_FRONT_UP     },
						{ LCD_D5_GPIO_Port, LCD_D5_Pin, KEY_RIGHT     },
						{ LCD_D6_GPIO_Port, LCD_D6_Pin, KEY_LEFT     },
						{ LCD_D7_GPIO_Port, LCD_D7_Pin, KEY_NONE  }
				}
		},
		{
				KEYPAD_ROW1_GPIO_Port,
				KEYPAD_ROW1_Pin,
				{
						{ LCD_D0_GPIO_Port, LCD_D0_Pin, KEY_2 },
						{ LCD_D1_GPIO_Port, LCD_D1_Pin, KEY_5    },
						{ LCD_D2_GPIO_Port, LCD_D2_Pin, KEY_8  },
						{ LCD_D3_GPIO_Port, LCD_D3_Pin, KEY_0     },
						{ LCD_D4_GPIO_Port, LCD_D4_Pin, KEY_FRONT_DOWN     },
						{ LCD_D5_GPIO_Port, LCD_D5_Pin, KEY_RED     },
						{ LCD_D6_GPIO_Port, LCD_D6_Pin, KEY_GREEN  },
						{ LCD_D7_GPIO_Port, LCD_D7_Pin, KEY_NONE   }
				}
		},
		{
				KEYPAD_ROW2_GPIO_Port,
				KEYPAD_ROW2_Pin,
				{
						{ LCD_D0_GPIO_Port, LCD_D0_Pin, KEY_3 },
						{ LCD_D1_GPIO_Port, LCD_D1_Pin, KEY_6    },
						{ LCD_D2_GPIO_Port, LCD_D2_Pin, KEY_9  },
						{ LCD_D3_GPIO_Port, LCD_D3_Pin, KEY_HASH     },
						{ LCD_D4_GPIO_Port, LCD_D4_Pin, KEY_NONE     },
						{ LCD_D5_GPIO_Port, LCD_D5_Pin, KEY_NONE     },
						{ LCD_D6_GPIO_Port, LCD_D6_Pin, KEY_NONE  },
						{ LCD_D7_GPIO_Port, LCD_D7_Pin, KEY_NONE   }
				}
		}
};
#endif

Perhaps you can check it..

Buttons SK1, SK2, SK3 aka P1,Mon are handled separately from the keymap, because in radios like the GD77 buttons SK1 and SK2 have decidated GPIO pins to each button, and the code is originally ported from the GD77 code

At the moment I think the functions of SK3 and SK2 will function as SK1 and SK2 (i.e reversed) but button SK1 on the 1701 will probably do nothing at the moment.


Also FYI. Because the UV380 code is a version of the MD9600 code, there is a separate definition for FRONT_PANEL UP and DOWN to Microphone Up and Down
i.e the code history is GD77 -> MD9600 -> UV380

In the case of the UV380 we are using FRONT_PANEL Up / Down events for the keys on the radio.

[VK3KYY]

If you already downloaded the CPS installer, please download it again, because there was a mistake.

I did not build the Release version which is used by the installer script, so some files were incorrect

I think it now works OK, because if I try to use the DM-1701 firmware loader option, the UV380 does not function and remains in the bootloader

[VK3KYY]

Please try this version

downloads/DM1701/Firmware/04f5e8eb0fb12 ... e139481835

Keyboard map is per the code I posted earlier

I have also changed the SK1 and SK2 function, so they should now work correctly

I did not have time yet to map SK3 to the Orange button. I may be able to do this later

Anyway, let me know whether the key mapping is now correct. It is definietly wrong if I use this firmware with my RT3S/UV380

[BD4VOW]

I ordered this

https://www.aliexpress.com/item/1005001917389029.html?

From Aliexpress

I now need to sell some GD77

That's expensive, here in china it costs less than 60 USD for a brand-new one including a fast delivery service, which will receive in less than 48 hours.

BTW, here is my next target, Baofeng DM-1702, which includes GPS.
https://www.aliexpress.us/item/32568046 ... zihjotoUEa

[VK3KYY]

I think AliExpress is cheaper than Radioddity.com but both are expensive because its selling to outside China where they can charge more and make more profit


Re: DM-1702

Is the encryption table know for this radio ?

It is not listed by RadioTool

If a firmware update is available for this radio, you may be able to brute force crack it to get the encrytion table. There are methods for this, but I don't know them.

Perhaps github md380tools has some scripts to brute force attack the encryption table if its the same size as the other radios.

[BD4VOW]

Is DM-1802 still being manufactured.

I checked AliExpress

https://www.aliexpress.com/w/wholesale- ... -1802.html

But I don't find any DM-1802

It was selling as DM-1802 in China, but refer to Baofeng's website http://gb.baofengradio.com/product/17/, it seems to be renamed as DM-1701B， that's more suitable, it is using exactly the same PCB with DM-1701. But BF is not selling this model, maybe only selling as other brand & model name。