[chirp_devel] Image Format Proposal
Hi all,
For quite some time, it has been apparent that the current method of storing memory data on save and detecting the model on load was breaking down. Right now, memory data from an image-based radio is dropped directly into a file and the length of that file is used to identify the model when it is opened.
I certainly don't want to eliminate that mode of operation, since it's useful for developers. However, it's not the best thing for the users. I've been thinking for a while about a meta format that could encapsulate the memory image, as well as some other useful data for us, the least of which would be information to make the process of driver matching straightforward.
Attached is an example of what I have come up with, along with an XML schema definition for it. I think this is extensible enough to support more things in the future, such as storing raw command strings from a Kenwood-like radio for whole backup purposes, etc. For now, it will support base64 encoding and md5 checksumming of the binary data, as well as timestamping of when the file was created, last modified, uploaded and downloaded from the radio.
I've got a mechanism in there for generic metadata, which could be used by the drivers for internal record-keeping, and/or by the UI for the users.
I'd appreciate some feedback and discussion on this. We don't have to solve the whole problem right now, but I'd like to make sure that what we settle on is something we can deal with in the long-term, even if we do extend it in the future.
I dunno what to call it, really. I burned .chirp on the generic XML format (which I've never liked), so I'm calling this CDF (chirp data format) for the moment.
Thanks!
On 27/09/2012 01:24, Dan Smith wrote: [...cut...]
I'd appreciate some feedback and discussion on this. We don't have to solve the whole problem right now, but I'd like to make sure that what we settle on is something we can deal with in the long-term, even if we do extend it in the future.
I must say I'm not an xml expert but the suggested format seams more than good.
I dunno what to call it, really. I burned .chirp on the generic XML format (which I've never liked), so I'm calling this CDF (chirp data format) for the moment.
...mmm... what about .chirp2?
73 de IZ3GME Marco
On Wed, Sep 26, 2012 at 5:24 PM, Dan Smith dsmith@danplanet.com wrote:
Hi all,
For quite some time, it has been apparent that the current method of storing memory data on save and detecting the model on load was breaking down. Right now, memory data from an image-based radio is dropped directly into a file and the length of that file is used to identify the model when it is opened.
Why don't we just improve match_model() where needed? I've never had an issue... it's not apparent to me that the current method is breaking down :-)
I dunno what to call it, really. I burned .chirp on the generic XML format (which I've never liked), so I'm calling this CDF (chirp data format) for the moment.
.wouxun seems appropriate.
Tom KD7LXL
Why don't we just improve match_model() where needed? I've never had an issue... it's not apparent to me that the current method is breaking down :-)
I present to you, the following:
Exhibit A: if len(filedata) == 8192 and \ filedata[0x60:0x64] != "2009" and \ filedata[0xf00:0xf05] != "KGUV6":
Exhibit B: return len(filedata) in [0x1808, 0x1948]
Exhibit C: return filedata.startswith("\x13\x60\x17\x40\x40\x00\x48\x00" + "\x35\x00\x39\x00\x47\x00\x52\x00")
Exhibits D1 and D2: # This is a horrid hack, given that people can change the GPS-A # destination, but it should suffice in most cases until we get # a rich container file format return len(filedata) == cls._memsize and "API880," in filedata
# This is a horrid hack, given that people can change the GPS-A # destination, but it should suffice in most cases until we get # a rich container file format return len(filedata) == cls._memsize and "API80," in filedata
Exhibit E: if not len(filedata) == cls._memsize: return False return filedata[-16:] == "IcomCloneFormat3"
Exhibits F1 - F5: return len(filedata) == cls._memsize and \ filedata[0x64] == chr(0x00) and filedata[0x65] == chr(0x28)
return len(filedata) == cls._memsize and \ filedata[0x64] == chr(0x00) and filedata[0x65] == chr(0x50)
return len(filedata) == cls._memsize and \ filedata[0x64] == chr(0x01) and filedata[0x65] == chr(0x44)
return len(filedata) == cls._memsize and \ filedata[0x64] == chr(0x02) and filedata[0x65] == chr(0x22)
return len(filedata) == cls._memsize and \ filedata[0x64] == chr(0x04) and filedata[0x65] == chr(0x00)
Exhibit G: self._isuhf = (ord(self._mmap[0x1930]) != 0)
Several of those are testing user-modifiable data, and most of the rest are checking things we *think* might be static, but aren't sure. Some of the chinese radios' memories grow as firmwares improve and features are added, which makes detecting by file size pretty ugly.
Aside from the need, any comments on the actual format I proposed?
participants (3)
-
Dan Smith -
IZ3GME Marco -
Tom Hayward