[chirp_devel] Leixen VV-898

[Jim Unroe]

On Sun, Dec 7, 2014 at 8:47 PM, Tom Hayward <tom at tomh.us> wrote:
> On Sun, Dec 7, 2014 at 4:58 PM, Jim Unroe <rock.unroe at gmail.com> wrote:
>> The first issue is with the CTCSS tones. My radio shipped with 2
>> channels that have CTCSS tones that are in the WTFTONES list (63.0
>> Hz). I get this exception:
>>
>> Exception running RadioJob: `63.0' is not in valid list: [67.0, 69.3, 71.9, 74.4
>> , 77.0, 79.7, 82.5, 85.4, 88.5, 91.5, 94.8, 97.4, 100.0, 103.5, 107.2, 110.9, 11
>> 4.8, 118.8, 123.0, 127.3, 131.8, 136.5, 141.3, 146.2, 151.4, 156.7, 159.8, 162.2
>> , 165.5, 167.9, 171.3, 173.8, 177.3, 179.9, 183.5, 186.2, 189.9, 192.8, 196.6, 1
>> 99.5, 203.5, 206.5, 210.7, 218.1, 225.7, 229.1, 233.6, 241.8, 250.3, 254.1, 62.5
>> ]
>>
>> Obviously "63.0" must be in some list or how else would CHIRP know
>> that 0x08 equaly 63.0? I'm going to ponder this a little longer,
>> hoping I can figure this out on my own, but currently I am stumped.
>
> I added 63.0 to my WTFTONES list so that it would index properly when
> reading from the VV-898. This doesn't actually add support for 63.0 hz
> because, as you found, Chirp doesn't support it. It's not a standard
> CTCSS tone. I didn't look into what it would take to support this in
> the UI, as I figured no one would ever need it. If it's a non-standard
> tone, it's probably not required by any repeaters. So that's as far as
> I went with it.
>

Ahh, I see. Then I agree, this is good enough.

>> The second issue is with detection of the data file when it is loaded.
>> My "factory" data file has lots of \xff bytes in it so, unfortunately,
>> it is detected as a Wouxun KG-816.
>>
>>     @classmethod
>>     def match_model(cls, filedata, filename):
>>         if len(filedata) == 8192 and \
>>                 filedata[0x60:0x64] != "2009" and \
>>                 filedata[0x1f77:0x1f7d] == "\xff\xff\xff\xff\xff\xff" and \
>>                 filedata[0x0d70:0x0d80] != "\xff\xff\xff\xff\xff\xff\xff\xff" \
>>                                            "\xff\xff\xff\xff\xff\xff\xff\xff":
>>             return True
>>         return False
>>
>> I think the solution here is to add another area that can't possibly
>> be the same as on the Leixen VV-898 or Jetstream JT270M.
>
> This looks to me like an obvious shortcoming in the KG-816 driver. If
> all we had was a big blank file, it would identify as a KG-816.
> There's got to be something more definitive in the memory image to
> identify.
>

Yes. I took a quick glance at the KG-816.img file and didn't see
anything that stuck out to identify it. I'll look harder later. I just
altered it here for now so my VV-898.img would be detected instead.
Unfortunately I think the image made with the vv-898 driver is going
to have the same issue with identification if the Custom Display
message is changed..

>> The third issue is that the the bytes that are to detect the model
>> (see below) are the Custom Display message.
>>
>>     @classmethod
>>     def match_model(cls, filedata, filename):
>>         model = filedata[0x900:0x906]
>>         return model == cls.MODEL
>>
>> If the user edits this message to something other than "VV-898" or
>> "JT270M", then the data file won't be detected when it is loaded into
>> CHIRP.
>
> I think the image had more than location with the text "VV-898". Maybe
> we can switch to one of the others.

No. It is only at 0x900:0x906.

>
>> My thought here is to write "VV-898" or "JT270M" to some other unused
>> area when the data is first downloaded from the radio and then use it
>> to detect the data file.
>
> I don't think it's a good idea to write to unknown portions of memory.

Yeah, I know. Baofeng has been relocating some of their data to
previously unused areas of memory causing grief with the new models
after uploading old .img files to them.

>
>> The fourth issue appears to be a bug in the OEM software that misleads
>> us into thinking that there are 3 default channels and 199 memory
>> channels. This isn't the case according to the data file output by the
>> OEM software. It provides 3 default channels (1-3) and 196 memory
>> channels (4-199) for a total of 199 memory channels.
>
> I don't recall how I handled this in Chirp. I don't think I
> differentiated the default channels from the normal channels. I think
> I just did one big block of 199.

I finally got an image to upload. I populated the channels 196 through
199 and uploaded them to the radio. The radios supports these channels
fine. CHIRP (aka Tom) has it right. It is the OEM software that has it
wrong.

>
>> I am going to look into this further but my fifth issue is I can't
>> upload to my radio using CHIRP. I get "Radio refused program mode". My
>> radio is a new v1.03 and it requires the new v1.03 OEM software. The
>> v1.02 OEM software won't work with it. I will monitor the port and see
>> what is different.
>
> Definitely snoop on the data from the new software. I'm sure we can
> find a way to support both version in Chirp.

I moved my programming cable to my laptop with XP so I could use
portmon. The handshake looked exactly the same. When I moved back to
my main computer, the upload went fine. The problem was apparently
between the keyboard and the chair. ;-)

>
> Tom KD7LXL


Jim KC9HI