qdmr
qdmr copied to clipboard
hmatuschek
Support for Retevis RT73/Radioddity DB25-D/Kydera CDR-300UV
I will receive the Retevis RT73 radio sometime this week. What is needed to add support for these?
I need to know to which radio this one is related to and I may need a wireshark capture of the original CPS reading and writing a codeplug as well as (if supported) a call-sign DB. From this I can start to reverse engineer the codeplug and implementing the support. A single week is certainly tight.
Hi, Please don't misunderstand. I'm just saying I will receive the radio this week. I'm willing to provide you with data from the radio so you can add support for it. You can take as long as you want to work on it. I'm sure many Retevis and Radioddity users (including myself) will be grateful to you.
Once I get the radio, I will download from CPS and send you the file. Please let me know where I should upload that file. I will try to find information on wireshark. If you have any specific instructions for capturing wireshark data that you would like me to follow, please let me know.
No worries. However, I certainly need the wireshark captures to verify the memory addresses the codeplug is written to. Wireshark (https://www.wireshark.org/) is a tool usually used to monitor and analyze network packets. It also can capture USB traffic. With this I can analyze how the manufacturer CPS talks to the radio.
Thanks for the captures. This is going to be very interesting! At the first glance, the codeplug and transfer does not look like any other radio I had in my hands.
But good news, they use a USBSerial protocol, this allows in principle to write a small script that emulates the device once I understood the protocol. Then, I can easily reverse engineer the codeplug format without having a device at hand.
I'm glad that worked. I have never captured wireshark data before, and I'm running CPS through wine on ubuntu. I just read the default information on the radio and wrote it directly back. Let me know if you need any other information. I'm still building my codeplug, I only have some zones and channels created. I have not loaded any contacts yet.
Hi there. I finally got around to loading contacts into my radio, and it looks like this is a completely separate process from loading the rest of the codeplug. I'm not sure if that's how other radios work. Do you need that file and another wireshark capture for loading contacts?
Yes, that would be very helpful. Also, where do I find the contact upload tool? I haven't found such an option in the CPS.
Hi. Here is the wireshark capture of writing my updated codeplug, writing 16-byte contacts (ID and callsign only), and writing 128-byte contacts (ID, callsign, name, location). I have included my updated codeplug and the australian contacts that I loaded.
I'm not sure what you mean by the contact upload tool. I was able to download contacts from here: https://www.ailunce.com/ResourceCenter
I unzipped and imported that into CPS and then hit the write button. I cant confirm whether it saves the contacts in the codeplug. Contacts don't always appear after i save and reopen the codeplug. I did save the codeplug after importing the contacts, so let me know if that is what you needed. rt73 codeplug contacts wireshark.zip
@hmatuschek Not sure exactly how far you are in reverse engineering this, but a fellow member of our local hackspace did a pretty good job of this a bit ago: https://github.com/davidmpye/RT73-utils
I've started the implementation of the codeplug in the rt73 branch. Unfortunately, the enumeration phase was not capture. So I need the VID:PID of the radio to identify which serial port is associated with this device. A simple call to lsusb while the radio is connected does the trick.
Here's the output of lsusb: Bus 005 Device 002: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Ok, thanks. As I do not own such a device, can someone checkout the rt73 branch and run
dmrconf --verbose detect
It should now detect the RT73 and thus verifying the implemented interface to the device. I'll then implement the codeplug.
Here's what I get:
$ ./dmrconf --verbose detect Debug in dfu_libusb.cc@39: Try to detect USB DFU interface 483:df11. ERROR in dfu_libusb.cc@50: Cannot open device 483:df11. ERROR in tyt_interface.cc@11: Cannot open TyTInterface. Debug in hid_libusb.cc@12: Try to detect USB HID interface 15a2:73. ERROR in hid_libusb.cc@27: Cannot find USB device 15a2:73. Debug in usbserial.cc@11: Try to detect USB serial interface 1fc9:94. ERROR in usbserial.cc@36: No serial port found with 1fc9:94. Debug in usbserial.cc@11: Try to detect USB serial interface 28e9:18a. ERROR in usbserial.cc@36: No serial port found with 28e9:18a. Debug in usbserial.cc@11: Try to detect USB serial interface 67b:2303. Debug in usbserial.cc@21: Found serial port 67b:2303: ttyUSB0 'USB-Serial Controller'. Debug in usbserial.cc@41: Openend serial port ttyUSB0 with 115200baud. ERROR in kydera_interface.cc@327: Cannot read response: Unknown error ERROR in kydera_interface.cc@88: Cannot identify Kydera device. ERROR in radio.cc@492: Cannot connect to radio. ERROR in detect.cc@17: No compatible radio found:
Thanks, this is kind of bad. The problem with this radio is, that it does not identifies itself before the actual codeplug read/write. As qdmr supports multiple radios, I actually need to know which radio I am talking to, before I start to write to or read from it.
So I tried a hacky thing: I start to read the codeplug, but only request a single block. With this, I know which radio I talk to. But unfortunately, it appears like the radio does not like that.
I've pushed a version to the rt73 branch that contains a more detailed error message. Maybe it helps to find the issue.
I don't see any change, but just to make sure I didn't do anything wrong, I'm going to delete my folder and clone this branch again.
$ ./dmrconf --verbose detect Debug in dfu_libusb.cc@39: Try to detect USB DFU interface 483:df11. ERROR in dfu_libusb.cc@50: Cannot open device 483:df11. ERROR in tyt_interface.cc@11: Cannot open TyTInterface. Debug in hid_libusb.cc@12: Try to detect USB HID interface 15a2:73. ERROR in hid_libusb.cc@27: Cannot find USB device 15a2:73. Debug in usbserial.cc@11: Try to detect USB serial interface 1fc9:94. ERROR in usbserial.cc@36: No serial port found with 1fc9:94. Debug in usbserial.cc@11: Try to detect USB serial interface 28e9:18a. ERROR in usbserial.cc@36: No serial port found with 28e9:18a. Debug in usbserial.cc@11: Try to detect USB serial interface 67b:2303. Debug in usbserial.cc@21: Found serial port 67b:2303: ttyUSB0 'USB-Serial Controller'. Debug in usbserial.cc@41: Openend serial port ttyUSB0 with 115200baud. ERROR in kydera_interface.cc@327: Cannot read response: Unknown error ERROR in kydera_interface.cc@88: Cannot identify Kydera device. ERROR in radio.cc@492: Cannot connect to radio. ERROR in detect.cc@17: No compatible radio found:
ok, this looks more like it. Here's the new response.
$ ./dmrconf --verbose detect Debug in dfu_libusb.cc@39: Try to detect USB DFU interface 483:df11. ERROR in dfu_libusb.cc@50: Cannot open device 483:df11. ERROR in tyt_interface.cc@11: Cannot open TyTInterface. Debug in hid_libusb.cc@12: Try to detect USB HID interface 15a2:73. ERROR in hid_libusb.cc@27: Cannot find USB device 15a2:73. Debug in usbserial.cc@11: Try to detect USB serial interface 1fc9:94. ERROR in usbserial.cc@36: No serial port found with 1fc9:94. Debug in usbserial.cc@11: Try to detect USB serial interface 28e9:18a. ERROR in usbserial.cc@36: No serial port found with 28e9:18a. Debug in usbserial.cc@11: Try to detect USB serial interface 67b:2303. Debug in usbserial.cc@21: Found serial port 67b:2303: ttyUSB0 'USB-Serial Controller'. Debug in usbserial.cc@41: Openend serial port ttyUSB0 with 115200baud. ERROR in kydera_interface.cc@336: Unpexected response: ERROR in kydera_interface.cc@88: Cannot identify Kydera device. ERROR in radio.cc@492: Cannot connect to radio. ERROR in detect.cc@17: No compatible radio found:
Ok, if you like retry. The issue was, that I get an empty response (of cause) if I read from a non-blocking device immediately after sending the request. Now, there is a timeout of 1000ms.
Got something this time. Also I get the "Flash Read" message on the radio for about 5 seconds. Here's the output:
$ ./dmrconf --verbose detect Debug in dfu_libusb.cc@39: Try to detect USB DFU interface 483:df11. ERROR in dfu_libusb.cc@50: Cannot open device 483:df11. ERROR in tyt_interface.cc@11: Cannot open TyTInterface. Debug in hid_libusb.cc@12: Try to detect USB HID interface 15a2:73. ERROR in hid_libusb.cc@27: Cannot find USB device 15a2:73. Debug in usbserial.cc@11: Try to detect USB serial interface 1fc9:94. ERROR in usbserial.cc@36: No serial port found with 1fc9:94. Debug in usbserial.cc@11: Try to detect USB serial interface 28e9:18a. ERROR in usbserial.cc@36: No serial port found with 28e9:18a. Debug in usbserial.cc@11: Try to detect USB serial interface 67b:2303. Debug in usbserial.cc@21: Found serial port 67b:2303: ttyUSB0 'USB-Serial Controller'. Debug in usbserial.cc@41: Openend serial port ttyUSB0 with 115200baud. ERROR in usbserial.cc@67: Serial port error: (12) Operation timed out. ERROR in kydera_interface.cc@402: Cannot read from device: Timeout. ERROR in kydera_interface.cc@403: Incomplete data: ''. ERROR in kydera_interface.cc@333: Cannot receive response for read command. ERROR in kydera_interface.cc@88: Cannot identify Kydera device. ERROR in radio.cc@492: Cannot connect to radio. ERROR in detect.cc@17: No compatible radio found:
Unless I overlooked something very obvious, the device may not like my idea of reading a single codeplug block to identify the radio or I do not understand the way the read command works.
To my understanding, the first command send to the device is
0 1 2 3 4 5 6 7 8 9 a b c d e f
+----+----+----+----+----+----+----+----+----+----+----+----+----+----+----+----+
00 | 'Flash Read ' ASCII | 00 | 3c | 00 | 00 | 00 |
+----+----+----+----+----+----+----+----+----+----+----+----+----+----+----+----+
10 | 00 | #Blocks | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 |
+----+----+----+----+----+----+----+----+----+----+----+----+----+----+----+
The bytes 0x11+0x12 encode the number of blocks to read in big-endian. I'll check if I have a off-by-one error here but if that fails, I do not know how to proceed here. Maybe David @davidmpye has an idea.
I have no idea if this will help you, but I decided to update and run it again. Once with the radio connected, and once without the radio connected but the cable still plugged into the PC.
Here's what I get with the radio connected: $ ./dmrconf --verbose detect Debug in dfu_libusb.cc@39: Try to detect USB DFU interface 483:df11. ERROR in dfu_libusb.cc@50: Cannot open device 483:df11. ERROR in tyt_interface.cc@11: Cannot open TyTInterface. Debug in hid_libusb.cc@12: Try to detect USB HID interface 15a2:73. ERROR in hid_libusb.cc@27: Cannot find USB device 15a2:73. Debug in usbserial.cc@11: Try to detect USB serial interface 1fc9:94. ERROR in usbserial.cc@36: No serial port found with 1fc9:94. Debug in usbserial.cc@11: Try to detect USB serial interface 28e9:18a. ERROR in usbserial.cc@36: No serial port found with 28e9:18a. Debug in usbserial.cc@11: Try to detect USB serial interface 67b:2303. Debug in usbserial.cc@21: Found serial port 67b:2303: ttyUSB0 'USB-Serial Controller'. Debug in usbserial.cc@41: Openend serial port ttyUSB0 with 115200baud. ERROR in usbserial.cc@67: Serial port error: (12) Operation timed out. ERROR in kydera_interface.cc@402: Cannot read from device: Timeout. ERROR in kydera_interface.cc@403: Incomplete data: ''. ERROR in kydera_interface.cc@333: Cannot receive response for read command. ERROR in kydera_interface.cc@88: Cannot identify Kydera device. ERROR in radio.cc@492: Cannot connect to radio. ERROR in detect.cc@17: No compatible radio found:
Here's what I get with the cable connected to the PC but the radio disconnected: $ ./dmrconf --verbose detect Debug in dfu_libusb.cc@39: Try to detect USB DFU interface 483:df11. ERROR in dfu_libusb.cc@50: Cannot open device 483:df11. ERROR in tyt_interface.cc@11: Cannot open TyTInterface. Debug in hid_libusb.cc@12: Try to detect USB HID interface 15a2:73. ERROR in hid_libusb.cc@27: Cannot find USB device 15a2:73. Debug in usbserial.cc@11: Try to detect USB serial interface 1fc9:94. ERROR in usbserial.cc@36: No serial port found with 1fc9:94. Debug in usbserial.cc@11: Try to detect USB serial interface 28e9:18a. ERROR in usbserial.cc@36: No serial port found with 28e9:18a. Debug in usbserial.cc@11: Try to detect USB serial interface 67b:2303. Debug in usbserial.cc@21: Found serial port 67b:2303: ttyUSB0 'USB-Serial Controller'. Debug in usbserial.cc@41: Openend serial port ttyUSB0 with 115200baud. ERROR in kydera_interface.cc@338: Device returned invalid response: 00000000000000000000000000000000000000000000 ERROR in kydera_interface.cc@88: Cannot identify Kydera device. ERROR in radio.cc@492: Cannot connect to radio. ERROR in detect.cc@17: No compatible radio found:
I don't know if this is normal, but it seems odd that it shows a timeout with the radio connected, but claims an invalid response when it's not connected.
Slightly OT, and a personal opinion, but I think it's crackers to be probing for radios by simply writing data to a user's USB serial ports, without any idea as to what is on the end of the usb serial device.
It could cause a user all sorts of problems, depending on what the device was and how it interpreted a 'radio probe'.... Imagine if it was an important USB-serial device, and it malfunctioned in a dangerous or self destructive way (eg a USB/serial controlled CNC machine!)
David
On Thu, 6 Jan 2022 at 18:11, clewisit @.***> wrote:
I have no idea if this will help you, but I decided to update and run it again. Once with the radio connected, and once without the radio connected but the cable still plugged into the PC.
Here's what I get with the radio connected: $ ./dmrconf --verbose detect Debug in @.: Try to detect USB DFU interface 483:df11. ERROR in @.: Cannot open device 483:df11. ERROR in @.: Cannot open TyTInterface. Debug in @.: Try to detect USB HID interface 15a2:73. ERROR in @.: Cannot find USB device 15a2:73. Debug in @.: Try to detect USB serial interface 1fc9:94. ERROR in @.: No serial port found with 1fc9:94. Debug in @.: Try to detect USB serial interface 28e9:18a. ERROR in @.: No serial port found with 28e9:18a. Debug in @.: Try to detect USB serial interface 67b:2303. Debug in @.: Found serial port 67b:2303: ttyUSB0 'USB-Serial Controller'. Debug in @.: Openend serial port ttyUSB0 with 115200baud. ERROR in @.: Serial port error: (12) Operation timed out. ERROR in @.: Cannot read from device: Timeout. ERROR in @.: Incomplete data: ''. ERROR in @.: Cannot receive response for read command. ERROR in @.: Cannot identify Kydera device. ERROR in @.: Cannot connect to radio. ERROR in @.***: No compatible radio found:
Here's what I get with the cable connected to the PC but the radio disconnected: $ ./dmrconf --verbose detect Debug in @.: Try to detect USB DFU interface 483:df11. ERROR in @.: Cannot open device 483:df11. ERROR in @.: Cannot open TyTInterface. Debug in @.: Try to detect USB HID interface 15a2:73. ERROR in @.: Cannot find USB device 15a2:73. Debug in @.: Try to detect USB serial interface 1fc9:94. ERROR in @.: No serial port found with 1fc9:94. Debug in @.: Try to detect USB serial interface 28e9:18a. ERROR in @.: No serial port found with 28e9:18a. Debug in @.: Try to detect USB serial interface 67b:2303. Debug in @.: Found serial port 67b:2303: ttyUSB0 'USB-Serial Controller'. Debug in @.: Openend serial port ttyUSB0 with 115200baud. ERROR in @.: Device returned invalid response: 00000000000000000000000000000000000000000000 ERROR in @.: Cannot identify Kydera device. ERROR in @.: Cannot connect to radio. ERROR in @.: No compatible radio found:
I don't know if this is normal, but it seems odd that it shows a timeout with the radio connected, but claims an invalid response when it's not connected.
— Reply to this email directly, view it on GitHub https://github.com/hmatuschek/qdmr/issues/165#issuecomment-1006806259, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARIHYKY3GCRP2ERIEFSY43UUXLORANCNFSM5HEUEU6A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID: @.***>
Actually not that OT at all. The Kydera CDR-300UV/Retevis RT73 appears to use a generic USB<->Serial chip in their cable. This explains the observation by @clewisit above. Even if the radio is not connected, the cable is detected.
For the automatic radio detection, I currently use the VID/PIDs of supported radios and probe only those interfaces (not only serial) that have a matching VID/PID. Indeed these IDs are not unique, especially for the RT73 using a generic chip. Although being convenient, this auto-detection method has also some other issues. I therefore opened a new issue addressing this #187.
Irrespective of the interface selection, I still need a way to identify which radio I am talking to before I actually read from or write to the device. I would assume that also other Kydera radios will use the same chip and protocol. I though the easiest way would be to read only the first block of the codeplug to receive the device information send as a response to the 'Read Flash' command.
Agree.
Because these radios use a generic USBserial interface IC, I don't think auto-detection (without asking the user, specifically, "Should I probe the device attached to /dev/ttyUSB0?" or similar) is a good idea.
Here's one idea you could try to detect the Kydera:
Send the usual "Read codeplug" command, and the radio will start sending blocks. If you don't ACK after the first block, the radio will timeout after maybe 20 seconds, if I recall. You can check the first block and confirm that it contains something that identifies the radio (as either CD-300UV or RT73) - I forget the exact strings, but I can query mine and see.
David
On Fri, 7 Jan 2022 at 11:53, Hannes Matuschek @.***> wrote:
Actually not that OT at all. The Kydera CDR-300UV/Retevis RT73 appears to use a generic USB<->Serial chip in their cable. This explains the observation by @clewisit https://github.com/clewisit above. Even if the radio is not connected, the cable is detected.
For the automatic radio detection, I currently use the VID/PIDs of supported radios and probe only those interfaces (not only serial) that have a matching VID/PID. Indeed these IDs are not unique, especially for the RT73 using a generic chip. Although being convenient, this auto-detection method has also some other issues. I therefore opened a new issue addressing this #187 https://github.com/hmatuschek/qdmr/issues/187.
Irrespective of the interface selection, I still need a way to identify which radio I am talking to before I actually read from or write to the device. I would assume that also other Kydera radios will use the same chip and protocol. I though the easiest was would be to read only the first block of the codeplug to receive the device information send as a response to the 'Read Flash' command.
— Reply to this email directly, view it on GitHub https://github.com/hmatuschek/qdmr/issues/165#issuecomment-1007349139, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARIHYLFEFW7GMQZQ2KNLFLUU3H3TANCNFSM5HEUEU6A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID: @.***>
BTW: I don't think it's safe to assume other radios from the same 'manufacturer' will speak the same language. A lot of these seem to be rebadged (eg radiooddity rebadge a lot of things that aren't actually made by them), so you might find things with the same name on, but are completely different internally, and CPS-wise...
David
On Fri, 7 Jan 2022 at 16:13, David Pye @.***> wrote:
Agree.
Because these radios use a generic USBserial interface IC, I don't think auto-detection (without asking the user, specifically, "Should I probe the device attached to /dev/ttyUSB0?" or similar) is a good idea.
Here's one idea you could try to detect the Kydera:
Send the usual "Read codeplug" command, and the radio will start sending blocks. If you don't ACK after the first block, the radio will timeout after maybe 20 seconds, if I recall. You can check the first block and confirm that it contains something that identifies the radio (as either CD-300UV or RT73) - I forget the exact strings, but I can query mine and see.
David
On Fri, 7 Jan 2022 at 11:53, Hannes Matuschek @.***> wrote:
Actually not that OT at all. The Kydera CDR-300UV/Retevis RT73 appears to use a generic USB<->Serial chip in their cable. This explains the observation by @clewisit https://github.com/clewisit above. Even if the radio is not connected, the cable is detected.
For the automatic radio detection, I currently use the VID/PIDs of supported radios and probe only those interfaces (not only serial) that have a matching VID/PID. Indeed these IDs are not unique, especially for the RT73 using a generic chip. Although being convenient, this auto-detection method has also some other issues. I therefore opened a new issue addressing this #187 https://github.com/hmatuschek/qdmr/issues/187.
Irrespective of the interface selection, I still need a way to identify which radio I am talking to before I actually read from or write to the device. I would assume that also other Kydera radios will use the same chip and protocol. I though the easiest was would be to read only the first block of the codeplug to receive the device information send as a response to the 'Read Flash' command.
— Reply to this email directly, view it on GitHub https://github.com/hmatuschek/qdmr/issues/165#issuecomment-1007349139, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARIHYLFEFW7GMQZQ2KNLFLUU3H3TANCNFSM5HEUEU6A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID: @.***>
A timeout of about 20s is relatively long. What happens if one sends the "read codeplug" command twice. Does it restart sending the blocks? If so, I can live with this, as the radio does not need to timeout before I can start with the actual codeplug up or download.
Concerning the manufacturer protocol issue. This is true, but I do not assume that. For now, I have only seen specific protocols being used with specific VID/PID pairs. This way, I at least know how to talk to the radio and to get it to identify itself. Once I know the specific device, I can assemble the binary codeplug for it.
For now, I have seen only few genuine different protocols: A weird USB-HID protocol (Radioddity), DFUse + extensions (TyT), 4 different USB-serial based ones (AnyTone, Kydera, OpenGD77, Cotre) and one complex homebrew raw USB (Hyera).
It appears that the protocol and the basic codeplug structure correlates heavily. That is, irrespective of the manufacturer, if I know the protocol I can relatively reliably determine how the binary codeplug will look like. This is not that surprising, as all these radios are based on some specialized radio-on-a-chip and I believe that the radio manufacturer will reuse some example code provided by the chip manufacturer for the CPS and firmware.
In the interface branch, I've implemented the means for selecting matching USB devices as well as the radio if it cannot be identified automatically. To this end, the RT73 will be marked as unsave as well as unidentifiable. That is, if a RT73 is connected, the user must specify/verify the USB device and must specify the particular radio (in this case the RT73). This way I do not need to identify the RT73 before any action is performed on the radio. I will then verify the user selection during codeplug read or write and abort the operation if there is a mismatch.