Open DanNixon opened 2 years ago
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.
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
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.
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.
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).
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
.
no progress on this in a year? :(
https://github.com/OK2MOP/MD1702-tools
software that can read and write codeplugs. i think it partially documents the plugs too.
Also ref in #199
I'd quite like support for the Retevis RT72. I do have one of these radios and could do testing/provide information as required.