CHIRP

The failure is because CHIRP is looking for "2009" to identify the image is from a JT220. Your image has "2011" where CHIRP expects the "2009" to be.

Jim KC9HI

When an image is loaded from a file, CHIRP has to somehow identify which radio this image came from. Usually a file length match is done first. Many radio models have an image of the same length so usually an additional check is made to check for something unique to that radio model in the image. The check for the Jetstream JT220 is shown below.

    @classmethod
    def match_model(cls, filedata, filename):
        return len(filedata) == cls._memsize and \
            filedata[0x60:0x64] == "2009"

The check is for the string in the image a position 0x60:0x64. CHIRP is looking for "2009" (which is the year part of a date -- 2009-4-10 or April 10, 2009). Your image has 2011 in this position (which is the year part of the date 2011-11-3 or November 3, 2011. See the attached screen capture from my hex editor.

Unfortunately the choice of this string to check for a JT220 didn't turn out to be a good one.

Possible workarounds are...

1 the "Jetstream JT220 image":http://chirp.danplanet.com/projects/chirp/repository/changes/tests/images/Jetstream_JT220M.img from the repository could be used.

2 the "2011" in your original image could be changed to "2009" so it passes the current check. (attached)

3 the alinco.py driver could be edited/hacked to look for "2011" which would allow you to enable "Enable Developer Functions" so you could load it to work with your JT220 image. (attached)

4 a developer might get away with patching the driver to only check for "20". This would match both "2009" and "2011" and shouldn't be an issue again until the year "2100". ;-)

5 a developer might determine another way to identify the image.

Jim