[chirp_devel] Baofeng UV-6 Radio

Dan Smith
Wed Feb 5 17:17:43 PST 2014


> Yes. I'm sure that with a little guidance, I can handle it. I believe
> Jens was doing some of that when he was originally adding the BJ UV-55
> to uv5r.py.

Okay, here is something to get you started. Sorry this took so long.
This is far from complete, but I hope it will help get you going.

First, I've attached a diff of everything that you changed on the UV5
driver to arrive at the UV6 driver. That gives you a concise mapping of
things that need to be done.

Second, I've attached a patch against the UV5 driver which adds a
subclass of the base UV5 driver for the UV6. You can override things in
this subclass -- anything you don't override is used from the base class
as-is. You can see that I added an override for the _is_orig() method to
always return False in the case of the UV6. Also, I overrode the
_get_settings() method entirely. I figure that a good first start will
be to just put the settings stuff that you have figured out for the UV6
into that method, even if it duplicates some of what is already there
for the UV5. Later, we can reconcile those, but it will be simpler to do
it that way I think.

I applied some (but probably not all) of your changes to the cloning
functions near the top so that they will do the right thing for the UV6.
I think that since we can always check radio.MODEL and do something
specific for the UV6, we should be able to handle all the cases.

For the memory format changes, you can just leave any of the structures
that apply only to the uv5 -- they won't hurt the uv6 in that case. It
looks like the only conflict is that the uv5 calls one byte "autolk" and
the uv6 calls it "voxenable". If it were me, I would just leave it as
autolk and put a comment in the UV6 settings code like:

  # NOTE: The UV6 calls this byte voxenable, but the UV5 calls it
  # autolk. Since this is a minor difference, we'll refer to it by the
  # wrong name here.

We can apply some sneakier techniques later to make it look right, but
the comment should be enough for now since it's really the only
discrepancy in the settings block.

It also looks like the two radios count their memories differently, one
being from zero and the other from one. In that case, you might just add
a method like this for the uv5:

  def _get_mem(self, number):
      return self._memobj.memory[number]

and then override it in the UV6 class like this:

  def _get_mem(self, number):
      return self._memobj.memory[number - 1]

then in get_memory(), you can do this:

  mem = self._get_mem(number)

and it will do the right thing in each class.

Make sense? I know it's a little more complicated to do it this way, but
I think it will end up with a *lot* less maintenance in the long-run.

Thanks a lot for doing this, and of course, ask if you have questions!

--Dan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jim_changes_from_uv5_driver.diff
Type: text/x-patch
Size: 39626 bytes
Desc: not available
Url : http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20140205/caeb7ebf/attachment-0003.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jim_start_on_a_uv6_subclass.patch
Type: text/x-patch
Size: 2694 bytes
Desc: not available
Url : http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20140205/caeb7ebf/attachment-0004.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
Url : http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20140205/caeb7ebf/attachment-0005.bin 


More information about the chirp_devel mailing list