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 RT73/Radioddity DB25-D/Kydera CDR-300UV #165

Open
clewisit opened this issue Nov 1, 2021 · 40 comments
Open

Support for Retevis RT73/Radioddity DB25-D/Kydera CDR-300UV #165

clewisit opened this issue Nov 1, 2021 · 40 comments
Assignees
Labels
NewDevice Request for support of a new device

Comments

@clewisit
Copy link

clewisit commented Nov 1, 2021

I will receive the Retevis RT73 radio sometime this week. What is needed to add support for these?

@hmatuschek
Copy link
Owner

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.

@hmatuschek hmatuschek added the NewDevice Request for support of a new device label Nov 1, 2021
@clewisit
Copy link
Author

clewisit commented Nov 1, 2021

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.

@hmatuschek
Copy link
Owner

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.

@clewisit
Copy link
Author

clewisit commented Nov 3, 2021

Hello,
Here are the files I promised
rt73 codeplug and wireshark.zip
.

@hmatuschek
Copy link
Owner

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.

@hmatuschek
Copy link
Owner

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.

@clewisit
Copy link
Author

clewisit commented Nov 4, 2021

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.

@clewisit
Copy link
Author

clewisit commented Nov 9, 2021

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?

@hmatuschek
Copy link
Owner

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.

@clewisit
Copy link
Author

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

@DanNixon
Copy link

@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

@hmatuschek
Copy link
Owner

Perfect, all I needed.

@hmatuschek
Copy link
Owner

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.

@clewisit
Copy link
Author

clewisit commented Jan 4, 2022

Here's the output of lsusb:
Bus 005 Device 002: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port

@hmatuschek
Copy link
Owner

hmatuschek commented Jan 5, 2022

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.

@clewisit
Copy link
Author

clewisit commented Jan 5, 2022

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:

@hmatuschek
Copy link
Owner

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.

@clewisit
Copy link
Author

clewisit commented Jan 5, 2022

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:

@clewisit
Copy link
Author

clewisit commented Jan 5, 2022

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:

@hmatuschek
Copy link
Owner

Mhh, looks like an error of mine. I am on it.

@hmatuschek
Copy link
Owner

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.

@clewisit
Copy link
Author

clewisit commented Jan 5, 2022

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:

@hmatuschek
Copy link
Owner

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.

@clewisit
Copy link
Author

clewisit commented Jan 6, 2022

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.

@davidmpye
Copy link

davidmpye commented Jan 6, 2022 via email

@hmatuschek
Copy link
Owner

hmatuschek commented Jan 7, 2022

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.

@davidmpye
Copy link

davidmpye commented Jan 7, 2022 via email

@davidmpye
Copy link

davidmpye commented Jan 7, 2022 via email

@hmatuschek
Copy link
Owner

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.

@hmatuschek
Copy link
Owner

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.

@davidmpye
Copy link

davidmpye commented Jan 13, 2022 via email

@hmatuschek hmatuschek self-assigned this Feb 5, 2022
@ben-kuhn
Copy link

I just received one of these radios today and would love to be able to use it with qdmr. Is there any additional testing or data collection that I could assist with for work to proceed on this model?

@davidmpye
Copy link

davidmpye commented Aug 18, 2022 via email

@ben-kuhn
Copy link

Maybe I'm being dense but if it is I sure can't seem to figure out how to read a codeplug. Here is the output:

