For clarification, the patch quoted below is the one that added support of settings to all of the FT1900/FT2900 series, and I don’t believe that particular patch is what was causing the problem. I suspect you’re talking about another submission, which added support for a modded version of the FT2900. That was submitted in a similar timeframe, and is here: http://chirp.danplanet.com/projects/chirp/repository/revisions/1c398653986f
Yep, sorry, my bad :)
I’m now digging through the logic in that test. It’s not obvious to me how adding the support of a modified radio is different from adding support of a European version of the FT-2900/FT-1900 radio, which was done a long time ago (a year or more? I don’t remember, but it was long ago). In both cases, we didn’t add a new .img file to the test cases, there was just a new class added with the same settings overridden.
Because the euro version has a different ident string or something. We've got to be able to detect which model class to use from the file when we open it. Some radios do that by file size, while others look at some identification bytes inside. Some a combination of both.
If the mod bits are stored in the file anywhere, then you can just modify both classes to look at the mod bytes and return the appropriate match. Right now the class uses file size only:
http://chirp.danplanet.com/projects/chirp/repository/entry/chirp/drivers/ft2...
If you look at a couple other examples in other files you'll see some of the more complicated ones.
Anyway, I’ve got to step away from the computer for a while right now, but I just wanted to let you know I’ll be digging into this.
No problem, thanks much!
--Dan