Project

General

Profile

Actions

Bug #1611

closed

Kenwood TH-D72A: Programming 2m repeater results in non-functional memory channel

Added by Stuart Longland almost 10 years ago. Updated almost 7 years ago.

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

100%

Estimated time:
Chirp Version:
daily
Model affected:
(All models)
Platform:
All
Debug Log:
I read the instructions above:

Description

Hi,

I recently stumbled across your software and decided to give it a go with a Kenwood TH-D72A which I purchased recently.

After following the instructions, I managed to generate a CSV file that chirp was happy with based on the repeater data from the Wireless Institute of Australia. When I programmed it in, I found all the 70cm repeater entries worked perfectly, but the 2m ones wouldn't transmit.

When I transfer the memory channel to the VFO, the problem persists. I note when I go into the menu and select Radio → TX/RX → Prog. VFO, it shows 410-469MHz as the frequency range, indicating it thinks this is a 70cm frequency, not a 2m one. If I tell the radio to switch bands then overwrite the memory channel, this fixes the problem.

The frequency step gets programmed to 0Hz too for some odd reason. I've attached the .chirp file for the data I've imported and the resultant .img file. A repeater in the memory channels that exhibits issues is number 388: VK4RBN (shown as "4BNBris2"), while one I tried to fix is number 380: VK4RAX.

I've uploaded a couple of snapshots for you to compare them, hopefully they contain the critical detail. Diff-ing the hexdumps seems to suggest a difference but I don't know enough about the format to make an intelligent diagnosis.

I hope the above is enough to diagnose the fault. If not, let me know and I'll try to fetch more information.

Otherwise though, your software saved me many hours of fiddling. Thank-you for your efforts and please keep up the good work.


Files

th-d72a.img (64 KB) th-d72a.img Snapshot after fixing VK4RAX Stuart Longland, 05/03/2014 01:35 AM
th-d72a.chirp (304 KB) th-d72a.chirp Intended data to be loaded Stuart Longland, 05/03/2014 01:35 AM
th-d72a-fixrbn.img (64 KB) th-d72a-fixrbn.img Snapshot after fixing VK4RBN Stuart Longland, 05/03/2014 01:35 AM
000-factory-reset.img (64 KB) 000-factory-reset.img James King, 03/17/2017 03:04 PM
001-set-channel-0-from-radio.img (64 KB) 001-set-channel-0-from-radio.img James King, 03/17/2017 03:04 PM
002-set-channel-1-from-radio.img (64 KB) 002-set-channel-1-from-radio.img James King, 03/17/2017 03:04 PM
003-hexedit-channel0-unknown0-flag-to-1.img (64 KB) 003-hexedit-channel0-unknown0-flag-to-1.img James King, 03/17/2017 03:04 PM
004-import-csv-into-000.img (64 KB) 004-import-csv-into-000.img James King, 03/17/2017 03:04 PM
channels.csv (261 Bytes) channels.csv James King, 03/17/2017 03:04 PM
thd72.py (23.1 KB) thd72.py Tom Hayward, 03/17/2017 03:54 PM
thd72.py (23.6 KB) thd72.py Tom Hayward, 03/19/2017 07:53 PM

Related issues

Has duplicate Bug #2455: TH-D72a clone image: 2m channels don't work, radio does not transmitClosed03/24/2015

Actions
Actions #1

Updated by Tom Hayward almost 10 years ago

  • Assignee set to Tom Hayward

Thanks for providing the comparable .img files. I should be able to track this down.

You should use the live mode driver. It doesn't have bugs like this.

Actions #2

Updated by Tom Hayward about 7 years ago

Comparing 388 on the two files, here's what changed:

 struct {
              freq: 0x08C30AC0
-         unknown1: 0xFF
+         unknown1: 0x07
              mode: 0x00
-        tone_mode: 0x08 (....1000b)
+        tone_mode: 0x00 (....0000b)
            duplex: 0x02 (....0010b)
             rtone: 0x09
-            ctone: 0x09
+            ctone: 0x08
              dtcs: 0x00
        cross_mode: 0x00
            offset: 0x000927C0
-         unknown2: 0xFF
+         unknown2: 0x00
 } memory (16 bytes at 0x2D40)
 struct {
          disabled: 0x00 (.0000000b)
-         unknown0: 0x01 (.......1b)
+         unknown0: 0x00 (.......0b)
              skip: 0x00
 } flag (2 bytes at 0x0F08)

Looks like unknown0, unknown1, and unknown2 were set differently by the radio than by Chirp. Some more investigation will be required to understand these values. (It appears the tone was unset by Stuart and can be ignored.)

Actions #3

Updated by James King almost 7 years ago

#2455 is a duplicate of this bug, I recorded my troubleshooting there after originally hitting this bug, have performed simplified testing as follows:

The flag.unknown0 field appears to be a per-channel TX inhibit function (0=off, 1=on). Verified as follows:

  • factory reset of radio, download clone (000)
  • set channel 0 directly from handset (freq=144.025, name=abc), download clone (001)
  • set channel 1 directly from handset (freq=144.050, name=def), download clone (002)
  • make copy of previous image, user hexeditor to set flag[0].unknown0 to 0x01 (003), upload clone to handset

Prior to the final step both channels could transmit, afterwards channel 0 could not transmit, while channel 1 could. As this "feature" is inaccessible from the UI, it should probably not be exposed for user editing, but unilaterally set to 0x00 for all active channels instead.

