I'm a little worried because when I change a single property of a single memory I get a large number of changes in the memory file. For example, if I change only one channel from high power to low power I get about 37 bytes affected. I expected to see only two or three (the byte that records the power level, and the checksum).

Are you doing it from the VFO? The VFO buffer is a volatile spot that changes a lot. Even still, just powering on the radio can change data in places you might not expect. Radios with digital volume controls will modify memory if you adjust the volume, and many radios store the s-meter as well, so just receiving some garbage can modify memory.

Fret not. Find where your memory is and ignore the rest of it.

Finally, I seem to have a problem where occasionally I get or lose a null byte at the beginning of the file, which of course messes up the byte count. I think I should get "\x00AHN015" but sometimes I just get "AHN015".

That would be contrary to more than, what, ten other similar models, so I doubt it. The most likely cause is you putting chirp into clone mode before you put the radio into clone mode. Those radios seem to burp when crossing that line, which is why it's important to power it up into clone mode, then start chirp listening, then hit the clone tx button.

That's all for now. I guess there won't be a patch as the VX2r is a new program file. I'll send the whole thing when I'm done, or I can send the current horribly broken mess to anyone who wants to look at it.

No, please submit as a patch. Just use "hg add" to get mercurial to pay attention to it. I also recommend using the mq extension to manage and prepare patches, and I think I've made a believer out of Tom as well :D

Thanks!