[chirp_devel] [PATCH] [uv5r] add work mode settings
# HG changeset patch # User Jim Unroe rock.unroe@gmail.com # Date 1358558371 18000 # Node ID c0c2d198f04c0449d53585e043cdc31070dd705a # Parent cca7868bd2dc089c07269a7dda7b9a511ef838e4 [uv5r] add work mode settings update extra structure add wmchannel structure #443
diff -r cca7868bd2dc -r c0c2d198f04c chirp/uv5r.py --- a/chirp/uv5r.py Thu Jan 17 13:59:18 2013 -0800 +++ b/chirp/uv5r.py Fri Jan 18 20:19:31 2013 -0500 @@ -86,15 +86,24 @@
#seekto 0x0E52; struct { - u8 disp_ab:1, + u8 displayab:1, unknown1:2, fmradio:1, alarm:1, unknown2:1, reset:1, menu:1; + u8 unknown3; + u8 workmode; + u8 keylock; } extra;
+#seekto 0x0E7E; +struct { + u8 mrcha; + u8 mrchb; +} wmchannel; + #seekto 0x1000; struct { u8 unknown1[8]; @@ -800,6 +809,35 @@ RadioSettingValueBoolean(uhf_limit.enable)) other.append(rs)
+ workmode = RadioSettingGroup("workmode", "Work Mode Settings") + group.append(workmode) + + options = ["A", "B"] + rs = RadioSetting("extra.displayab", "Display", + RadioSettingValueList(options, + options[self._memobj.extra.displayab])) + workmode.append(rs) + + options = ["Frequency", "Channel"] + rs = RadioSetting("extra.workmode", "VFO/MR Mode", + RadioSettingValueList(options, + options[self._memobj.extra.workmode])) + workmode.append(rs) + + rs = RadioSetting("extra.keylock", "Keypad Lock", + RadioSettingValueBoolean(self._memobj.extra.keylock)) + workmode.append(rs) + + _mrcna = self._memobj.wmchannel.mrcha + rs = RadioSetting("wmchannel.mrcha", "MR A Channel", + RadioSettingValueInteger(0, 127, _mrcna)) + workmode.append(rs) + + _mrcnb = self._memobj.wmchannel.mrchb + rs = RadioSetting("wmchannel.mrchb", "MR B Channel", + RadioSettingValueInteger(0, 127, _mrcnb)) + workmode.append(rs) + return group
def set_settings(self, settings):
Hey Jim,
+#seekto 0x0E7E; +struct {
- u8 mrcha;
- u8 mrchb;
+} wmchannel;
Since these channels can only be 0-127, I wonder if we ought to limit them appropriately? It's possible that the baofeng could use that upper bit for something, which would cause your parsing code below to blow up. Something like:
struct { u8 unused1:1, mrcha:7; u8 unused2:1, mrchb:7; } wmchannel;
The 7-bit field there fits perfectly and will avoid you crashing if that upper bit is set. What do you think?
Sounds like a great idea to me. Let me see if I can figure out how to resubmit it?
Also, would it be difficult to limit the 0-127 selection to only programmed channels? Right now I depend on the user to select a programmed channel. Choosing an empty channel defaults to the channel with the lowest number. So it really isn't a big deal. Jim
On Fri, Jan 18, 2013 at 8:45 PM, Dan Smith dsmith@danplanet.com wrote:
Hey Jim,
+#seekto 0x0E7E; +struct {
- u8 mrcha;
- u8 mrchb;
+} wmchannel;
Since these channels can only be 0-127, I wonder if we ought to limit them appropriately? It's possible that the baofeng could use that upper bit for something, which would cause your parsing code below to blow up. Something like:
struct { u8 unused1:1, mrcha:7; u8 unused2:1, mrchb:7; } wmchannel;
The 7-bit field there fits perfectly and will avoid you crashing if that upper bit is set. What do you think?
-- 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
Sounds like a great idea to me. Let me see if I can figure out how to resubmit it?
Looks like you figured it out, nice job :)
Also, would it be difficult to limit the 0-127 selection to only programmed channels? Right now I depend on the user to select a programmed channel. Choosing an empty channel defaults to the channel with the lowest number. So it really isn't a big deal.
Yeah, that's going to be quite a bit more complicated. I think it's good as you have it. I've applied the updated one.
Thanks!
participants (2)
-
Dan Smith -
Jim Unroe