hrmm.. looks like here storing/using the raw memory image blob is biting us here...
was thinking more about your .chirp format, or something else
maybe .chirp2 format, comprised of json, which has these sections:
0. some header section with metadata (identification/type, date created/modified, version, etc)
1. channel data (with extra fields like description, last_mod_dates, etc)
2. tree of settings
3. banks/mappings/names
4. raw memory image (i.e., same thing as .img today), encoded base64,
etc
I was thinking this would make for a more portable image format.
There were still some areas of concern - such as making sure you dont directly upload raw image from one radio to exact same model of another radio. This might not ever be possible unless there is some way to interrogate a unique id (serial number, etc) on target radio - which probably could never be expected across all radios.
Which brings me to another thought: having some flag in the new format which indicates whether its portable or not, or otherwise being able to handle multiple memory regions - such as the UV-5R and variants which have this problem: main section of ram with channel/settings data is portable, but there is an extended section of ram which contains unportable data: serial numbers and (more importantly) calibration data (gains/squelch/power, etc)
From: Dan Smith <dsmith@danplanet.com>
To:
chirp_devel@intrepid.danplanet.com
Sent: Thursday, January 9, 2014 9:23 AM
Subject: Re: [chirp_devel] Build test results: Failure
> wonder if this is the reason why FT7900 model class was never registered.
> It's really identical to FT7800 in terms of memory layout and size.
>
> I guess i'll move that registration for FT7900 and resubmit patch :(
Oh, yeah, I forgot about this.
The radio is so identical, I couldn't find any way to tell them apart.
We do have people ask how to do the 7900 because it doesn't show up in
the download list, so registration would be nice, but I just left it
unregistered until I figured out what to do.
We could register it and hack the test to know that the 7900 is weird.
The problem with that is that people will download
from their 7900 and
have it report the model correctly. If they save and re-open the file it
will say 7800. I was trying to avoid that potential confusion.
Maybe we should just nix the 7900 class and modify the 7800 driver to
say "7800/7900"? I hate doing that, but...
--Dan
_______________________________________________
chirp_devel mailing list
chirp_devel@intrepid.danplanet.comhttp://intrepid.danplanet.com/mailman/listinfo/chirp_develDeveloper docs:
http://chirp.danplanet.com/projects/chirp/wiki/Developers