-
Notifications
You must be signed in to change notification settings - Fork 46
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
Comments
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, 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. |
Hello, |
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: 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. |
@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 |
Perfect, all I needed. |
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 |
Here's the output of lsusb: |
Ok, thanks. As I do not own such a device, can someone checkout the rt73 branch and run
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 |
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 |
ok, this looks more like it. Here's the new response. $ ./dmrconf --verbose detect |
Mhh, looks like an error of mine. I am on it. |
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. $ ./dmrconf --verbose detect |
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
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: Here's what I get with the cable connected to the PC but the radio disconnected: 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
<#165 (comment)>,
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
<#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
<#165 (comment)>,
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
> <#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
> <#165 (comment)>,
> 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 |
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
<#165 (comment)>,
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:
***@***.***>
|
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? |
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
<#165 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AARIHYONSK7EJ2M62WZGHATVZ2BLHANCNFSM5HEUEU6A>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
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'. I also tried building the RT73 branch but I just noticed above that maybe I should try the Interface branch instead. |
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. |
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
<#165 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AARIHYJWSRQV2GGZ2QNWDSTVZ6RPFANCNFSM5HEUEU6A>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
$ dmrconf -V --radio RT73 --device /dev/ttyUSB0 -b read test.bin $ dmrconf --verbose detect $ dmrconf --radio RT73 --device /dev/ttyUSB0 --verbose detect 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. |
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
<#165 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AARIHYLKUN3PKRBGLJC77PLVZ6WPRANCNFSM5HEUEU6A>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Oh . . . Hi again. 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. |
Also ref in #381 (as the GD-88) |
I will receive the Retevis RT73 radio sometime this week. What is needed to add support for these?
The text was updated successfully, but these errors were encountered: