[chirp_devel] RFC settings import export
Robert Terzi
Mon Dec 30 11:56:19 PST 2013
On 12/30/2013 12:57 PM, Jens J. wrote:
>
> Im not sure if you are getting at this, but one "dirty little
> secret" of importing images into other "identical" radios is that, in
> at least some models, there may be other non-exposed settings (e.g.,
> power calibrations, deviations, level settings, etc) that are stored
> in the radio image,
Ok that's a bit disturbing, I wasn't aware of that. What models do that?
The clone mode radios I have played with, Yaesus and Wouxuns, appear to
keep the calibration data outside of the region that is cloned or is
write protected. (Cloning functionality is built into those radios,
so it makes sense that the manufacturer's would figure out to protect
radio specific data.)
> The best approach should be to import export channels and settings
> directly from existing image, rather than opening the image and
> uploading it directly to the radio. This is up to the user to do
> this, but currently I doubt most users understand this, nor is it
> really documented anywhere (that Im aware of).
So should there be warnings on radios that aren't "clone safe"?
However this still brings back the point of how do you know what you are
importing and why? How do you compare two radios? You can try to flip back and
forth between open tabs, or take screen shots. For simple radios that is probably
fine, but increasingly tedious on more feature-rich radios.
> The "ability to import settings from existing images of same model
> of radio" should be the new functionality here. I think Tom
> mentioned this and I vote for this approach.
To prevent copying unwanted data hiding in unused fields, I'm assuming the
only settings that will get imported/export are those that have defined
setting interfaces. Additionally, I'm guessing you might want to have the
changes go through the setting interface so any error checking will fire.
So really I'm just suggesting (or hoping for) functionality that walks the
known settings and can dump them in some sort of textual representation that
can be examined outside of the chirp gui.
--Rob
More information about the chirp_devel
mailing list