joc2
commented
7 months ago i just found that if i comment all the line that remove item was not in this firmware option, that correct the problem.
if not has_alarm:
lst.remove("ALARM")
so mean something with pointer of the element number when remove item
it's not the solution to do, but it pin point where to look at..
egzumer
Strange Thing Happend.
egzumer version 22 in the radio,
i have one version of chirp,, the problem is their, then install the last one, but same result:
When you program any one of the programable key (F1 short,F1 Long,F2 short,F2 Long, M) to a value near the end of the list choice ( lock keypad ,switch ... ) directely in the radio via the M key ...
you read with chirp, it display the right thing in chirp. no problem their
The problem , if you change the key setting to a other choice selection in chirp, but uses the option in the bottom of the list, then upload it to the radio. The radio will not gone a show and do the option you program.......
example 1: program (switch demodulation) in chirp, send to the radio, then in the radio it show (switch vfo), example 2: program (lock keypad ) in chirp, send to the radio, then in the radio it show (fm radio) etc...
but if you program the key setting with the top first few option . then every thing working fine. when uploading to the radio.
it look like, that chirp have dificulty to handle a large option selection for a key. .
I check the value send in the debug log of chirp when upload data to the radio. the value send is not good, if it's in the last value of the list,
but if it's on the first value of the list, then the value are good..
maybe chirp have a max len list menu option and with this progammable key, it's over flow the buffer in chirp so if it take a low value it not over flow. it's done that on any of the key programable you select.
it might match when egzumer integrate in chirp, not done test on older version chirp....