search

hmatuschek / qdmr

A GUI application for configuring and programming cheap DMR radios under Linux and MacOS X.
https://dm3mat.darc.de/qdmr/
GNU General Public License v3.0
223 stars 46 forks source link

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

Open clewisit opened 3 years ago

clewisit commented 3 years ago

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

hmatuschek commented 3 years ago

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.

clewisit commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

hmatuschek commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

Perfect, all I needed.

hmatuschek commented 2 years ago

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 commented 2 years ago

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

hmatuschek commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

hmatuschek commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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: @.***>

hmatuschek commented 2 years ago

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 commented 2 years ago

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: @.***>

davidmpye commented 2 years ago

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: @.***>

hmatuschek commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

Hi Hannes,

I think that's probably the best thing to do for this radio - given that the USB ids are just those of a USB-serial converter, it's definitely the safest option.

If I get a chance, I will see what happens with a double read-codeplug command- I expect it'll just error, or timeout.

Cheers

David

On Thu, 13 Jan 2022 at 08:21, Hannes Matuschek @.***> wrote:

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.

— Reply to this email directly, view it on GitHub https://github.com/hmatuschek/qdmr/issues/165#issuecomment-1011902284, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARIHYITBH5CEFSWKFXCK4DUV2DQVANCNFSM5HEUEU6A . 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: @.***>

ben-kuhn commented 2 years ago

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 commented 2 years ago

Is it not just supported now?

On Thu, 18 Aug 2022, 21:55 Ben Kuhn, @.***> wrote:

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?

— Reply to this email directly, view it on GitHub https://github.com/hmatuschek/qdmr/issues/165#issuecomment-1219832885, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARIHYONSK7EJ2M62WZGHATVZ2BLHANCNFSM5HEUEU6A . You are receiving this because you were mentioned.Message ID: @.***>

ben-kuhn commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

For the rt73 you need to specify the serial port, not rely on auto probe.

David

On Fri, 19 Aug 2022, 18:25 Ben Kuhn, @.***> wrote:

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.

— Reply to this email directly, view it on GitHub https://github.com/hmatuschek/qdmr/issues/165#issuecomment-1220805247, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARIHYJWSRQV2GGZ2QNWDSTVZ6RPFANCNFSM5HEUEU6A . You are receiving this because you were mentioned.Message ID: @.***>

ben-kuhn commented 2 years ago

$ 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 commented 2 years ago

Hmm,

Well, I'm the rt73-utils guy, so if that works, good news :-)

We'll have to wait to hear from Hannes then :-)

David

On Fri, 19 Aug 2022, 19:08 Ben Kuhn, @.***> wrote:

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

$ dmrconf --verbose detect Debug in @.: Autodetect radios. Debug in @.: Search for serial port with matching VID:PID 28e9:18a. Debug in @.: Search for serial port with matching VID:PID 1fc9:94. Debug in @.: Search for HID interfaces matching VID:PID 15a2:73. Debug in @.: Search for DFU devices matching VID:PID 483:df11. ERROR in @.: No matching USB devices are found. Check connection?

$ dmrconf --radio RT73 --device /dev/ttyUSB0 --verbose detect Debug in @.: Autodetect radios. Debug in @.: Search for serial port with matching VID:PID 28e9:18a. Debug in @.: Search for serial port with matching VID:PID 1fc9:94. Debug in @.: Search for HID interfaces matching VID:PID 15a2:73. Debug in @.: Search for DFU devices matching VID:PID 483:df11. ERROR in @.: 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.

— Reply to this email directly, view it on GitHub https://github.com/hmatuschek/qdmr/issues/165#issuecomment-1220847442, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARIHYLKUN3PKRBGLJC77PLVZ6WPRANCNFSM5HEUEU6A . You are receiving this because you were mentioned.Message ID: @.***>

clewisit commented 2 years ago

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 commented 1 year ago

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