Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for Retevis RT72/Baofeng DM-1702 #181

Open
DanNixon opened this issue Nov 29, 2021 · 9 comments
Open

Support for Retevis RT72/Baofeng DM-1702 #181

DanNixon opened this issue Nov 29, 2021 · 9 comments
Labels
NewDevice Request for support of a new device

Comments

@DanNixon
Copy link

I'd quite like support for the Retevis RT72. I do have one of these radios and could do testing/provide information as required.

@hmatuschek hmatuschek assigned hmatuschek and unassigned hmatuschek Nov 29, 2021
@hmatuschek hmatuschek added the NewDevice Request for support of a new device label Nov 29, 2021
@hmatuschek
Copy link
Owner

Sure, first I need to know how the device identifies itself. That is, can you install & run dmrconf, the command-line tool for qdmr.

dmrconf detect --verbose

If there is a message like "Unknown TyT device ...", we are off with a good start. In this case, the common DfuSE interface is used to communicate with the device and I do not need to implement the communication protocol blindly.

Anyway, I may still need a wireshark capture of the USB traffic with the device to verify the memory addresses the codeplug is written to. I may need a codeplug read and write as a separate capture. The codeplug content is not relevant here, so you can use the stock codeplug. If the radio also supports a call-sign DB, I need a capture of that as well. In fact I may need several captures of the call-sign DB uploads with varying sizes (e.g., one, two many entries) to reverse engineer the DB index format.

@DanNixon
Copy link
Author

I'll have to get the Wireshark captures later today, but for now...

> dmrconf detect --verbose
Debug in /home/dan/.cache/paru/clone/qdmr-git/src/qdmr/lib/dfu_libusb.cc@39: Try to detect USB DFU interface 483:df11.
ERROR in /home/dan/.cache/paru/clone/qdmr-git/src/qdmr/lib/tyt_interface.cc@11: DFUDevice Cannot open device 483, df11: 0 Success
Debug in /home/dan/.cache/paru/clone/qdmr-git/src/qdmr/lib/hid_libusb.cc@12: Try to detect USB HID interface 15a2:73.
Debug in /home/dan/.cache/paru/clone/qdmr-git/src/qdmr/lib/hid_libusb.cc@26: Cannot find USB device 15a2:73
Debug in /home/dan/.cache/paru/clone/qdmr-git/src/qdmr/lib/usbserial.cc@12: Try to detect USB serial interface 1fc9:94.
Debug in /home/dan/.cache/paru/clone/qdmr-git/src/qdmr/lib/usbserial.cc@12: Try to detect USB serial interface 28e9:18a.
ERROR in /home/dan/.cache/paru/clone/qdmr-git/src/qdmr/cli/detect.cc@17: No compatible radio found: detect(): No matching radio found.

lsusb shows the radio as: Bus 001 Device 006: ID 0483:5780 STMicroelectronics STM32 Virtual ComPort in FS Mode

@hmatuschek
Copy link
Owner

hmatuschek commented Nov 29, 2021

Thanks for the information. The bad news is, that the protocol is not implemented and I still need to reverse engineer it. The good news is, however, that it is likely a similar protocol like used by the RT73 (see #165). So I need the wireshark captures for sure to verify that. Being a serial-port over USB protocol, allows me to write an emulator script. With this I can then reverse engineer the binary codeplug format. Unfortunately, the codeplug file has nothing to do with the content being written to the device.

@hmatuschek
Copy link
Owner

BTW, the reverse engineering and development will happen in the rt73 branch (https://github.com/hmatuschek/qdmr/tree/rt73/doc/reveng/retevis/rt73) there is also the capture extraction script and the documentation of the current state.

@DanNixon
Copy link
Author

Here are the captures of writing and reading the default codeplug (or at least the demo one the CPS came with, the CPS save is also included).

rt72_usb_captures.zip

@hmatuschek
Copy link
Owner

OK, tanks a lot! I've just looked into it ant it appears to be an entirely different protocol. So the RT72 not not related at all to the RT73. Actually, it identifies itself as an DM1702, so I will implement it as that device in a new branch called dm1702.

@hmatuschek hmatuschek changed the title Support for Retevis RT72 Support for Retevis RT72/Baofeng DM-1702 Nov 29, 2021
@mr-sm1th
Copy link

mr-sm1th commented Dec 2, 2022

no progress on this in a year? :(

@mr-sm1th
Copy link

https://github.com/OK2MOP/MD1702-tools

software that can read and write codeplugs.
i think it partially documents the plugs too.

@allesand
Copy link

allesand commented Sep 28, 2023

Also ref in #199

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NewDevice Request for support of a new device
Projects
None yet
Development

No branches or pull requests

4 participants