[chirp_devel] Driver Testing by Non-developer Users
I am trying to work with a user to get his radio supported by CHIRP. The model (Baofeng UV-6R) is a supported model, but it is a different firmware version and it behaves a little different in the cloning process.
I can send him modified uv6r.py files that he can use the "Load module" feature to test the changes. The issue is that this driver depends on the baofeng_common.py driver for the cloning process itself. I can modify this driver and send it to him, but even after loading it using the "Load module" feature, the original driver continues to be used.
My question is what do I have to do to be able to allow this user to use a modified baofeng_common.py driver?
Thanks, Jim KC9HI
I am trying to work with a user to get his radio supported by CHIRP. The model (Baofeng UV-6R) is a supported model, but it is a different firmware version and it behaves a little different in the cloning process.
I can send him modified uv6r.py files that he can use the "Load module" feature to test the changes. The issue is that this driver depends on the baofeng_common.py driver for the cloning process itself. I can modify this driver and send it to him, but even after loading it using the "Load module" feature, the original driver continues to be used.
The original driver? Or the original baofeng_common.py code?
My question is what do I have to do to be able to allow this user to use a modified baofeng_common.py driver?
You can probably send him both, as long as he loads the common piece first.
--Dan
You can probably send him both, as long as he loads the common piece first.
I tried that and it didn't work for me. I even tried to do the common piece without anything else and it didn't work. There wasn't an entry in the debug log to show the common piece was replaced either.
Jim
I tried that and it didn't work for me. I even tried to do the common piece without anything else and it didn't work. There wasn't an entry in the debug log to show the common piece was replaced either.
Okay, there might be some ordering or scoping issues preventing that from working I guess. It's been a long time since I wrote the loader stuff.
What sorts of changes are made against the common module? Can you hack those into the driver itself for testing and then move them back out to common when they're known working?
--Dan
On Fri, Nov 18, 2016 at 2:36 PM, Dan Smith via chirp_devel chirp_devel@intrepid.danplanet.com wrote:
I tried that and it didn't work for me. I even tried to do the common piece without anything else and it didn't work. There wasn't an entry in the debug log to show the common piece was replaced either.
Okay, there might be some ordering or scoping issues preventing that from working I guess. It's been a long time since I wrote the loader stuff.
I haven't ruled out that might be a user error.
What sorts of changes are made against the common module? Can you hack those into the driver itself for testing and then move them back out to common when they're known working?
That is a good idea. If I copy and paste a "def" into the driver, will it automatically replace the common one?
Jim
That is a good idea. If I copy and paste a "def" into the driver, will it automatically replace the common one?
Yep, that's how subclasses work. If you re-define something in the subclass, then it takes precedence. If not, you get the one defined in your parent class (i.e. the common one).
--Dan
participants (2)
-
Dan Smith -
Jim Unroe