Support for radioddity gd73

[cbsousa]

I have a radioddity gd73. How can I get support. Are there any tests I can do to contribute?

[hmatuschek]

Yes, as I do not own this device, I need your help to figure out the VID/PID of the device (using lsusb while the device is connected).

Then I have to figure out the protocol used to communicate with the device. For this, I need a wireshark capture of the data send to and from the device while a codeplug read and write. See https://wiki.wireshark.org/CaptureSetup/USB on how to capture USB traffic. The content of the codeplug is not that important at that point. You can write and read the default codeplug.

If the device supports a call-sign DB. I may also need the captures of writing these call-signs to the device. Ideally writing only one, only two and many entries.

If you are lucky, the protocol is also used by a device that is already supported. Then I only need to figure out the codeplug format. This can usually be done using the binary codeplug files generated by the CPS. However, I will still need a wireshark capture to verify the memory addresses the CPS writes to.

[cbsousa]

Bus 001 Device 005: ID 1206:0227 HTMicroChip walkie-talkie-C7000

[hmatuschek]

OK, this will likely be a new protocol. However, an interesting one as the C7000 is a radio-on-a-chip that is used in many other devices.

[cbsousa]

ok. I neet to go to an windows and report you the wireshark connection. I do it soon.

[hmatuschek]

I've installed the manufacturer CPS and had a look at the binary codeplug files it creates. It appears like they simply store the stuff that gets written to the device (quiet common for Radioddity). This will make the reverse engineering of the codeplug much easier as I can do it without the device and with the CPS alone.

[cbsousa]

gd73-read and write.zip the wireshark file

[hmatuschek]

That was fast. Thanks. It is possible that the device registers itself as a USB Serial device? That is, lookout for a device like /dev/ttyACM0 or so appearing when plugging it in. If so, this makes the implementation much easier as I do not need to use libusb for raw USB access but rather can use the QSerialPort library for platform independent access to the device.

[hmatuschek]

Added gd73 branch for reverse engineering.

[cbsousa]

Well, I don't know how to test this. But, just say. I'm comfortable with using the linux terminal. If you need make some test with re radio connection i can do it. Or make test's from a alfa version. feel free to tell me

[cbsousa]

I don't now if is interesting, but that's my dmesg output 2495.389143] usb 1-3: new full-speed USB device number 5 using xhci_hcd [ 2505.932502] usb 1-3: device descriptor read/64, error -71 [ 2506.180777] usb 1-3: New USB device found, idVendor=1206, idProduct=0227, bcdDevice= 1.00 [ 2506.180786] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 2506.180790] usb 1-3: Product: walkie-talkie-C7000 [ 2506.180792] usb 1-3: Manufacturer: HTMicroChip [ 2506.180795] usb 1-3: SerialNumber: C86000886357FD716A1F2408 [ 2515.014725] audit: type=1100 audit(1642344796.744:141): pid=3021 uid=1000 auid=1000 ses=1 subj==unconfined msg='op=PAM:authentication grantors=pam_faillock,pam_permit,pam_faillock acct="cbsousa" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success' [ 2515.014861] audit: type=1101 audit(1642344796.744:142): pid=3021 uid=1000 auid=1000 ses=1 subj==unconfined msg='op=PAM:accounting grantors=pam_unix,pam_permit,pam_time acct="cbsousa" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success' [ 2515.015658] audit: type=1110 audit(1642344796.744:143): pid=3021 uid=1000 auid=1000 ses=1 subj==unconfined msg='op=PAM:setcred grantors=pam_faillock,pam_permit,pam_faillock acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success' [ 2515.018029] audit: type=1105 audit(1642344796.747:144): pid=3021 uid=1000 auid=1000 ses=1 subj==unconfined msg='op=PAM:session_open grantors=pam_systemd_home,pam_limits,pam_unix,pam_permit acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success'

[hmatuschek]

If the device is handled as a serial port by the kernel, it should also appear in /sys/class/tty when connected. If not, I need to talk to it using raw usb.

[cbsousa]

In /sys/class/tty i don't see any diference! But i'm not sure about what what should i see.

[hmatuschek]

Ok, then it is likely not identified as a serial port by the kernel.

[opie4624]

Anything I can contribute as well? I have two of these diminutive little guys.

[allesand]

Since one point for qdmr was support for "radios available for a small budget": the GD-73 sure has its limitations (quite a few), but it is the most affordable 70cm-DMR-Radio? There seems to be very little activity regarding firmware updates etc., but the radio is available, unlike other popular ones. I can also help testing&debugging. Since the Windows-CPS needs a special driver (and you have to follow the install order exactly), I would guess there is no serial port in the radio

