CHIRP

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.)

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.

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

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.

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.

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

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