[chirp_devel] UV-5R Settings tab not working.
I have had several individuals tell me that the UV-5R Settings tab does not work for them. The last person that reported the problem, I had convinced to switch from using v0.3.0 stable to 20130225 daily. I asked him to work his way back installing previous versions until the settings tap worked again and let me know what version it was.
He claims that the transition for a working to non-working settings tab occurs between CHIRP daily versions 20130216 (works) and 20130217 (doesn't work).
I'm trying to get a debug.log from this person.
Obviously, I am unable to duplicate this with my UV-5R radio with BFB231 firmware. This person has BFB281 firmware. I also have a similar issue with someone I have been trying to help me with the new Baofeng UV-5R 144/220 dual band radio.
Any suggestions on how I can isolate the problem so it can be fixed?
Thanks, Jim KC9HI
I'm trying to get a debug.log from this person.
Right, I asked that guy for a debug log instead of just selfishly going back to the older version, since something is clearly wrong.
Any suggestions on how I can isolate the problem so it can be fixed?
I think it's clearly a failure to parse one of the settings objects, and I'm sure it will become obvious once we see a debug log.
Here's the debug.log file that I got from William. Jim
On Sun, Mar 31, 2013 at 8:15 PM, Dan Smith dsmith@danplanet.com wrote:
I'm trying to get a debug.log from this person.
Right, I asked that guy for a debug log instead of just selfishly going back to the older version, since something is clearly wrong.
Any suggestions on how I can isolate the problem so it can be fixed?
I think it's clearly a failure to parse one of the settings objects, and I'm sure it will become obvious once we see a debug log.
-- Dan Smith www.danplanet.com KK7DS
chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
It seams that the problem have been introduced in 9/2/2013 "[UV-5R] Add support for editing the 15 PTT ID Codes" patch. After analisys of the debug.log I'm pretty sure that he has a value grather then 15 in any of the memobj.pttid[i].code elements. This takes one of the "%x" to be 2 char instead of just one.
This is the only explanation I found to have val = RadioSettingValueString(0, 5, _code, False) fail because of a _code longer then 5.
My two cents ..
73 de IZ3GME Marco
On 01/04/2013 04:29, Jim Unroe wrote:
Here's the debug.log file that I got from William. Jim
On Sun, Mar 31, 2013 at 8:15 PM, Dan Smith <dsmith@danplanet.com mailto:dsmith@danplanet.com> wrote:
> I'm trying to get a debug.log from this person. Right, I asked that guy for a debug log instead of just selfishly going back to the older version, since something is clearly wrong. > Any suggestions on how I can isolate the problem so it can be fixed? I think it's clearly a failure to parse one of the settings objects, and I'm sure it will become obvious once we see a debug log. -- Dan Smith www.danplanet.com <http://www.danplanet.com> KK7DS _______________________________________________ chirp_devel mailing list chirp_devel@intrepid.danplanet.com <mailto:chirp_devel@intrepid.danplanet.com> http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
On Mon, Apr 1, 2013 at 6:41 AM, Marco IZ3GME iz3gme.marco@gmail.com wrote:
It seams that the problem have been introduced in 9/2/2013 "[UV-5R] Add support for editing the 15 PTT ID Codes" patch. After analisys of the debug.log I'm pretty sure that he has a value grather then 15 in any of the memobj.pttid[i].code elements. This takes one of the "%x" to be 2 char instead of just one.
I asked Bill to email me his .img file and sure enough PTT-ID #1 had a 0x1f in the location where the first digit would normally be. I change it with a hex editor and email it back. I received a report that it is working now.
This is the only explanation I found to have val = RadioSettingValueString(0, 5, _code, False) fail because of a _code longer then 5.
That's it. If I change 5 to 6 and load the image the settings tab is available and the PTT-ID #1 is displayed as "1f0202" (6 characters long).
My two cents ..
73 de IZ3GME Marco
So my question now is what is the best way to trap this condition?
Plus while testing, I just discovered that the Baofeng software also allows *, #, A, B, C and D in addition to the 10 digits.
0 = 0x00 1 = 0x01 2 = 0x02 . . . 9 = 0x09 n/a = 0x0a * = 0x0b # = 0x0c A = 0x0d B = 0x0e C = 0x0f D = 0x10
I wouldn't mind adding that to but I've not thought about it long enough to figure out how to do that.
Jim
I asked Bill to email me his .img file and sure enough PTT-ID #1 had a 0x1f in the location where the first digit would normally be. I change it with a hex editor and email it back. I received a report that it is working now.
Cool, thanks for following up :)
That's it. If I change 5 to 6 and load the image the settings tab is available and the PTT-ID #1 is displayed as "1f0202" (6 characters long).
Okay, but just to be clear, the problem is not that it should be be 6 characters long, but that the 1F hex value is being rendered into the string as two characters, right? I think you know this, but just making sure...
I'm guessing that 0x1F is a sentinel value, which would be a five-bit field of all ones (00011111).
Plus while testing, I just discovered that the Baofeng software also allows *, #, A, B, C and D in addition to the 10 digits.
Ah, good to know :)
Will this fix it?
diff -r b6bca3fba0e9 chirp/uv5r.py --- a/chirp/uv5r.py Mon Apr 01 17:15:57 2013 -0700 +++ b/chirp/uv5r.py Mon Apr 01 17:30:29 2013 -0700 @@ -1055,12 +1055,13 @@
dtmf = RadioSettingGroup("dtmf", "DTMF Settings") group.append(dtmf) + dtmfchars = "0123456789*#ABCD"
for i in range(0, 15): _codeobj = self._memobj.pttid[i].code - _code = "".join(["%x" % x for x in _codeobj if int(x) != 0xFF]) + _code = "".join([dtmfchars[x] for x in _codeobj if int(x) < 0x1F]) val = RadioSettingValueString(0, 5, _code, False) - val.set_charset("0123456789") + val.set_charset(dtmfchars) rs = RadioSetting("pttid/%i.code" % i, "PTT ID Code %i" % (i + 1), def apply_code(setting, obj): code = []
That's it. If I change 5 to 6 and load the image the settings tab is available and the PTT-ID #1 is displayed as "1f0202" (6 characters long).
Okay, but just to be clear, the problem is not that it should be be 6 characters long, but that the 1F hex value is being rendered into the string as two characters, right? I think you know this, but just making sure...
Right. 1F is the problem.
I'm guessing that 0x1F is a sentinel value, which would be a five-bit field of all ones (00011111).
Plus while testing, I just discovered that the Baofeng software also allows *, #, A, B, C and D in addition to the 10 digits.
Ah, good to know :)
Will this fix it?
diff -r b6bca3fba0e9 chirp/uv5r.py --- a/chirp/uv5r.py Mon Apr 01 17:15:57 2013 -0700 +++ b/chirp/uv5r.py Mon Apr 01 17:30:29 2013 -0700 @@ -1055,12 +1055,13 @@
dtmf = RadioSettingGroup("dtmf", "DTMF Settings") group.append(dtmf)
dtmfchars = "0123456789*#ABCD" for i in range(0, 15): _codeobj = self._memobj.pttid[i].code
_code = "".join(["%x" % x for x in _codeobj if int(x) !=0xFF])
_code = "".join([dtmfchars[x] for x in _codeobj if int(x)< 0x1F]) val = RadioSettingValueString(0, 5, _code, False)
val.set_charset("0123456789")
val.set_charset(dtmfchars) rs = RadioSetting("pttid/%i.code" % i, "PTT ID Code %i" %(i + 1), def apply_code(setting, obj): code = []
It allows the characters to be read from the radio. But I get the following error when keying in the extended characters.
Error in setting value: invalid literal for int() with base 10: 'A'
or '*' or '#' or 'B' or 'C' or 'D'. Clicking the [OK] button clears the error and enters the character in the field. The extended characters do not get uploaded to the radio.
Jim
On Mon, Apr 1, 2013 at 10:04 PM, Dan Smith dsmith@danplanet.com wrote:
Error in setting value: invalid literal for int() with base 10: 'A'
Hmm, can you send me the image?
Here's the image.
Jim
participants (3)
-
Dan Smith -
Jim Unroe -
Marco IZ3GME