Non-responsive UI after reading TYT MD-380 codeplug as TYT MD-UV380 selected

[eshattow]

Debian GNU/Linux host OS (bookworm/sid)

unpack editcp-1.0.31 and copy 99-md380.rules where it needs to go, sudo udevadm trigger radio is TYT model MD-UV380 136-174MHz/400-480MHz radio info screen shows Firmware Ver D002.027 CP Ver. V01.34 I have this radio unit because a fellow operator asked me if I could get it to work, so I don't know if this is stock or modified condition, and it appears to power up and operate normally from what little I know about it. They described difficulty in getting free (as in money) software to interact with the unit after loading a codeplug given to them, regretting to have not downloaded the initial codeplug before doing so. I am at the first stages of discovery here, to find a tool that can download the state of the radio as it is before I try anything more interesting. Button1+Tx and power up radio verify with alternating green/red light, plug USB into host:

Oct 16 18:38:41 zontar kernel: usb 1-4: new full-speed USB device number 7 using xhci_hcd
Oct 16 18:38:42 zontar kernel: usb 1-4: New USB device found, idVendor=0483, idProduct=df11, bcdDevice= 2.00
Oct 16 18:38:42 zontar kernel: usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Oct 16 18:38:42 zontar kernel: usb 1-4: Product: Digital Radio in USB mode
Oct 16 18:38:42 zontar kernel: usb 1-4: Manufacturer: AnyRoad Technology
Oct 16 18:38:42 zontar kernel: usb 1-4: SerialNumber: 00000000010C
Oct 16 18:38:42 zontar mtp-probe[190430]: checking bus 1, device 7: "/sys/devices/pci0000:00/0000:00:01.2/0000:01:00.0/usb1/1-4"
Oct 16 18:38:42 zontar mtp-probe[190430]: bus: 1, device: 7 was not an MTP device
Oct 16 18:38:42 zontar mtp-probe[190432]: checking bus 1, device 7: "/sys/devices/pci0000:00/0000:00:01.2/0000:01:00.0/usb1/1-4"
Oct 16 18:38:42 zontar mtp-probe[190432]: bus: 1, device: 7 was not an MTP device

(previous: output of journalctl -xf)

./editcp

Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.

Not even sure what that means, seems harmless. Continuing... Radio|Read codeplug from radio > Select the codeplug model and frequency range. MD-UV380 A: 136-174 MHz B: 400-480 MHz

"OK" Preparing.... yeah okay. Reading codeplug from radio... progress bar ticks along 0%-100% steadily then dialog goes away, I hear the CPU fans spinning up, UI for editcp is non-responsive.

Gnome window manager is asking me "Codeplug Editor" is not responding.... Force Quit or Wait. I try "Wait" a few dozen times, no luck.

htop shows an initial CPU usage spike on the second core and then usage kind of drifts all over the cores.

Force Quit. CPU usage flatlines overall.

I should have this unit in my possession until the next exams we are offering, so if there's more testing to do I'd be happy to report my findings.

[DaleFarnsworth]

I don't doubt that this is a bug in editcp, but I have no way to reproduce the problem. I assume you have repeated the exercise with the same results. All I can offer you now is, "I'm sorry".

[DaleFarnsworth]

Note that you cannot read nor write a codeplug while in the FW update mode (red/green lights flashing). You must be in "normal" operating mode to read or write a codeplug.

[eshattow]

Note that you cannot read nor write a codeplug while in the FW update mode (red/green lights flashing). You must be in "normal" operating mode to read or write a codeplug.

Re-tested with unit powered on in normal operation, same kind of response from editcp (prepares, reads 0%-100%, UI non-responsive). During that attempt the radio unit does show "PC Program USB Mode" program mode initiated and then returns to normal operation.

Failure is always an option :-) What would cause the non-responsive UI after a reading operation though? That seems odd.

[DaleFarnsworth]

My guess is that while trying to interpret the codeplug's contents, that editcp gets into an infinite loop. Only a guess with limited informaiton. If you don't need to preserve the current codeplug in the radio, you might try to create a "new" codeplug and write it to the radio, overwriting the codeplug in the radio.

[eshattow]

