CHIRP

Use the live mode driver.

That did indeed help with my problem, however only after another full reset of the handheld. Thanks!
Clone mode seems to screw up the memory in it somehow, and trying now in live mode to import a CSV results in CHiRP hanging. A reset cured that.

I'd prefer to have clone mode working, because it's about 4 times as fast, and an image can be saved on disk. Makes cloning easier.

I have this issue as well, but clone image mode seems to work fine in Linux, so I believe this is a Windows-only problem?

The same thing appears to happen on Mac

I am also experiencing this issue in Linux (Linux Mint 17.3 Cinnamon 64-bit). Tried with version 0.40 from ubuntu-hams-updates PPA, and also with the latest daily tarball.

Burns Fisher wrote:

The same thing appears to happen on Mac

Same for me using macOS Sierra.

On the TH-D72A, I noticed that menu item 130 (VFO Prog) is completely blank with 2m memory channels, whereas it lists a frequency range for 70cm memory channels.

I encountered the same issue using CHIRP on OSX El Capitan, but hit it for both 2m and 70cm channels at the same time. While I was affected by this issue, transmitting still worked fine in VFO mode, just not in channel mode.

To troubleshoot this without losing my channels, I:

• cloned a copy of the bad image
• exported the channel configuration to CSV
• did a full reset of the radio
• did a download clone, reimported the CSV
• uploaded the resulting good image to the radio

Afterwards, comparing the channel configuration (0x1500..0x5380) with a hex editor shows that configured channels in the bad image have 0xFF values in the unknown1 and unknown2 structure fields, while the good image has 0x00 values. I've verified the image attached to the original bugreport also has 0xFF values.

I haven't been able to retrigger the underlying bug that corrupted these values in the first place, but I used a hex editor to fixup these fields to 0x00 values in a copy of the bad image, reuploaded it to my radio, and confirmed I can transmit in channel mode now.

As long as the clone driver enforces unknown1/unknown2 to 0x00 in the frequency struct for all configured channels, that should resolve this bug.

Spoke too soon, some of my channels still weren't working. Found the failed channels also have a correlation to the disabled field in the channel flags region (0x0c00..0x1500). Channels that could not be transmitted on had a disabled field value of 0x01. Once these bytes were zeroed out in my faulted image, the ability to transmit on all channels started working again.

As before, I've verified this is also the case with the image in the original report.

Note that the issue I previously noted with the unknown1/2 fields does also need to be corrected, as 0xFF in those fields causes the live mode driver to show ERROR on the affected channels (and those values may even be what caused the radio to set the disabled flag on what should have been active channels in the first place).