[chirp_devel] Need Advice for UV-5R Driver

[Jim Unroe]

Dan,
Here is what I have been working on. I've gone about as far as I can
without some additional help.

I could not get the patch file that you sent to import. I found what look
to be good instructions, but there were lots of errors reported (probably
something I did). There wasn't that much that changed so I was easily able
to add the changes manually. I used the settingsedit.py that you provided
as-is. The only change I made to settings.py was to bump the precision
setting of 'RadioSettingValueFloat(RadioSettingValue): from 4 to 5.

All of these settings determine the state that the UV-5R will be in when
the Upload To Radio process is completed. So the CHIRP user can select:
- Channel of Frequency mode
- [A]/[B] display
- the selected channel for each display
- the VFO frequency (and BAND) for each display
and that is the way the UV-5R will be when the cloning process completes.

Except for the Channel/Frequency mode selection, it don't think the rest
are available anywhere else.

Everything works except the VFO frequency settings. I was able to
successfully pull the frequency from the UV-5R as individual bytes and
change it to a floating point value to get it displayed. What I haven't
figured out (and that is the main thing I need your help with) is getting
the user's frequency changes back to the radio.

Entering the frequency works great. The proper error is returned for below
137 MHz, above 512 MHz (in need to get that changed to 520 MHz) and in
between 174 MHz and 400 MHz.Thanks.

Seems to me that the band settings could be determined and set in the
background by 'looking' at the frequency. If it starts with a 1 set it to
VHF, if it starts with a 4 or 5 (or if it is not a 1) set it to UHF. That
way the BAND settings could be removed. I do no that if you stuff in a VHF
frequency in the UV-5R while the VFO is set to UHF, you get a weird result
in the display.

A 'would be nice' thing would be to allow only programmed channels to be
selected in the MR A/B Channel selecton. Unless it would be really easy to
implement, I probably wouldn't mess with it since choosing an unprogrammed
channel cause the UV-5R to select channel 0. Not much harm in that.

Thanks again for the 'float_setting_callback_example' patch. That really
propelled me much farther that I thought I could get in in a couple of
days.

Any advice, help and/or hints on the above will be greatly appreciated.

Thanks in advance,
Jim


On Thu, Jan 3, 2013 at 11:34 PM, Dan Smith <dsmith at danplanet.com> wrote:

> Hi Jim,
>
> > I want to use a section of code something like this. This already
> > works, but is there a better way to do it? What it need to do is
> > allow the user to see and edit a VHF or UHF frequency within the
> > allowable frequency range. It would be nice if it could be displayed
> > and edited similar to a cell in the spreadsheet view.
>
> Okay, so what you're asking for is completely valid, but not really
> something that is easy with the current settings architecture. However,
> that's not a good excuse :)
>
> I've attached a patch of some sloppy test code to get close, I think.
> If this works for you, I can clean it up and make it suitable for
> inclusion in the tree. It does the following:
>
> 1. It introduces a RadioSettingValueFloat that behaves very similar to
> the Integer variant, except that it handles formatting the value with a
> given precision.
>
> 2. It adds a callback function to the RadioSettingValue base class,
> which allows you to specify a callback function. This function gets
> called when the setting is set, is passed the value that is trying to
> be set, and expects you to return the value that should actually be
> set. This gives you (the driver author) the ability to intercept the
> set operation and check the value, optionally raising an exception if
> something is wrong (i.e. if their value is not within your 1, 4, 5
> requirements).
>
> 3. It adds the necessary bits in the UI to catch an error during the
> setting save and display it to the user (this really should be there
> anyway).
>
> 4. It adds a fake setting in uv5r.py to demonstrate how to do this. I
> created a new group called "test" with a single fake setting inside
> called "footest". This footest setting has a value of type float, which
> has a callback called "my_validate". The my_validate() function checks
> to make sure the value is not between 200 and 300 returns the value. If
> it is in the banned range, it raises an exception saying that it's
> invalid.
>
> Hopefully you have a way to apply a patch in your Windows environment.
> If not, I think you can use "hg qimport" to pull this into your patch
> queue. Test it to see how it works, and maybe try building your new
> feature on top of it. If it works (or needs some tweaking) then I can
> clean it up and put it in the tree.
>
> Whew, hopefully that all made sense!
>
> --
> Dan Smith
> www.danplanet.com
> KK7DS
>
> _______________________________________________
> chirp_devel mailing list
> chirp_devel at intrepid.danplanet.com
> http://intrepid.danplanet.com/mailman/listinfo/chirp_devel
> Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20130105/ac9daf4b/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: workmode.patch
Type: application/octet-stream
Size: 98527 bytes
Desc: not available
Url : http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20130105/ac9daf4b/attachment-0001.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: workmode.jpg
Type: image/jpeg
Size: 129217 bytes
Desc: not available
Url : http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20130105/ac9daf4b/attachment-0001.jpg