Thanks Dale! If you have this model of radio, I could try to obtain from the owner of the radio unit the steps what they did to get it to this state of operation, including the codeplug data itself (which appears to be a regional specific amateur radio club data set, so reasonable to ask for permission to share if there's nothing proprietary about it). Also valid to close wontfix, as I don't directly have any experience debugging golang.

[DaleFarnsworth]

I am interested in duplicating the problem in my MD-UV380, if you can get a hold of the codeplug and send it to me.

[eshattow]

problem_codeplug_issue23.zip attachment contains 'CP Exported 061522.rdt' and 'Ham VHF Freqs.doc' as sent to me by the owner of the radio unit KA6NSN, and additionally contains '202210172214_DR780_70cm_3106893.rdt' as I was able to read from the radio at the dmr.tools web-based tool (identified the radio as model DR780 with bands 70cm). I attempted to open 'CP Exported 061522.rdt' in editcp and there is a warning that 12 records with invalid fields were found; opening '202210172214_DR780_70cm_3106893.rdt' (from the radio via dmr.tools) yields a warning of 4 records with invalid values. I will refrain from writing any data to the radio for the moment pending your advice. Note that the radio is said to be from an ebay market sale and no information at the moment if the firmware was original or customized.

P.S. Additional information from the owner:

I think that the free programming application that I used on that radio was written for an MD-390. The UHF information from my MD-380 exported successfully into the MD-UV380 but the radio would not take anything after that. I followed internet advice about re-installing the operating system but it did not work.

Asking follow-up questions now, especially to learn what software was used (not editcp?) Clarifying the issue is that bad data makes editcp spin out (infinite loop?) on read. Whether the codeplug is suitable or not is less of a concern as I'm confident that the radio unit is working as intended and has some unexpected data on it.

[DaleFarnsworth]

Thanks for supplying the files.

Interesting. DR780 is the codeplug identiifier for the MD-380 (not UV380). And the size of 202210172214_DR780_70cm_3106893.rdt matches the size of an MD-380 codeplug. I won't be able to look at the files for a day or two, but my current guess is that a MD-380 codeplug was written to the MD-UV380, which will NOT work at all.

If you tell editcp that your radio is an MD-380, I suspect that editcp will read and produce a codeplug file identical to 202210172214_DR780_70cm_3106893.rdt.

Note that there is no alternative firmware for the MD-UV380. There are a few versions of the factory firmware that should work. I suspect that the FW in the radio is fine and it just needs a good codeplug.

[DaleFarnsworth]

It looks to me like a codeplug for the MD-380 was written to the MD-UV380 radio. That won't work. I'll load these two files into my MD-UV380 and see if I see the same with editcp. Thanks for sending the files.

[tarxvftech]

Howdy! Since dmr.tools got mentioned, I'll chime in. dmr.tools can't export a true RDT, the header isn't fully filled in, so that's problem 1 with trying to use the exported codeplug from dmr.tools and expected.

The radio is from 2015, based on the serial number - I talked with shadow out of band on the M17 discord- so it's too early to be a dual-bander anyway. I suspect that's 100% of the issue, is a misidentification of the radio hardware. In short, the real radio is an MD-380, not an MD-UV380 as thought, and identifies itself as such when interrogating the firmware.

[tarxvftech]

And not that it should matter for this, but there were indeed modified firmwares for the md-2017 and md-uv380s from kg5rki's fork of md380tools, TyToolz. Modern options include OpenRTX (but it'd be obvious if OpenRTX was being used, because it's not a fork of the OEM but a de novo firmware).

Also: thanks for your work on documenting the codeplug format in that codeplug.json doc, I use it in dmr.tools! (source under my ProgramRadios repo). I use it to create a deep binary file format proxy with ES6 Proxies, which avoids the whole parse/render cycle by doing it in real time on changes and reads. Vue3 caches the reads, which avoids the worst of the costs of doing it that way. It's a huge mess but also pretty cool. :D

[DaleFarnsworth]

Do you have a pointer to the md380tools derivative firmware for the MD-UV380?

[DaleFarnsworth]

The radio is from 2015, based on the serial number, so it's too early to be a dual-bander anyway.

Are you saying that the radio eshattow has is not an MD-UV380?

[tarxvftech]

I think it's at https://github.com/KG5RKI/TyMD380Tools I know Ty (kg5rki) went through several stages of taking it private, public, private, etc and I lost track a while ago, but this looks to be about what I remember. It was a hard fork from fairly early-on so there's almost no shared history with md380tools.

[tarxvftech]

The radio is from 2015, based on the serial number, so it's too early to be a dual-bander anyway.

Are you saying that the radio eshattow has is not an MD-UV380?

Yes, exactly, or at least several signs point that direction with some authority.

[DaleFarnsworth]

I'm familiar with https://github.com/KG5RKI/TyMD380Tools, but there's no evidence of a port to the MD-UV380.

[DaleFarnsworth]

Thanks! So, eshattow, do you have an MD-UV380 or an MD-380?

[tarxvftech]

No evidence of a port

Then Ty may not have that up anywhere. He was fairly protective of it. I do remember distinctly that he had it working on the md-2017 and later I'm fairly sure he had the md-uv380, as they're very nearly the same radio.

Update: md2017 branch has the md-2017 changes at least, I recognize the FW key.

[eshattow]

Further comments from the owner of the radio unit:

The original codeplug was downloaded to my MD 380 from the SNARS website. I have programming software that works for the MD 380 and was able to modify that device to work with custom channels. Online software that I downloaded allowed me to export UHF data from the MD 380 to the MD UV 380 but it apparently corrupted the files when I attempted to modify further.

email will not let me send programming software but they are labeled as below: MD-UV380 and MD-UV390 Firmware V18.11_20191015 20211224095042 (compressed zip) CPS+TYT+MD-UV380+GPS+UV390+GPS+Setup+v1.06 (rar file) MD-UV380 and MD-UV390 Firmware V18.11_20191015 (compressed zip)

And indeed, the box that they handed me says MD-UV380 but the sticker on the back of the unit (with battery removed) says MD-380. I did not catch this discrepancy, asking the owner about it now.

Also confirming when selecting the correct model (MD-380) and frequency range (400-480MHz) that editcp reads out the codeplug and there is no UI "spin out"; it does say "4 records with invalid field values were found in the codeplug.":

The following field values are invalid:

Channels[Channel].Rx Frequency (MHz): frequency out of range -1e-05
Channels[Channel].Tx Offset (MHz): rxFrequency is invalid

Channels[NARRI IRLP].CTCSS/DCS Decode: bad ctcss frequency: 123.9

Channels[W7DI].CTCSS/DCS Decode: bad ctcss frequency: 123.9

Channels[UNR].CTCSS/DCS Decode: bad ctcss frequency: 123.9

[DaleFarnsworth]

Okay. Thanks to tarxvftech for clearing that up. It does look like those 4 fields in the codeplug are invalid. I'm inclined not to invest more time on this one and closing. Thank you.