Leixen VV-898S Jetstream JT-270MH mismatch
I have one each, Leixen VV-898S and Jetstream JT-270MH radios. They are the same radio with different branding.
If I clone from the Leixen VV-898S (specified as Leixen VV-898S), Chirp works correctly.
If I clone from the Jetstream JT-270MH (specified as Jetstream JT-270MH) Chirp pulls the data from the radio, then crashes as it is trying display the data.
If I clone from the Jetstream JT-270MH (specified as Leixen VV-898S), Chirp works correctly.
This was observed with Chirp 20191221 daily, on Mac OS X 10.8.5 running on a 2012 MBP.
Updated by Bernhard Hailer about 3 years ago
- Status changed from New to Feedback
Are you able to retrieve the debug log after the crash?
Please see Wiki: How To Report Issues.
Updated by Nita Sanders about 3 years ago
So, I have been looking at a file called Leixen.py, and I have a few observations. (first disclaimer: tons of software dev experience, but not so much python. I can read it, but hesitate to try speaking it). Between grokking what is happening in the python source code, and comparing that to a hexdump of a saved clone file, I have a few thoughts on what is causing two different crashes.
First crash is the one that I reported in the bug report, namely that (other than the external branding) my two radios are identical. At lexien.py/1033 it correctly shows the channel data starting at 0x0D00. That matches the hexdump. The next line (namestart at 0x19B0) also is correct. Moving up to the Jetstream variant (lines 980 & 981) those values do not appear to match my Jetstream branded radio.
The other problem (I think) has to do with line 903, and the associated function. I don't understand what the point of the RadioA and RadioB are. These are not in the logic flow (AFAICT) for the Leixen VV898S, and that logic behaves correctly. If someone wants to illucidate this more clearly, then maybe we can sort it out. I will note the reported chirp crash happens as it is trying to display A Band and B Band, so I think there is a connection here.
The other crash (which I have not otherwise reported, but appears to be in the same Python file) is possibly traced to line 120. When examining the cloned data in chirp, and I switch into browser mode, if I click on the sub section 'messages', chirp crashes. Line 120 is partially involved in the browsing, and an examination of the hexdump shows non-printable ASCII (all 0xff) in that specific field. I don't know what python does in that situation, but if it chokes on non-printable ASCII in a char field, then perhaps that one should be u8 instead.
I can see what I think are some of the problems, but I don't know how to force the .py file to recompile. If someone wants to coach me, I may be able to verify my suspicions and guesses.
73, Nita Rae WA4VQW
Updated by Bernhard Hailer almost 3 years ago
- Target version set to chirp-legacy
- Model affected changed from (All models) to Leixen VV-898S, Jetstream JT-270MH
Hi Nita, you don't have to recompile it. But you can proceed as follows:
- Enable developer mode: Help -> check "Enable developer functions".
- Load your modified module: File -> Load module, point to your modified file.
- Perform any testing, download/upload, modifications etc.
Good luck. And if it works, please share!
More info: Wiki, Developers