Project

General

Profile

Actions

Bug #2455

closed

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

Added by Bernhard Hailer about 9 years ago. Updated about 7 years ago.

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

0%

Estimated time:
Chirp Version:
0.4.0
Model affected:
Kenwood TH-D72a
Platform:
Windows
Debug Log:
I read the instructions above:

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


Files


Related issues

Related to Bug #81: thd72 driver does not work with recent firmwareClosedTom Hayward03/14/2012

Actions
Is duplicate of Bug #1611: Kenwood TH-D72A: Programming 2m repeater results in non-functional memory channelClosedTom Hayward05/03/2014

Actions
Actions #1

Updated by Tom Hayward about 9 years ago

Use the live mode driver.

Actions #2

Updated by Bernhard Hailer about 9 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.

Actions #3

Updated by Eric Hidle about 8 years 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?

Actions #4

Updated by Burns Fisher over 7 years ago

The same thing appears to happen on Mac

Actions #5

Updated by Robert Bauer over 7 years 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.

Actions #6

Updated by Dustin Brewer over 7 years 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.

Actions #7

Updated by James King about 7 years 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.

Actions #8

Updated by James King about 7 years 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).

Actions #9

Updated by Tom Hayward about 7 years ago

  • Status changed from New to Closed
Actions

Also available in: Atom PDF