I get a little less that 10,000 8 bit bytes from the rig, it's almost like a memory dump.
Almost all of the radios CHIRP supports are dumping memory images, so.. yes :)
Is the intent of MemoryMapBytes to hold an "image" of that dump, but provide some structure to the blob for easier access?
Yes, but technically MemoryMapBytes is just the flag image, the output of bitwise.parse() is the logical structure object laid on top of the flat memory buffer. In C parlance, the MemoryMapBytes is the result of the malloc() and the memobj (output of bitwise.parse()) is like a `struct mymemobj*` you point at it to get a structured view.
It appears there are two channels per "record", there seems to be a record start marker with some channel information, 2x rx frequency, mode, name, and tx frequency then a checksum and end of record marker.
I've setup my memory format like this: MEM_FORMAT = """ struct mem_struct{ char rx_freq[9]; char mode; char name[14]; char tx_freq[8]; };
We would call this one channel. Lots of radios store the tx and rx frequency for a given channel (i.e. a numbered memory channel in the radio) separately.
seekto 0x0000; struct { char unknown_SOR[11]; struct mem_struct channels[2]; char checksum[2]; char unknown_EOR; }memory[2]; """
Er, I don't think it makes much sense to have a mem_struct[2] in the middle of this. I'm guessing maybe you're confusing the packetization of the memory data over the wire with the actual memory structure? On all (amateur, granted) Icom radios, they use the ICF protocol to transfer the memory contents to the PC in 8, 16 or 32-byte chunks (depending on the vintage of the radio). Each chunk has a sort of SOR, src and dest addresses (since it's sort of a networking protocol), a command number, the actual payload, and an EOR. You don't want to store all of that, you want to just store the payload in the proper index in the MemoryMapBytes. Other radios with similar protocols include a command, address (i.e. where in the memory address space this chunk goes), length, checksum, etc.
Have a look at icf.py, specifically IcfFrame.parse() to see if it happens to match what you're looking at. At the very least, you should implement that sort of scheme, where you speak the protocol separately from the actual payload that you store.
--Dan