[chirp_devel] RFC settings import export

Jens J.
Mon Dec 30 09:57:51 PST 2013



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,
and are (or should be) specific to exactly that individual radio. While they _might_ be mostly portable between same model of radios, there could be potential issues.

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).

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.

-J

________________________________
 From: Robert Terzi <rct at r-t.org>
To: chirp_devel at intrepid.danplanet.com 
Sent: Monday, December 30, 2013 11:36 AM
Subject: Re: [chirp_devel] RFC settings import export
 

On 12/30/2013 1:03 AM, Tom Hayward wrote:

> It makes more sense to me to begin by supporting Import/Export of
> settings via img from identical radio models. For example, import
> uv5r.img into another uv5r. For this you will not need any CSV
> encoding or translation between models. I think this feature would
> satisfy most user's need for settings import.

Couldn't that use case of moving settings to an identical radio already
be handled by just using the source image after importing the frequencies
from the destination radio's image?

The recently requested use case was the possibility of improved accessibility
for the visually impaired by allowing CSV export and import.  As mentioned, this
would need 100% fidelity in the export and re-import to be useful, so would be
difficult to achieve, especially with CSV.

The use case that I haven't seen mentioned, is exporting to some textual
representation to facilitate settings comparisons.  This is useful for
not only comparing two radios, but also for determining what settings have
changed over time on a single radio.  I use G4HFQ's FTBVX8 software in that
manner.  The settings user interface is table oriented and can be exported
to text files making compares possible, even on radios with a lot of settings
like the VX-8.

As this can be very useful for diagnostic purposes, I'd be interested in seeing
some sort of textual export/report, even if there were no import, initially just an
additional developer function.  More of the settings meta data would need to be exposed,
which would wind up providing additional documentation for each radio's settings.
I'm guessing that is where Jens J. is headed recently asking about doc strings for settings.

Just adding my thoughts, the subject did say this was a request for comments, right?

A happy and healthy New Year to all,
--Rob


_______________________________________________
chirp_devel mailing list
chirp_devel at intrepid.danplanet.com
http://intrepid.danplanet.com/mailman/listinfo/chirp_devel
Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20131230/3074a0cc/attachment-0001.html 


More information about the chirp_devel mailing list