[17416.721546] usb 2-1.2: new full-speed USB device number 9 using ehci-pci [17416.831549] usb 2-1.2: New USB device found, idVendor=1206, idProduct=0227, bcdDevice= 1.00 [17416.831572] usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [17416.831579] usb 2-1.2: Product: walkie-talkie-C7000 [17416.831584] usb 2-1.2: Manufacturer: HTMicroChip

Bus 002 Device 009: ID 1206:0227 HTMicroChip walkie-talkie-C7000

Maybe of interest: "The GD73 is the same radio as TYT MD-430" from https://www.facebook.com/groups/1013715902161167/

There is a discussion about high BER with recent firmware versions - could not determine, which versions are problematic, but suggestion is not to "upgrade" unless it is clear that the target version works, since not all versions are available online.

Product pages at https://www.radioddity.com/products/radioddity-gd-73a-e and https://www.tyt888.com/pro_info151.html (latest firmware there: https://radioddity.s3.amazonaws.com/2021-01-27_GD-73_v1.06_update_package.zip - but newly shipped radios come with "v1.11"!)

[allesand]

Also mentioned in https://github.com/hmatuschek/qdmr/discussions/371

" Offering Captures for Alinco DJ-MD5 & Radioddity GD-73A #371 "

@cbsousa and @opie4624 : dev and checklist here in #188

[hmatuschek]

Ok here is the todo-list:

• [x] Get the device
• [x] Reverse engineer protocol
• [ ] Implement protocol
  • [x] Implement codeplug read
  • [ ] Implement codeplug write
• [x] Reverse engineer codeplug (no device needed, rdt file is 1:1 written memory)
  • [x] Settings
  • [x] General settings
  • [x] Tone settings
  • [x] Button settings
  • [x] DMR settings
  • [x] Zones
  • [x] Channels
  • [x] Contacts
  • [x] Group lists
  • [x] Scan lists
  • [x] Encryption
  • [x] DTMF signaling
• [x] Implement codeplug
  • [x] Contacts
  • [x] Group lists
  • [x] Channels
  • [x] Zones
  • [x] Scan lists
  • [x] Extensions
  • [x] encoding
  • [x] decoding
• [ ] Tests

[allesand]

Current gd73 branch: which Linux device is qdmr trying to read/is it "raw USB access"?

Debug in lib/c7000device.cc@145: Try to detect USB C7000 interface USB C7000 HT: bus 1, device 5.
Debug in lib/c7000device.cc@159: Matching device found at bus 1, device 5 with vendor ID 1206 and product ID 227.
ERROR in lib/c7000device.cc@175: Cannot open device USB C7000 HT: bus 1, device 5: Access denied (insufficient permissions).
Speicherzugriffsfehler (Speicherabzug geschrieben)

With sudo:

Debug in lib/c7000device.cc@145: Try to detect USB C7000 interface USB C7000 HT: bus 1, device 5.
Debug in lib/c7000device.cc@159: Matching device found at bus 1, device 5 with vendor ID 1206 and product ID 227.
ERROR in lib/c7000device.cc@190: Failed to claim USB interface USB C7000 HT: bus 1, device 5: Resource busy.
Speicherzugriffsfehler

"Detect" works, reading does not yet.

[hmatuschek]

You need to update the 99-qdmr.rules file in /etc/udev/rules.d/ add the lines

# Radioddity GD-73A/E
SUBSYSTEM=="usb", ATTRS{idVendor}=="1206", ATTRS{idProduct}=="0227", MODE="660", GROUP="dialout"

And then reload the rules with

$  udevadm control --reload-rules && udevadm trigger

An updated udev rules file will be shipped with the release of the GD-73 support.

[allesand]

Editing the udev rules worked. So as a normal user I know get

Debug in lib/c7000device.cc@159: Matching device found at bus 1, device 7 with vendor ID 1206 and product ID 227.
ERROR in lib/c7000device.cc@190: Failed to claim USB interface USB C7000 HT: bus 1, device 7: Resource busy.
Speicherzugriffsfehler (Speicherabzug geschrieben)

when trying to read from the radio. "versions: V1.11" here also.

[hmatuschek]

Ok, the segfault is certainly a bug. However, that the resource is busy, is somewhat out of my control. Is there any other process that might want to talk to the device? Is there a VirtualBox running Windows with that pesky driver?

[allesand]

Short reminder for me: it's gvfs/fuse that sits in the way. When disabled, qdmr reads up to Debug in lib/gd73_interface.cc@86: Read 53bytes from address 21fdfh. stops at 99% and then shows a dialog that an unknown error has occurred. ToDo: Is there a "supported" way to tell gvfsd/fuse to leave that device alone? But - QRT for today..

Oh? Am I supposed to be able to edit the Checklist above? By accident I set the check at "decoding"!

[hmatuschek]

Probably also with udev, at least modem manager can be told to leave a device alone. But I don't know it. Concerning the transfer error: try increasing the delay in C7000Device::sendRecv.

[allesand]

The "just get reading the radio to work" way, at least on a Linux system: $ sudo kill $(ps -A | grep gvfs | awk '{print $1}') $ sudo killall gvfs

Delay: with s.th. like QObject().thread()->usleep(3000); ? Still gives an "Unknown error". But: I will just wait for some more code changes and see if that error persists.

[hmatuschek]

Do you know killall? Avoids the use of complicated grep/awk stuff to kill all instances of a program.

[hmatuschek]

Oh, wait. For now, decoding is not implemented yet. You can only read the binary codeplug using the command line tool. E.g.,

dmrconf --verbose read gd73_codeplug.dfu

[allesand]

Do you know killall? Avoids the use of complicated grep/awk stuff to kill all instances of a program.

You are very right. Should have thought of "killall", at least for all Linux systems the more robust way. On other Unix-type systems the result might not be the desired one, though :-) Oh, at least FreeBSD behaves the same way: https://man.freebsd.org/cgi/man.cgi?query=killall&sektion=1#IMPLEMENTATION_NOTES

[allesand]

dmrconf --verbose read gd73_codeplug.dfu

Oh, why does dmrconf read the codeplug just fine even with gvfs running?

Debug in lib/c7000device.cc@145: Try to detect USB C7000 interface USB C7000 HT: bus 2, device 8. Debug in lib/c7000device.cc@159: Matching device found at bus 2, device 8 with vendor ID 1206 and product ID 227. Debug in lib/c7000device.cc@199: Connected to C7000 device USB C7000 HT: bus 2, device 8. [ ] 0% Debug in lib/gd73_interface.cc@73: Start codeplug read, seqnr=ffffh. [ ] 0% How does the device access differ between the qdmr GUI and the dmrconf CLI? So: dmrconf works just fine, without increasing the delay value. Cool!

[allesand]

Wohoo! qdmr is reading my GD-73! I was not brave enough to try to write to the radio, but this is looking good! One thing: the contacts seem to be displayed twice - they just repeat from beginning to end. Since this is "work in progress" I will wait with writing until @hmatuschek says it's ok to try. Cool beans!

[hmatuschek]

There is only read and codeplug decoding implemented. Next step is encoding then writing.

[hmatuschek]

Similar to the AnyTone devices: compare the speed with the original CPS. :grin:

[hmatuschek]

Wohoo! qdmr is reading my GD-73! I was not brave enough to try to write to the radio, but this is looking good! One thing: the contacts seem to be displayed twice - they just repeat from beginning to end. Since this is "work in progress" I will wait with writing until @hmatuschek says it's ok to try. Cool beans!

Fixed contacts being created twice.

[allesand]

Fixed contacts being created twice.

@hmatuschek Check!

[allesand]

Anything I can contribute as well? I have two of these diminutive little guys.

@opie4624 Which firmware version is installed on your devices? The "not on the net" V1.11 as well?

[opie4624]

I have one on v1.11 and one on v1.06.

[allesand]

There is only read and codeplug decoding implemented. Next step is encoding then writing.

@hmatuschek Thanks for your work, qdmr can write to the GD-73 now! Cool!

@opie4624 @cbsousa @vielmetti @Grissess @cr03 : Please give it a try and report (using the "devel" branch, the "gd73" branch was merged)

[allesand]

The "Checkmark"/Verify-Button seems to block access to the radio? It works exactly once, but pressing it again or trying to read from the radio afterwards makes qdmr crash:

Debug in lib/c7000device.cc@147: Try to detect USB C7000 interface USB C7000 HT: bus 1, device 5. Debug in lib/c7000device.cc@161: Matching device found at bus 1, device 5 with vendor ID 1206 and product ID 227. ERROR in lib/c7000device.cc@192: Failed to claim USB interface USB C7000 HT: bus 1, device 5: Resource busy. Speicherzugriffsfehler (Speicherabzug geschrieben)

[hmatuschek]

The radio does. Once you started a codeplug read, the radio will block until it is completed. Just power-cycle the radio. There is no command to interrupt the transfer nor to reboot the radio. The crash, however, should not happen. Also the verify action should not block the radio. I'll have a look at it.

[hmatuschek]

Ok, opened a new issue for the crash.