Bug #2455

TH-D72a clone image: 2m channels don't work, radio does not transmit

Added by Bernhard Hailer about 2 years ago. Updated 2 months ago.

Status:Closed Start date:03/24/2015
Priority:Normal Due date:
Assignee:- % Done:

0%

Category:-
Target version:-
Chirp Version:0.4.0 Platform:Windows
Model affected:Kenwood TH-D72a

Description

Hello team,

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,
Bernhard AE6YN

150322 FCV channel plan - Kenwood TH-D72.img (64 kB) Bernhard Hailer, 03/24/2015 08:55 pm

FCV channel plan - sample private radio, no NFM.csv (29.3 kB) Bernhard Hailer, 03/24/2015 08:55 pm


Related issues

related to Bug #81: thd72 driver does not work with recent firmware Closed 03/14/2012
duplicates Bug #1611: Kenwood TH-D72A: Programming 2m repeater results in non-f... Closed 05/03/2014

History

Updated by Tom Hayward about 2 years ago

Use the live mode driver.

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 over 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 Burns Fisher 9 months ago

The same thing appears to happen on Mac

Updated by Robert Bauer 7 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 6 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 3 months 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 3 months 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).

Updated by Tom Hayward 2 months ago

  • Status changed from New to Closed

Also available in: Atom PDF