ERROR in repeaterdatabase.cc@85: Cannot open repeater list '/home/frosty/.local/share/DM3MAT/qdmr/repeater.json'.
Debug in userdatabase.cc@124: Loaded user database with 223586 entries from /home/frosty/.local/share/DM3MAT/qdmr/user.json.
Debug in talkgroupdatabase.cc@140: Loaded talk group database with 1633 entries from /home/frosty/.local/share/DM3MAT/qdmr/talkgroups.json.
Debug in application.cc@96: Last known position:
ERROR in repeaterdatabase.cc@137: Cannot download repeater list: Error transferring https://repeatermap.de/api.php - server replied: Not Found
Debug in application.cc@390: Last device is invalid, search for new one.
Debug in usbserial.cc@162: Search for serial port with matching VID:PID 28e9:18a.
Debug in usbserial.cc@162: Search for serial port with matching VID:PID 1fc9:94.
Debug in hid_libusb.cc@128: Search for HID interfaces matching VID:PID 15a2:73.
Debug in dfu_libusb.cc@156: Search for DFU devices matching VID:PID 483:df11.
ERROR in application.cc@394: No matching devices found.
Debug in application.cc@390: Last device is invalid, search for new one.
Debug in usbserial.cc@162: Search for serial port with matching VID:PID 28e9:18a.
Debug in usbserial.cc@162: Search for serial port with matching VID:PID 1fc9:94.
Debug in hid_libusb.cc@128: Search for HID interfaces matching VID:PID 15a2:73.
Debug in dfu_libusb.cc@156: Search for DFU devices matching VID:PID 483:df11.
ERROR in application.cc@394: No matching devices found.

I also tried building the RT73 branch but I just noticed above that maybe I should try the Interface branch instead.

@ben-kuhn
Copy link

Looks like the interface branch no longer exists.

After doing more digging, and commenting out the checks to force the device select dialog to pop up, it would appear that the application is no longer looking for USB ID 067b:2303.

@davidmpye
Copy link

davidmpye commented Aug 19, 2022 via email

@ben-kuhn
Copy link

$ dmrconf -V --radio RT73 --device /dev/ttyUSB0 -b read test.bin
Debug in cli/autodetect.cc@40: Autodetect radios.
Debug in lib/usbserial.cc@162: Search for serial port with matching VID:PID 28e9:18a.
Debug in lib/usbserial.cc@162: Search for serial port with matching VID:PID 1fc9:94.
Debug in lib/hid_libusb.cc@128: Search for HID interfaces matching VID:PID 15a2:73.
Debug in lib/dfu_libusb.cc@156: Search for DFU devices matching VID:PID 483:df11.
ERROR in cli/autodetect.cc@44: No matching USB devices are found. Check connection?
ERROR in cli/readcodeplug.cc@28: Cannot detect radio: In autodetect.cc:44: No matching USB devices are found. Check connection?

$ dmrconf --verbose detect
Debug in cli/autodetect.cc@40: Autodetect radios.
Debug in lib/usbserial.cc@162: Search for serial port with matching VID:PID 28e9:18a.
Debug in lib/usbserial.cc@162: Search for serial port with matching VID:PID 1fc9:94.
Debug in lib/hid_libusb.cc@128: Search for HID interfaces matching VID:PID 15a2:73.
Debug in lib/dfu_libusb.cc@156: Search for DFU devices matching VID:PID 483:df11.
ERROR in cli/autodetect.cc@44: No matching USB devices are found. Check connection?

$ dmrconf --radio RT73 --device /dev/ttyUSB0 --verbose detect
Debug in cli/autodetect.cc@40: Autodetect radios.
Debug in lib/usbserial.cc@162: Search for serial port with matching VID:PID 28e9:18a.
Debug in lib/usbserial.cc@162: Search for serial port with matching VID:PID 1fc9:94.
Debug in lib/hid_libusb.cc@128: Search for HID interfaces matching VID:PID 15a2:73.
Debug in lib/dfu_libusb.cc@156: Search for DFU devices matching VID:PID 483:df11.
ERROR in cli/autodetect.cc@44: No matching USB devices are found. Check connection?

I have verified permissions on the serial port and even tried as root for good measure. I am able to download a codeplug with RT73-utils so from a hardware standpoint everything appears to work.

@davidmpye
Copy link

davidmpye commented Aug 19, 2022 via email

@clewisit
Copy link
Author

Oh . . . Hi again.
I was waiting for some indication that RT73 was supported, but never saw any further progress on this ticket or anything to test.

So, how is this supposed to work? I don't see anything in the UI to select the RT73 or it's serial port. The dmrconf commands that Ben used don't seem to work either.

@allesand
Copy link

Also ref in #381 (as the GD-88)

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

When branches are created from issues, their pull requests are automatically linked.

6 participants