Initial support for Icom IC-7400

[danielegozzi]

This should also work seamlessly for IC-746PRO, as it is using the same address for the CI-V protocol.

As with other existing icomciv.py based implementations, I did not add general radio settings: this implementation only allows for setting memories.

(Probably) related to #2157
I meant to mention WA1RKT for possibly trying out this on the IC-746PRO, but I'm not able to find him on GH. If this PR lands decently I can drop him an email.

CHIRP PR Checklist

The following must be true before PRs can be merged:

• All tests must be passing.
• Commits should be squashed into logical units.
• Commits should be rebased (or simply rebase-able in the web UI) on current master. Do not put merge commits in a PR.
• Commits in a single PR should be related.
• Major new features or bug fixes should reference a CHIRP issue. Do this with the pattern Fixes #1234 or Related to #1234 so that the ticket system links the commit to the issue.
• New drivers should be accompanied by a test image in tests/images (except for thin aliases where the driver is sufficiently tested already).
• All files must be GPLv3 licensed or contain no license verbiage. No additional restrictions can be placed on the usage (i.e. such as noncommercial).

Please also follow these guidelines:

• Keep cleanups in separate commits from functional changes.
• Please write a reasonable commit message, especially if making some change that isn't totally obvious (such as adding a new model, adding a feature, etc).
• The first line of every commit is emailed to the users' list after each build. It should be short, but meaningful for regular users (examples: "thd74: Fixed tone decoding" or "uv5r: Added settings support").
• Do not add new py2-compatibility code (No new uses of six, future, etc).
• All new drivers should set NEEDS_COMPAT_SERIAL=False and use MemoryMapBytes.
• New drivers and radio models will affect the Python3 test matrix. You should regenerate this file with tox -emakesupported and include it in your commit.

[kk7ds]

Looks pretty solid other than a couple of comments. I pinged Eric to have a look (wasn't sure if you had done that). Can you also squash these into a single commit (or I can before I merge). No need to have the non-style-compliant iterations in the git history.

Thanks!

[kk7ds]

Are these different from chirp_common.TONES and chirp_common.DTCS_CODES?

[danielegozzi]

Yes, my values are more specific and come directly from the IC-7400 manual (I cross-referenced them on the IC-746PRO manual too, and they are the same). The defaults from chirp_common contain more values, but those are not supported by the device.

[kk7ds]

Okay, the typical way this works is to copy and modify the base list so it's more obvious what's going on. Here's an example:

https://github.com/kk7ds/chirp/blob/master/chirp/drivers/alinco.py#L237

Not required to change if you have a preference, but it generally makes it easier when someone complains that some tone is "missing when I use the XX driver". Anyone not familiar with the radio can find the list in the driver, see that tone is removed and know it's not supported.

[kk7ds]

Please don't actually put "N/A" in here because it breaks the UI, UX, and inter-radio compatibility. Normally I'd say put the actual list you index somewhere else and filter what you provide in RadioFeatures, but that's hard here because of how automated this is. Can we just change N/A to USB or some sensible default? If the radio should never have that mode set then we'll never see it, and actually setting USB should choose the earlier one anyway during a .index() operation. If we ever got a bad frame with this value, I think USB is a reasonable fallback.

[danielegozzi]

Ok, I'll update that with USB. The outcome of repeating USB sounds good!

As I'm also trying to squash the commits, I'm not aware of a way of doing that without creating a new git history in a different branch. If I create a new branch with a single commit, you will also have to handle a new PR, right? If you are ok with that and we settle for keeping my DTCS/tones I can go on and try with a new overall commit.

[kk7ds]

Nope, just squash them and git push -f. Don't create a new PR :)

[kk7ds]

If you have trouble with that, you can just stack more in here and I'll squash before merge.

[danielegozzi]

Suggestions implmented. The tones/dtcs codes were indeed the same as in chirp_common. Everything now squashed in one commit (obviously with a force push! how could I not think of that?).

[kk7ds]

Nice, thanks. I'll merge this for the next one.

Looks like there wasn't a bug for this one, so I filed it: https://www.chirpmyradio.com/issues/11246 I'll tweak your commit message to reference it (per item 5 on the checklist above) before I do.