Sure, I'll see what I can do. I don't have a TH-9800 or TH-7800 to work with, but I am on good terms with the TH-9800 driver authors. Maybe I can ask for their help on the testing side of things or potentially the person who filed the bug.

I didn't change any code in the TH-9800 driver. My guess is that this report from the unit tests might have something to do with the issue: TYT TH-9800 Detect FAILED: <class 'chirp.drivers.th9800.TYTTH9800Radio'> detected as <class 'chirp.drivers.th7800.TYTTH7800Radio'>

Right, this is the problem I think, which means the bug reporter is probably getting the wrong class when he opens his image.

I thought maybe that error was benign because one of the Yaesu Radio drivers also reports the same issue: Yaesu FT-2900R/1900 Detect FAILED: <class 'chirp.drivers.ft2900.FT2900Radio'> detected as <class 'chirp.drivers.ft2900.FT2900ModRadio'>

Ah, okay, fair enough. This has been a bug for a little bit and we're waiting for the author of that driver to fix it. However, it doesn't actually cause much of a problem because the two classes are the same implementation. For your driver, it means a real breakage.

Maybe you know more about what that means. I will dig into the code and figure out the "file" classes work.

It means that chirp can't tell the difference between a 7000 and 7800 image, and may load the wrong class when someone opens it. The model detection code in each driver will need to do something to distinguish the two. Hopefully you can find something to key off of from the images of each you already have?

Thanks!

--Dan