-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 18/09/13 18:52, Tom Hayward wrote:

On Wed, Sep 18, 2013 at 5:21 AM, Ron Wellsted ron@wellsted.org.uk wrote:

...

This patch modifies the chirp/anytone.py file to add support for the Intek HR-2040 radio. This radio seems to be the same hardware as the Anytone 5888UV with just a firmware difference. The same radio also seems to be sold as the CRT 270M.

Hi Ron,

Thanks for the patch. I see one issue:

...

+valid_model = {'QX588UV', 'HR-2040'}

This set syntax wasn't added until 2.7. I think this will break 2.6 support (still required for RHEL6 and CentOS). Keep it simple; just use a list.

It would be nice to see the ident string stored within the class rather than maintaining this separate list, but that's not going to work if the files all identify as "QX588UV" :-( The way you've done it is the best option I see for now (saved imgs will open as Anytones, but upload fine to either radio).

Tom KD7LXL

I have made the suggested change and also noted the relevant issue number in the patch. The attached patch file is the one that should be used, not the one I sent yesterday.

I have also attached the image file from my radio for inclusion into the tests/images directory. I have used this file with the run_tests command with the following results:

Intek HR-2040 Detect PASSED: All tests Intek HR-2040 CopyAll PASSED: All tests Intek HR-2040 Clone PASSED: All tests Intek HR-2040 BruteForce PASSED: All tests Intek HR-2040 Edges PASSED: All tests Intek HR-2040 Banks SKIPPED: Banks not supported - ---------------------------------------------------------------------- Results: TOTAL : 6 FAILED : 0 SKIPPED: 1 PASSED : 5 CRASHED: 0

- -- Ron Wellsted ron@wellsted.org.uk http://www.wellsted.org.uk Call Sign: M0RNW, Linux Counter No. 202120

On 20/09/13 00:02, Dan Smith wrote:

...

+# This SHOULD be a different model number but at present it returns the same as the AnyTone +# expect this to change in future firmware releases.

• @classmethod
• def match_model(cls, filedata, filename):

•    return filedata[0x21:0x28] == "QX588UV"
  

+# return filedata[0x21:0x28] == "HR-2040"

This makes it intentionally mis-detect files, instead of letting the other one win. Doesn't this fail the detect test? I would think it should.

Can you make this just return False so that it never matches anything (and thus the Anytone driver will always win)? Since this is functionally no different (especially from the testing-an-image perspective) I don't think we need this.

Otherwise, I think this looks good.

Thanks!

Hi, I have improved the detection so that it will correctly determine a .img file from an AnyTone or a Intek. A modified patch is attached.