[chirp_devel] Leixen VV-898

[Tom Hayward]

On Sun, Dec 7, 2014 at 4:58 PM, Jim Unroe <rock.unroe at gmail.com> wrote:
> Tom,
>
> I got a good deal on a Leixen VV-898 mobile transceiver so I purchased
> one. I thought I would map out the memory and either forward to you
> what I determined or take on the project of adding some of the
> settings to the driver myself (whichever is OK with you).

If I knew you wanted one I could have shipped you mine. I'm not using it.

It's okay with me if you want to take over this driver.

> Anyway I have some initial problems that I thought you and I should
> discuss and attempt to resolve before going any further.
>
> 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.

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

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

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

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

Tom KD7LXL