Just a few cents here from memory (which might not be worth much over time-depreciation ;) long: I recall from playing with several yaesu radios (VX-2/3/6/170?,FT-90,FT-7900) that the memory layouts and protocols were quite similar.They usually started with some ident (ascii?) string, e.g. AH017$, whch identified the model class, e.g. VX-2 vs VX-3.That was followed by a few bytes (1-3 or 4 cant recall exactly), which seemed to indicate either the regional variation (EU vs US), and also if it was "modded" or stock. I want to say that the first byte might have been a direct result of the jumper configuration (which I think also had to do with the regional setting and mods). Let's call this the "feature bits".
Note that whenever you changed jumpers, you were supposed to default/reset the radio, in order for the change to take effect. (It seemed that the radio used the feature bits in the running image, not the jumper settings, and the jumper settings were only transferred to running image during a default.) So after changing jumpers, defaulting, and downloading, some of those feature bits in the image would change. I attempted to exploit this, as I was trying to find a way to "soft-mod" the radio by tweaking these bits in the image, however the radio would not accept the image with the modded bits (if they did not match the bits in the running radio image). The result of this was that the radio would refuse to accept a clone image which was previously made from that same radio after you changed the jumper settings (and defaulted). So what this means for chirp interaction is that although the model id was the same, there differences in the features, and they are not portable between direct images. As with other radios, the best pattern is to pull a fresh image from the radio, and import the channels from previous image of the radio. You might also be able to detect the capabilities of the radio by looking at these feature bits (e.g. frequency range of EU vs US, unlocked, etc). short: The summary is that I dont think you need to treat the variants of a radio model for Yaesu as separate models in chirp.I think these feature bits are just attributes of model capabilities.
-Jens From: Dan Smith via chirp_devel chirp_devel@intrepid.danplanet.com To: Cc: chirp_devel@intrepid.danplanet.com Sent: Friday, April 1, 2016 3:25 PM Subject: Re: [chirp_devel] [PATCH] [FT2900] Add support for settings. Fix #2867
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 _______________________________________________ chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers