[chirp_devel] Chirp 0.3.1 and ID-51

[Dan Smith]

> This may require an architectural change to Icom frequency divider 
> logic, as I'd guess that other Icom radios may also be subject to
> this bug.  In my own code for DStarCom, I'm using my expanded table
> for all D-Star radios that have multiple frequency divider logic, but
> Chirp supports a much larger range of Icom radios, that I do in
> DStarCom, so I'd hate for this change to be made universally without
> a lot of testing on a lot of Icom radios.  So, *someone other than
> me* should decide how/where this should be done.  The bug description
> describes the issue and pretty much everything needed for the fix,
> once the architectural issue is resolved.

That's fine, I'm happy to do it. I don't know how much has to change
architecturally, really, but whatever it is, it needs to be done of
course. There is quite a bit of core stuff in CHIRP that comes from the
days where all I supported were a few recent Icom models. Thus, drivers
for those depend on core lists of things like tuning steps (right or
wrong as they may be). So, some separation or care may be needed to
avoid breaking indexing into those lists and the like, but again, those
are sins that need to be cleaned up anyway.

Unfortunately, my 880 is now mounted (deep) in a vehicle, so it's not
easily accessible for general development. However, if I can reproduce
this on another model, which I expect I can, then I should be able to
fix it and just sit in the car to test.

I targetted it for 0.4.0 so it'll get done.
 
> The ID-31 bug is #771 (today), and a patch has been submitted.

Thanks for the bug, and in advance for figuring out why mercurial
doesn't see your change :)

-- 
Dan Smith
www.danplanet.com
KK7DS
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
Url : http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20130408/71700d45/attachment-0001.bin