<html><body><div style="color:#000; background-color:#fff; font-family:lucida console, sans-serif;font-size:10pt"><div><span>hrmm.. looks like here storing/using the raw memory image blob is biting us here...</span></div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: 'lucida console', sans-serif; background-color: transparent; font-style: normal;"><span>was thinking more about your .chirp format, or something else</span></div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: 'lucida console', sans-serif; background-color: transparent; font-style: normal;"><span><br></span></div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: 'lucida console', sans-serif; background-color: transparent; font-style: normal;"><span>maybe .chirp2 format, comprised of json, which has these sections:</span></div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: 'lucida console', sans-serif; background-color: transparent;
font-style: normal;">0. some header section with metadata (identification/type, date created/modified, version, etc)</div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: 'lucida console', sans-serif; background-color: transparent; font-style: normal;"><span>1. channel data (with extra fields like description, last_mod_dates, etc)</span></div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: 'lucida console', sans-serif; background-color: transparent; font-style: normal;"><span>2. tree of settings</span></div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: 'lucida console', sans-serif; background-color: transparent; font-style: normal;"><span>3. banks/mappings/names</span></div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: 'lucida console', sans-serif; background-color: transparent; font-style: normal;"><span>4. raw memory image (i.e., same thing as .img today), encoded base64,
etc</span></div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: 'lucida console', sans-serif; background-color: transparent; font-style: normal;"><span><br></span></div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: 'lucida console', sans-serif; background-color: transparent; font-style: normal;"><span>I was thinking this would make for a more portable image format.</span></div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: 'lucida console', sans-serif; background-color: transparent; font-style: normal;"><span>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.</span></div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family:
'lucida console', sans-serif; background-color: transparent; font-style: normal;">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)</div><div><br></div> <div style="font-family: 'lucida console', sans-serif; font-size: 10pt;"> <div style="font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 12pt;"> <div dir="ltr"> <hr size="1"> <font size="2" face="Arial"> <b><span style="font-weight:bold;">From:</span></b> Dan Smith <dsmith@danplanet.com><br> <b><span style="font-weight: bold;">To:</span></b>
chirp_devel@intrepid.danplanet.com <br> <b><span style="font-weight: bold;">Sent:</span></b> Thursday, January 9, 2014 9:23 AM<br> <b><span style="font-weight: bold;">Subject:</span></b> Re: [chirp_devel] Build test results: Failure<br> </font> </div> <div class="y_msg_container"><br>> wonder if this is the reason why FT7900 model class was never registered.<br>> It's really identical to FT7800 in terms of memory layout and size.<br>> <br>> I guess i'll move that registration for FT7900 and resubmit patch :(<br><br>Oh, yeah, I forgot about this.<br><br>The radio is so identical, I couldn't find any way to tell them apart.<br>We do have people ask how to do the 7900 because it doesn't show up in<br>the download list, so registration would be nice, but I just left it<br>unregistered until I figured out what to do.<br><br>We could register it and hack the test to know that the 7900 is weird.<br>The problem with that is that people will download
from their 7900 and<br>have it report the model correctly. If they save and re-open the file it<br>will say 7800. I was trying to avoid that potential confusion.<br><br>Maybe we should just nix the 7900 class and modify the 7800 driver to<br>say "7800/7900"? I hate doing that, but...<br><br>--Dan<br><br>_______________________________________________<br>chirp_devel mailing list<br><a ymailto="mailto:chirp_devel@intrepid.danplanet.com" href="mailto:chirp_devel@intrepid.danplanet.com">chirp_devel@intrepid.danplanet.com</a><br><a href="http://intrepid.danplanet.com/mailman/listinfo/chirp_devel" target="_blank">http://intrepid.danplanet.com/mailman/listinfo/chirp_devel</a><br>Developer docs: <a href="http://chirp.danplanet.com/projects/chirp/wiki/Developers" target="_blank">http://chirp.danplanet.com/projects/chirp/wiki/Developers</a><br><br></div> </div> </div> </div></body></html>