Additionally, these images show that when adding a channel directly from the handset, the memory.unknown1/unknown2 fields are normally set to 0x00. These 0xFF values and the TX inhibit flag documented above appear to be solely due to how CHIRP merges a CSV import with the binary data for unused channels in an existing image. This can be replicated using the following process:

  • export channels 1 & 2 to CSV from the final download clone (002)
  • load factory reset image (000)
  • import CSV
  • save as new image (004)
  • compare images (002) and (004)

It's still not clear to me what the purpose for memory.unknown1/unknown2 is, but it should be noted that once this faulty imported data is uploaded to the handset, the live mode driver greys out each affected channel in the interface and shows ERROR for the channel name, so these should probably be initialized them to 0x00 during either a CSV import or manual addition of the channel in the CHIRP UI for safety.

All images generated from this process are attached for verification, please let me know if there's any other information I can provide.

Thanks for all your effort,
James VE7JWK

Actions #4

Updated by Tom Hayward almost 7 years ago

  • File thd72.py thd72.py added
  • Status changed from New to In Progress
  • Chirp Version changed from 0.4.0 to daily
  • Platform changed from Linux to All

Thanks for all your work on this. I made some changes based on your description, however I haven't tested them with a radio. Can you give this a shot? Download the attached file, then select it in Chirp with File > Load Module. Download from your THD72 (clone mode) and add a new channel. Hopefully the new channel will be initialized correctly.

Actions #5

Updated by Stuart Longland almost 7 years ago

Okay, I just grabbed the latest daily (20170311), unpacked it and ran ./chirpw from that directory.

In the File menu there is no "Load Module". Neither Open nor Import seem to know what to do with that file.

Closing chirp and replacing the thd72.py in the source before re-starting however allows the device to be programmed successfully. I created a test channel and uploaded, that worked, it is configured properly and can transmit.

Actions #6

Updated by Tom Hayward almost 7 years ago

I got the impression James already had developer mode enabled, so I didn't mention that step.

Actions #7

Updated by James King almost 7 years ago

Tom, thanks for such a quick turnaround on this!

Unfortunately, after beating up on the updated driver a bit, it looks like I was mistaken. It's not actually a TX inhibit flag, it was just behaving that way because of the frequencies I was using.

It's now looking like the flag indicates what frequency range the channel belongs to, 0=2m, 1=70cm (clued into this when I copied a 2m channel over to VFO with this bit set and then looked at the Prog VFO option and saw the 70cm range instead). It was refusing to TX because the frequency is out of band. This would also explains why this was only affecting 2m channels and not 70cm (which this patch now inverts).

I'll bang away on this more over the weekend to square away the behaviour for all the ranges the radio supports on both band A & B.

Actions #8

Updated by Tom Hayward almost 7 years ago

Thanks for your thorough testing. I'll be away from the computer most of the weekend, but I'll look for an update here when I get back.

Actions #9

Updated by James King almost 7 years ago

Hi Tom,

After a lot of poking, I think I finally have this sorted out enough to resolve this bug.

memory.unknown1 & unknown2's purpose are still unknown, but they always appears to be identical per record, with their value corresponding to the record's frequency:

  • 118000000 - 135999999 = 0x04
  • 136000000 - 173999999 = 0x00
  • 320000000 - 399999999 = 0x04
  • 400000000 - 522999999 = 0x07

As far as the flag record is concerned, I've observed its first byte to have values in the set [0x00, 0x01, 0x02, 0x04, 0x05]. When considered against the corresponding memory record's frequency, this value turns out to map perfectly as an index into the Prog VFO ranges, which I tracked down to the following location:

#seekto 0x02c0;
struct {
  ul32 start_freq;
  ul32 end_freq;
} prog_vfo[6];

The default minimum/maximum values for which are:

  • 136000000 - 174000000 = 0x00 (band A VHF range)
  • 410000000 - 470000000 = 0x01 (band A UHF range)
  • 118000000 - 136000000 = 0x02 (band B VHF range 1)
  • 136000000 - 174000000 = 0x03 (band B VHF range 2)
  • 320000000 - 400000000 = 0x04 (band B UHF range 1)
  • 400000000 - 524000000 = 0x05 (band B UHF range 2)

The above also means that the flag structure is probably more like so:

#seekto 0x0c00;
struct {
  u8 disabled:4,
     prog_vfo:4;
  u8 skip;
} flag[1032];

Additional observations:

  • While the values in the prog_vfo structure reflect any customization made in the handset's UI, the values that gets set in flag.prog_vfo only seem to be based on the range defaults I listed above
  • Because you can't actually program the final frequency in each VFO range, assume (end_freq - 1) when determining which Prog VFO range # to reference
  • Range 3 is a duplicate of range 0 and never appears to get used, even if range 0 is artificially restricted first
  • Range 1 always takes precedence over range 5
  • Because of the change in the width of flag.disabled, all references to it equaling 0x7f will need to change to 0x0f

Sorry for the earlier noise, please let me know if you have any questions or want me to test anything else.

Cheers,
James VE7JWK

Actions #10

Updated by Tom Hayward almost 7 years ago

Give this a try.

Actions #11

Updated by James King almost 7 years ago

Everything looks good from my end with the new version. Thanks for all the prompt effort on this!

Actions #12

Updated by Tom Hayward almost 7 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 0 to 100

Great. I submitted the patch. Thanks for doing all the hard work on this one.

Actions #13

Updated by Tom Hayward almost 7 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF