TH-D72a clone image: 2m channels don't work, radio does not transmit
|Model affected:||Kenwood TH-D72a|
My Kenwood TH-D72 is giving me a hard time.
What I did:
Factory reset on handheld, all channels empty.
Imported a CSV file which works great on other radios like Icom ID-51, Yaesu FT-60R; using CHiRP 0.4.1.
I am aware that this radio does not accept NFM.
Radio shows all channel names fine after upload, repeater offset seems to be correct, no apparent issue in spreadsheet.
However the radio won't transmit on any 2m frequency. 70cm works fine!
Maybe I'm overlooking something?
CSV andf IMG files are attached.
Thanks and 73,
Updated by Bernhard Hailer about 2 years ago
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.
Updated by Eric Hidle about 1 year ago
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?
Updated by Robert Bauer 5 months ago
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.
Updated by Dustin Brewer 4 months ago
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.
Updated by James King 18 days ago
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.
Updated by James King 18 days ago
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).