Baofeng DM-32 --> OpenDM-32

BTECH PC03 cable to work with the DM-32

FTDIBUS\COMPORT&VID_0403&PID_6001 ?

Один пользователь Facebook поделился своим опытом использования этих двух кабелей; эта информация может быть полезна:
https://www.facebook.com/groups/365615604322681/?multi_permalinks=2034600574090834

Заводская прошивка (OEM)
FTDI позволяет сохранить резервную копию заводской прошивки с помощью программы OO8UV.
CH340 не позволяет сохранить резервную копию заводской прошивки.

OpenGD77
Оба типа кабелей позволяют записывать прошивку OpenGD.

Кодплаг
FTDI позволяет записывать кодплаги, но не может их считывать (возникает ошибка «index out of array»).
CH340 без проблем считывает и записывает кодплаги.

Прошу прощения за качество перевода Google.

У меня есть наблюдение касательно того, что OpenGD CPS не может считать кодеплаг с радиостанции. Моя DM32 пришла в комплекте с кабелем для программирования на чипе CH340, и я не мог использовать его для создания бэкапа заводской прошивки с двух чипов памяти. Поэтому я взял свой кабель на FTDI, который использую с другими станциями, и с его помощью залил прошивку OpenGD DM32. Всё прошло отлично. Запись кодеплага через FTDI-кабель тоже, вроде бы, работала нормально. Но вот при попытке считать кодеплаг через FTDI я постоянно натыкаюсь на ошибку «array index out of bounds» (выход индекса за пределы массива). Если же я переключаюсь на родной CH340-кабель из комплекта, то кодеплаг считывается со станции без каких-либо ошибок. После этого я проверил заливку прошивки и запись кодеплага через кабель CH340 — это тоже сработало без проблем. Подумал, что эти наблюдения пригодятся для дальнейшего поиска и устранения проблемы. Просто пытаюсь внести свой вклад. Буду тестировать дальше. На следующей неделе мне как раз должен прийти 008UV, потестирую еще и на нём.

My CH340 works with the python code, but you have to do this very fast:

0) Turn off your radio, unplug your cable
1) run the script, it will show you a prompt to connect the radio
2) with the RADIO OFF, plug the cable and IMMEDIATELY turn it on... any noticeable delay will result in an error

У меня есть наблюдение касательно того, что OpenGD CPS не может считать кодеплаг с радиостанции.

Да, есть зависимость от применяемого кабеля. Для тестов я использую CH340 и FTDI и имею аналогичные проблемы как у тебя. В процессе изучения проблеммы и тестов...

As far as I can tell, as soon as you plug the cable with the radio off there is a small burst of serial data and a very tight time window to turn the radio on. I don't know what kind of data exchange there is, but it seems like the current process depends a lot on your ability to do that very fast.

У меня есть наблюдение касательно того, что OpenGD CPS не может считать кодеплаг с радиостанции.

Да, есть зависимость от применяемого кабеля. Для тестов я использую CH340 и FTDI и имею аналогичные проблемы как у тебя. В процессе изучения проблеммы и тестов...

As far as I can tell, as soon as you plug the cable with the radio off there is a small burst of serial data and a very tight time window to turn the radio on. I don't know what kind of data exchange there is, but it seems like the current process depends a lot on your ability to do that very fast.

Ребята, используя кабель Baofeng с чипом CH340, мне удалось сделать резервную копию флэш-памяти следующим образом:

1. Перед использованием OpenUV008, считайте данные с радиостанции DM-32 с помощью CPS.

2. При открытой и свернутой программе CPS откройте программу OpenUV008.

3. Выключите радиостанцию.

4. В OpenUV008 нажмите «ЧИТАТЬ», назовите файл (GD25Q16) и сохраните его, затем включите радиостанцию.

5. Повторите ту же процедуру для файла GD25Q128.

Надеюсь, это поможет. 73 PY5CV Сезар

1. In mass-produced transceivers, the initial firmware update process occurs via the JTAG interface. This takes much less time and doesn't require a serial interface.
2. The cable with the CH340 chip works correctly with the original Baofeng bootloader and CPS, but is unable to work with the HR_C7000 internal bootloader. I tested several cable revisions with different circuitry (with and without a quartz crystal, with and without additional transistors, with different TTL levels). In my case, none of the versions could access the HR_C7000 internal bootloader.
3. The cable with the FTDI chip works without problems with the HR_C7000 internal bootloader, but has problems reading the codeplugs in the CPS.
4. Testing was conducted on Windows 10 and 11 operating systems.

Summary of the above: The cable on the FTDI chip may be needed only for obtaining backup copies of flash memory, and the cable on the CH340 chip is used for basic work with updating firmware and writing/reading codeplugs.

I wish I spoke more than three words of Russian so I could properly participate here. I was able to make an account, but I can't seem to log in while using Google Translate so I'll just to make do.

I'm l big fan of digital voice modes and while I possess DMR radios from many companies (Baofeng, Motorola, Vertex, Cotre, Anytone, etc.) I'm of the opinion that there is no finer DMR handheld than a TYT MD-UV390/380 running OpenGD77. I quite enjoy the original DM-32, in spite of a few serious flaws. (Buggy CPS, no promiscuous mode, etc.) So I was really pleased to find that somebody had put in the work to port this wonderful firmware to it! In fact, the moment I learned of it, I bought a second DM-32 just to try it out.

I'd like to point out a few issues I've come across, not as a criticism but in the hope that they may help with the development process.

1 - Most importantly, I've found that radio will not always attempt to negotiate a connection with my DMR hotspots. The xmit light comes on and it does transmit a DMR signal, but the "handshaking" process never occurs and the call times out. A power off/on cycle will sometimes correct this, if not I have to remove the battery for a few seconds before I can connect again. I'm sure it's not an issue with my WPSD hotspots as I never see anything like this with my other radios.

2 - DCS encoding doesn't seem to work. My Allstar node is setup with DCS filtering on the input and works well, but when sending the appropriate code from the OpenDM32 equipped radio the node does not respond. Testing shows that other (analog of course) radios do not open their squelch in response to DCS from the DM32, so it's nothing to do with my node. CTCSS seems to work just fine.

3 - Lots of people have noticed that the the DMR user ID database can be loaded in it's entirety, but the radio doesn't ever display it in response to incoming calls. Some say it only displays DMR ID numbers, but I typically get the number, the callsign and sometimes a partial name while another DMR radio receiving the same signal will receive number, call, full name as well as location. My impression is that's it's merely falling back on Talker Alias data, which may or may not be present in the signal. Skimming though your forum leads me to believe that this is a known issues but I thought I'd throw my experiences into the mix.

Again, I apologize for not speaking your language but the OpenDM77 port has created a bit of a stir here in the United States and I'm sure sales of these radios is booming! I'm guessing a lot of members her speak English, sadly most Americans never learn a second language...I do speak a fair bit of Spanish. But I'd to express my appreciation for those who did the hard work of creating this version and let you know that many hams in "The States" are eagerly following it's development. If feedback and bug reports are welcome, I'm always happy to help in any way I can.

Cheers es 73,
Larry KC6WOG