Add Retevis RA87 - fixes #10871

[KC9HI]

CHIRP PR Guidelines

The following must be true before PRs can be merged:

1. All tests must be passing. The "PR Checks" job is speculative and failure doesn't always indicate a critial problem, but generally it needs to pass as well.
2. Commits should be rebased (or simply rebase-able in the web UI) on current master. Do not put merge commits in a PR.
3. Commits in a single PR should be related. Squash intermediate commits into logical units (i.e. "fix tests" commits need not survive on their own). Keep cleanup commits separate from functional changes.
4. Major new features or bug fixes should reference a CHIRP issue in the commit message. Do this with the pattern Fixes #1234 or Related to #1234 so that the ticket system links the commit to the issue.
5. 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").
6. New drivers should be accompanied by a test image in tests/images (except for thin aliases where the driver is sufficiently tested already). 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.
7. 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).
8. Do not add new py2-compatibility code (No new uses of six, future, etc).

[kk7ds]

The UI should not send you any duplexes other than those your radio claims to handle... Is this for a specific behavior you saw, or are you just being comprehensive? If it can happen for some reason, this should probably raise an error so there's some indication to the user that something went wrong, right? Otherwise it'll just flip back when it refreshes.

[KC9HI]

This is basically code borrowed from the anytone778uv.py driver. DUPLEX_NOSPLIT is just a variable that holds the value of 0x00 which is the value of 'duplex' when the radio's memory is set to simplex (no split).

u8   step:4,          // STEP                                    // 5
     unk1:2,
     duplex:2;        // Duplex 0: Simplex, 1: Plus, 2: Minus

Do you just want me to rename the variable to something like DUPLEX_SIMPLEX, replace it directly with 0x00 or am I not understanding what you are trying to tell me?

[kk7ds]

Nope, I'm just wondering about the else condition for mem.duplex and the error log. I'm just wondering if you added that because you saw the UI send you a duplex that wasn't in the radio's supported_duplexes?

[KC9HI]

No. It it there only because it was in the anytone778uv.py driver that I borrowed it from.

[kk7ds]

Okay, gotcha, just wanted to make sure it wasn't signaling something else going on.

[KC9HI]

There is a similar else condition in both get_memory() and set_memory(). Should I just remove them both?

[kk7ds]

No need to remove them, I just wanted to make sure there wasn't some reason for it :)

[kk7ds]

Protip life hack for you. Whenever you need to iterate a list and have the index, you can do this:

for i, dtmfcode in enumerate(codes):

Now, i will be zero-origin instead of 1 like you're doing here, but it looks like you're using it as i-1 anyway.

[KC9HI]

Thanks for the tip. Appreciated.