[chirp_devel] Leixen VV-898
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).
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.
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.
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.
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.
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 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.
Jim KC9HI
On Sun, Dec 7, 2014 at 4:58 PM, Jim Unroe rock.unroe@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 FalseI 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.MODELIf 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
On Sun, Dec 7, 2014 at 8:47 PM, Tom Hayward tom@tomh.us wrote:
On Sun, Dec 7, 2014 at 4:58 PM, Jim Unroe rock.unroe@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 FalseI 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.MODELIf 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
participants (2)
-
Jim Unroe -
Tom Hayward