[chirp_devel] Need Advice for UV-5R Driver
All,
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.
_vfoa = self._memobj.vfoa.freqa rs = RadioSetting("vfoa.freqa", "VFO A Frequency", RadioSettingValueInteger(0, 9, _vfoa[0]), RadioSettingValueInteger(0, 9, _vfoa[1]), RadioSettingValueInteger(0, 9, _vfoa[2]), RadioSettingValueInteger(0, 9, _vfoa[3]), RadioSettingValueInteger(0, 9, _vfoa[4]), RadioSettingValueInteger(0, 9, _vfoa[5]), RadioSettingValueInteger(0, 9, _vfoa[6]), RadioSettingValueInteger(0, 9, _vfoa[7])) workmode.append(rs)
I also want to limit '_vfoa[0]' to a list of 1, 4 and 5. Any suggestions on how to do that?
Also, I would want to set another variable, lets call it 'vfoaband', to 0 [meaning VHF] if '_vfoa[0]' = 0 and 1 [meaning UHF] if '_vfoa[0]' = 4 or 5.
Thanks in advance, Jim Unroe
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!
Hi Dan,
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:
- It introduces a RadioSettingValueFloat that behaves very similar to
I'll take a look at this after work (I'm afraid if I look at it now, I'll not make it to work ;-).
Hopefully this will get me far enough along that I can send you rough example of what I am doing. I'm sure I will need additional advice with the project.
Jim KC9HI
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@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:
- It introduces a RadioSettingValueFloat that behaves very similar to
the Integer variant, except that it handles formatting the value with a given precision.
- 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).
- 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).
- 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@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
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).
Hmm. I just tried and this works here:
hg qimport float_setting_callback_example.patch hg qpush
Does that not work for you? If you could copy and paste the error(s) you get when you try to apply, that'd be good. It's really worth spending a bit of time getting that to apply properly, because it was fairly intertwined.
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.
Hmm, I didn't give you a settingsedit.py, but there were changes to that in the patch.
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.
Hmm, well I think I need to see your code to really understand all of the above. If you could get the patch applied cleanly and then send me the "hg diff" of your changes on top of that, I can certainly take a look and try to figure out what needs to be done on the "set" side to make it take effect.
Hmm. I just tried and this works here:
hg qimport float_setting_callback_example.patch hg qpush
Does that not work for you? If you could copy and paste the error(s) you get when you try to apply, that'd be good. It's really worth spending a bit of time getting that to apply properly, because it was fairly intertwined.
I used the steps from another website. I'll give it a try again with your
steps.
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.
Hmm, I didn't give you a settingsedit.py, but there were changes to that in the patch.
I mean I used it as patched, not that I actually got the file from you. Sorry.
Hmm, well I think I need to see your code to really understand all of the above. If you could get the patch applied cleanly and then send me the "hg diff" of your changes on top of that, I can certainly take a look and try to figure out what needs to be done on the "set" side to make it take effect.
I thought I sent a patch along. I'll send it again. Or is there something else you need?
Jim
I mean I used it as patched, not that I actually got the file from you. Sorry.
Ah, okay :)
I thought I sent a patch along. I'll send it again. Or is there something else you need?
Nope, I didn't see a patch. That's what I want. If you want to try the steps for importing to confirm that they work, I may be able to separate out your changes from mine and send you back two patches so you can be clean going forward.
Fail. The best I could come up with was a screen capture. Sorry.
That's probably because mercurial is (at least on UNIX) writing to stderr, which isn't captured with a '>' redirection. No idea if that even exists on Windows or how to grab it :)
That level of epic fail looks like maybe it's an EOL problem, which seems strange (although Marco will shout "told ya" here). I've attached a copy of the patch with CRLF endings, can you try this and see if it applies properly?
Ha! You almost had it figured out.
I looked at both the original file and the latest file and they both had CRs and LFs. I removed them from one file and the import was nearly instant and without incident.
No I cookin' with gas...
Jim
On Sat, Jan 5, 2013 at 5:03 PM, Dan Smith dsmith@danplanet.com wrote:
Fail. The best I could come up with was a screen capture. Sorry.
That's probably because mercurial is (at least on UNIX) writing to stderr, which isn't captured with a '>' redirection. No idea if that even exists on Windows or how to grab it :)
That level of epic fail looks like maybe it's an EOL problem, which seems strange (although Marco will shout "told ya" here). I've attached a copy of the patch with CRLF endings, can you try this and see if it applies properly?
-- 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
Ha! You almost had it figured out.
I looked at both the original file and the latest file and they both had CRs and LFs. I removed them from one file and the import was nearly instant and without incident.
Ah, probably the fault of some evil mail client :D
participants (2)
-
Dan Smith -
Jim Unroe