[chirp_devel] Chirp 0.3.1 and ID-51
Is Chirp 0.3.1 supposed to support the ID-51? When I attempt to open an ID-51 .img file, Chirp doesn't recognize it.
On Mon, Apr 8, 2013 at 8:15 AM, Dean Gibson AE7Q data@ae7q.net wrote:
Is Chirp 0.3.1 supposed to support the ID-51? When I attempt to open an ID-51 .img file, Chirp doesn't recognize it.
ID-51 is only supported in the daily builds and is targeted for 0.4.0 (see http://chirp.danplanet.com/projects/chirp/roadmap).
0.3.1 supports the same set of radios as 0.3.0. Chirp point releases like this do not add any new features. They just fix some of the bugs found in the previous major release.
Tom KD7LXL
Thanks! Yes, I had seen the roadmap, but I thought that new radios (not subject to regressions) might be in the new release.
What is the cutoff date for 0.4.0 ?? I think there is still a bug in the ID31 code that I corrected when I created the ID51 code: the MyCall "struct" table there didn't have the tag field. Also, the ID-880H uses the common frequency multiplier function, which is incorrect for that table and leads to erroneous frequencies being displayed (eg, for 121.5, the international distress/MayDay frequency).
I want to get to both of those (the first is a trivial fix) before the 0.4.0 cutoff, but I'm busy now.
-- Dean
On 2013-04-08 08:31, Tom Hayward wrote:
On Mon, Apr 8, 2013 at 8:15 AM, Dean Gibson AE7Q data@ae7q.net wrote:
Is Chirp 0.3.1 supposed to support the ID-51? When I attempt to open an ID-51 .img file, Chirp doesn't recognize it.
ID-51 is only supported in the daily builds and is targeted for 0.4.0 (see http://chirp.danplanet.com/projects/chirp/roadmap).
0.3.1 supports the same set of radios as 0.3.0. Chirp point releases like this do not add any new features. They just fix some of the bugs found in the previous major release.
Tom KD7LXL
I want to get to both of those (the first is a trivial fix) before the 0.4.0 cutoff, but I'm busy now.
Thanks, that'd be great. Just make sure there are bugs for both registered and targetted for 0.4.0. That will mean that either 0.4.0 waits for them, or we'll have a discussion about if we need to push it to a later release. As soon as you target for 0.4.0, it will show up in the roadmap and contribute to the "how much is left to do" progress bar.
On 2013-04-08 08:57, Dan Smith wrote:
I want to get to both of those (the first is a trivial fix) before the 0.4.0 cutoff, but I'm busy now.
Thanks, that'd be great. Just make sure there are bugs for both registered and targetted for 0.4.0. That will mean that either 0.4.0 waits for them, or we'll have a discussion about if we need to push it to a later release. As soon as you target for 0.4.0, it will show up in the roadmap and contribute to the "how much is left to do" progress bar.
The ID-880H bug is #559 (2013-02-13). I regard this bug as critical (but not for me personally), but marked it urgent, because it could possibly lead to transmission on an incorrect frequency, if an import and then export from/to the radio was done.
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.
The ID-31 bug is #771 (today), and a patch has been submitted.
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 :)
On 2013-04-08 10:28, Dan Smith wrote:
...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.
I temporarily faced the same dilemma as you have, with my IC-2820H in my car in my garage. As I mentioned in a previous post, you can install the (free) Digi PortServer support on either Linux or Windows (I did both), and then you can directly access (via the Internet) one of my ID-880H radios for testing. Or, you can buy one of the boxes and remotely access your own ID-880H in your car. Or both.
Either from the comfort of your own living room (grin).
All my radios (except for the ID-51A) have their serial ports permanently available via the Internet using Digi PortServer boxes.
Thanks for the bug, and in advance for figuring out why mercurial doesn't see your change :)
Well, I'm still using CVS for my own personal software development. I've been planning (when one is retired, one's set of "plans for the future" increase exponentially) to move to a newer system for some time, so I'm looking at alternatives. SVN was the initial candidate, but that now seems out of favor compared to GIT/HG. Since I like tools that run *WELL* on multiple platforms, I'm leaning toward HG. Still, either the learning curve is steep, or I haven't yet found good documentation.
participants (3)
-
Dan Smith -
Dean Gibson AE7Q -
Tom Hayward