[chirp_devel] [PATCH] [bj-uv55] fix fm setting #1335
# HG changeset patch # User Jens Jensen kd4tjx@yahoo.com # Date 1389073505 21600 # Mon Jan 06 23:45:05 2014 -0600 # Node ID 01fbc99d901e3d26f71315ab01006dbcc36d094c # Parent 9b34ea6769cf7b4bb3e6c8b8147072a19474e6fa [bj-uv55] fix fm setting #1335
diff -r 9b34ea6769cf -r 01fbc99d901e chirp/bjuv55.py --- a/chirp/bjuv55.py Mon Jan 06 23:23:36 2014 -0600 +++ b/chirp/bjuv55.py Mon Jan 06 23:45:05 2014 -0600 @@ -186,8 +186,8 @@ unknown5:6; } vfob;
-#seekto 0x0F56; -u16 fm_presets; +#seekto 0x0F57; +u8 fm_preset;
#seekto 0x1008; struct { @@ -549,8 +549,8 @@ fm_preset = RadioSettingGroup("fm_preset", "FM Radio Preset") group.append(fm_preset)
- preset = self._memobj.fm_presets / 10.0 + 87 - rs = RadioSetting("fm_presets", "FM Preset(MHz)", + preset = self._memobj.fm_preset / 10.0 + 87 + rs = RadioSetting("fm_preset", "FM Preset(MHz)", RadioSettingValueFloat(87, 107.5, preset, 0.1, 1)) fm_preset.append(rs)
@@ -635,8 +635,8 @@ try: val = element.value value = int(val.get_value() * 10 - 870) - print "Setting fm_presets = %s" % (value) - self._memobj.fm_presets = value + print "Setting fm_preset = %s" % (value) + self._memobj.fm_preset = value except Exception, e: print element.get_name() - raise \ No newline at end of file + raise
# HG changeset patch # User Jens Jensen kd4tjx@yahoo.com # Date 1389073505 21600 # Mon Jan 06 23:45:05 2014 -0600 # Node ID 01fbc99d901e3d26f71315ab01006dbcc36d094c # Parent 9b34ea6769cf7b4bb3e6c8b8147072a19474e6fa [bj-uv55] fix fm setting #1335
Really, it would be nice if these commit messages could at least describe the problem (apparently the offset was wrong?).
--Dan
Lols Dan. Do you want <80 chars or multiple lines ;) I'll start working on the latter.
What about: "fix wrong fm preset offset and size in radio image" ?
________________________________ From: Dan Smith dsmith@danplanet.com To: chirp_devel@intrepid.danplanet.com Sent: Wednesday, January 8, 2014 6:49 PM Subject: Re: [chirp_devel] [PATCH] [bj-uv55] fix fm setting #1335
# HG changeset patch # User Jens Jensen kd4tjx@yahoo.com # Date 1389073505 21600 # Mon Jan 06 23:45:05 2014 -0600 # Node ID 01fbc99d901e3d26f71315ab01006dbcc36d094c # Parent 9b34ea6769cf7b4bb3e6c8b8147072a19474e6fa [bj-uv55] fix fm setting #1335
Really, it would be nice if these commit messages could at least describe the problem (apparently the offset was wrong?).
--Dan
_______________________________________________ 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
Lols Dan. Do you want <80 chars or multiple lines ;)
Multiple lines! Who ever said they had to be a single line? :)
I'll pick on Tom here a bit, who I think started the current trend of single-line micro logs :)
I'll start working on the latter.
What about: "fix wrong fm preset offset and size in radio image" ?
I meant to say, I applied this one already, but I'd like to have the 7800 one with the details.
I was looking at our commit history the other day trying to find something and came to the realization that we've been pretty bad lately with being descriptive in the log. I'd just like us to be a little better about that.
Generally, the first line of a commit message should stand alone, followed by a blank line, then as much text as makes sense to describe the issue/change/fix. I've been really lax about this recently, and we don't have to be insane about it, but lately we've had a lot of "fix bug #123" commit messages.
Project-specific details aside, the following two pages have some good guidelines and examples, which I think are pretty common for open-source projects:
http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
https://wiki.openstack.org/wiki/GitCommitMessages
--Dan
gotcha.
1. do you work on openstack development at all? 2. have you looked at moving chirp to github? I was thinking they have some nice features like code review, and maybe some intrinsics like system multi-site/backup redundancy. Was curious as to what kind of redundancy you have for chirp hg repo?
________________________________ From: Dan Smith dsmith@danplanet.com To: chirp_devel@intrepid.danplanet.com Sent: Wednesday, January 8, 2014 7:23 PM Subject: Re: [chirp_devel] [PATCH] [bj-uv55] fix fm setting #1335
Lols Dan. Do you want <80 chars or multiple lines ;)
Multiple lines! Who ever said they had to be a single line? :)
I'll pick on Tom here a bit, who I think started the current trend of single-line micro logs :)
I'll start working on the latter.
What about: "fix wrong fm preset offset and size in radio image" ?
I meant to say, I applied this one already, but I'd like to have the 7800 one with the details.
I was looking at our commit history the other day trying to find something and came to the realization that we've been pretty bad lately with being descriptive in the log. I'd just like us to be a little better about that.
Generally, the first line of a commit message should stand alone, followed by a blank line, then as much text as makes sense to describe the issue/change/fix. I've been really lax about this recently, and we don't have to be insane about it, but lately we've had a lot of "fix bug #123" commit messages.
Project-specific details aside, the following two pages have some good guidelines and examples, which I think are pretty common for open-source projects:
http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
https://wiki.openstack.org/wiki/GitCommitMessages
--Dan
_______________________________________________ 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
- do you work on openstack development at all?
Yes.
- have you looked at moving chirp to github?
Personally I really don't like github, so no.
I was thinking they have some nice features like code review, and maybe some intrinsics like system multi-site/backup redundancy.
Hah, that's funny. Github is extremely well-known for being down all the time. It was down today, in fact :)
Was curious as to what kind of redundancy you have for chirp hg repo?
It's backed up in several places, runs on a machine in a datacenter and is backed by RAID1. It's more than reliable enough for our purposes I think :)
% uptime 17:33:43 up 387 days, 21:44, 2 users, load average: 0.12, 0.23, 0.22
--Dan
On 09/01/2014 02:35, Dan Smith wrote:
[...cut...]
Was curious as to what kind of redundancy you have for chirp hg repo?
It's backed up in several places, runs on a machine in a datacenter and is backed by RAID1. It's more than reliable enough for our purposes I think :)
And don't forget is replicated on each development machine at hg pull so we have copies all around the world, far enouth from each other to survive to any disaster including dinosaurs resuscitation and aliens invasions ;)
73 de IZ3GME Marco
participants (4)
-
Dan Smith -
IZ3GME Marco -
Jens J. -
Jens Jensen