On Tue, Aug 7, 2018 at 6:28 AM Dan Smith via chirp_devel chirp_devel@intrepid.danplanet.com wrote:
Thing is, I've always referred to my favorite repeater as "chirp-img0001-", and that's how I label it in my radios. I hope your new feature can support my unique use case.
Yeah, I didn't give a lot of thought to the magic, perhaps I should throw something non-printable in there and be a little more strict about where it is in the file.
🐖📻📡 (joke aside, since this is printable it's not the best option)
Changing the file extension seems like a pretty low cost way to support both formats and allow mere mortals to identify them in a directory. I can't think of a use case though... Pros? Cons?
The only pro would be sharing the file with older versions of chirp, either because they have something on an old machine and can't upgrade or are sharing with someone that won't.
Had to sleep on it, but I remembered a use case. We can currently save-as .vx5, allowing .img edited by Chirp to be opened with VX5 Commander. VX5 Commander also uses the simple flash-dump image format, but with a .vx5 extension. Will this still be possible? Looks like the driver could override save_mmap() to restore the original functionality.
The Motorola Waris Codeplug Tool works with simple flash images as well.
I've started work on a number of Chirp drivers that don't implement upload/download, but just read a binary file from disk (downloaded with first-party software), modify it, and expect the first-party software to be able to open and upload it back to the radio.
Tom