Correction:
The error message occurs when I attempt to +open+ the image file, not +upload+ it. Sorry about that.

Understood. Thanks.

I also have a Wouxun KG-UV6X. I also experienced the error message, "Detection Failed. Unable to detect model!", when attempting to load an image file into Chirp. I was not able to work around the problem by changing the welcome message back to "WELCOM".

I read the code. It looks like Jim Unroe did a bunch of the development to support this model. Thanks, Jim! However, I see something slightly different about how the detection works that what Jim said in #note-2 above.

It looks to me like Chirp accepts an image file as being for a Wouxun KG-UV6D or KG-UV6X if a) it is exactly 8,192 bytes long, and b) if the field vfo_offset [1].pad[], bytes 0 through 5, contain the ASCII characters "WELCOM". (See below for a citation to the source code.) This field is different from the two welcome message fields, which are strings.welcome1[] and strings.welcome2[]. It looks to me like the value of the welcome messages don't directly affect Chirp's detection of the handset model.

I don't see a place in the Chirp UI to directly set vfo_offset [1].pad[]. I can see two workarounds: 1. set byte values using Chirp's "developer functions", 2. edit the image file binary data.

Workaround 1: to set vfo_offset [1].pad[] using Chirp's "developer functions", do the following:

If the image for your KG-UV6 is open in Chirp, close it.¶

In Chirp, under the Help menu, select menu item "Enable Developer Functions". A checkmark should now appear next to that menu item. (This instructions are for the Mac OS X version of Chirp. Versions on other platforms may differ.)¶

Open the image file for your KG-UV6. The error message, "Detection Failed. Unable to detect model!" appears. Manually select "Wouxun KG-UV6".¶

In the left pane of the main Chirp window, there is a tab, Browser. Click on this tab. The right hand part of the window becomes largely blank, and divided in two panes, middle and right. The middle pane has a heading Element, and an entry root, which has a disclosure triangle to its left.¶

Click on the disclosure triangle for root. Nine entries appear under root, including vfo_offset [2], which has a disclosure triangle to its left.¶

Click on the disclosure triangle for vfo_offset [2]. Two entries appear under it, "vfo_offset [2][0]" and "vfo_offset [2][1]". Each has a disclosure triangle to its left.¶

Click on the disclosure triangle for vfo_offset [2][1]. Two entries appear under it, "tx_offset [6]" and "pad [9]".¶

Click on "pad [9]". In the right pane, nine lines, labelled "0" through "8", appear. Each has three text fields, labelled "Hex", "Dec", and "Bin". (Each of these corresponds to successive bytes of the field which Chirp checks for the value "WELCOM".)¶

Enter the following numbers in the "Dec" fields of rows 0 through 5 only: 87, 69, 76, 67, 79, 77. Leave rows 6 through 8 unchanged. Equivalently, enter the following numbers and letters in the "Hex" fields of rows 0 through 5: 0x57, 0x45, 0x4C, 0x43, 0x4F, 0x4D. (These are two different ways to represent the ASCII character codes for the letters W, E, L, C, O, M.)¶

In the left pane of the main Chirp window, click on the Settings tab. In the middle and right panes, various settings appear.¶

Change a setting, any setting. If you want, change it back. (This is to make Chirp aware that the image has changed. Chirp appears not to notice changes made in the Browser tab.)¶

Save and close the image for your KG-UV6.¶

In Chirp, under the Help menu, select menu item "Enable Developer Functions". The should no longer be a checkmark next to that menu item. (This instructions are for the Mac OS X version of Chirp. Versions on other platforms may differ.)¶

Open the image file for your KG-UV6. Chirp should recognise it as being for a KG-UV6. The error message should no longer appear.¶

Workaround 2: edit the image file binary data. (This is only practical if you are comfortable using a binary editor.)

If the image for your KG-UV6 is open in Chirp, close it.¶

Open the image file in a binary editor (aka a hex editor).¶

Find the 6 bytes at offsets 0x1f77-0x1f7c inclusive.¶

Change those 6 bytes to have hex values 0x57, 0x45, 0x4C, 0x43, 0x4F, 0x4D. (These are the ASCII character codes for the letters W, E, L, C, O, M.)¶

Save the image file, and close it in the binary editor.¶

Open the image file for your KG-UV6. Chirp should recognise it as being for a KG-UV6. The error message should no longer appear.¶

Result of code analysis

I'm basing my diagnosis on my belief that this Chirp behaviour is controlled by code in module source:chirp/drivers/wouxun.py .

I believe the code which determines if an image matches the KG-UV6D and X is at source:chirp/drivers/wouxun.py#L1423:

@classmethod
def match_model(cls, filedata, filename):
    if len(filedata) == 8192 and \
            filedata[0x1f77:0x1f7d] == "WELCOM":
        return True
    return False

Note that in filedata[0x1f77:0x1f7d], the second address is exclusive. This range starts at 0x1f77 and ends at 0x1f7c, and contains 6 charcters.

I believe the code which defines what is at bytes 0x1f77–0x1f7c (inclusive) is at source:chirp/drivers/wouxun.py#L1055:

#seekto 0x1f60;
struct {
    u8 unknown_flag_26:6,
       tx_offset_dir:2;
    u8 tx_offset[6];
    u8 pad[9];
} vfo_offset[2];

That defines two instances of a vfo_offset struct, the first starting at 0x1f60, each being 1 byte + 6 bytes + 9 bytes = 16 bytes long. The pad field of the second vfo_offset struct is located at 0x1f60 + 0x0010 + 0x0007 = 0x1f77.

I haven't found any code in Chirp which sets vfo_offset [1].pad[]. However, in my image files, it was set to a string which I used in my welcome message. Maybe Chirp copied bytes from the welcome strings fields to this padding. Maybe the KG-UV6 itself copies the bytes from the welcome strings, and when you download an image from the KG-UV6, the image has the welcome message copied into that padding. I don't know.