This makes us try to detect the baud rate of the radio the first time we communicate with it by fetching the template memory. If we fail, we take the default set on the radio class. We also start with the default on the radio class to speed up detection for the default case.

This is annoying for users to have to set a specific rate, and by default, a much slower one than they should need to use.

Tested with an IC-7300

Hello

This was done following the call on the mailing list. I'm a bit rusty so this is probably not following the chirp PR etiquette. I remember the process was somewhat unusual but may have changed since this is now using git rather than mercurial.

In any case, the current py3 branch does not work with the radio in the subject. This is because the driver is expecting strings rather than python bytes and is also using strings internally to compile the proper commands that are then sent to the radio. In particular, the "... %s ..." % foo idiom is used quite a bit, and would include the the b prefix if foo is of the bytes type. That is, of course, undesired. To make this work, we removed the b prefix in all _model variables and added encode() and decode() in _send() and receive(). We also amended the list of tested radios.

I can only guess that there was some debate among developers how to deal with this very problem. The solution chosen here has the advantage that it leaves most of the driver untouched. One could make the point that now would be a great time to implement this in a cleaner way, but I have no way to test the change for all other Alinco radios; I would probably introduce bugs if I go for a more elaborate change.

This code passes the unit tests and reading from / writing to the Alinco DJ-G7 is successful. I assume that I am allowed to add the "byte clean" flag to the list of tested radios under these conditions (not sure what that column really means...)

Thank you for all your efforts! Matt

Turns out data_files was deprecated; PyPA et al recommend that data files be included in the package(s) themselves, in this case, under chirp. Using importlib_resources allows obviating pkg_path() and other hacks about included data files, as they are now fully guaranteed to be present (even in the extremely unlikely load-from-ZIP-file scenario).

(This may be a precursor to full PEP-517 compliance later on)

This is pretty error-prone, but if we find stuff in the text clipboard that looks like frequency/tone data, try to parse it out into a memory and paste it into the grid. Works pretty well for repeaterbook lines, and a few other local repeater group websites I tried. It's definitely not something we can do with a high degree of accuracy, but if you just copy a frequency and tone, it does a decent job.

Alternative to #103

Also fixes bug #10110

This removes the use of bytes in the driver entirely.

The only place where bytes was material was on line 197, where data from radio.pip.read was being cast as bytes. The data from the pipe should already be bytes, so there is no need to cast here.

The other place we're checking against bytes is line 172, which was incorrect anyway... if data was not bytes, then the code should encode on line 173, NOT decode. This was removed entirely

The other spots where bytes was used were redundant given the b prefix on the string.

Hey Dan, @kk7ds, I recently bumped into snapcraft (again) and thought I'd create a snap for Chirp. I know you've had success with the Flatpak build script I put together a few years ago and so I thought I'd give this a go too.

I tested this out with my Baofeng H-777 and was able to download and upload just fine. The snap landing page is currently at https://snapcraft.io/chirp-snap, let me know if you'd like to be added as a collaborator or would like ownership of it.

sudo snap install chirp-snap --edge
sudo snap alias chirp-snap chirp
/snap/bin/chirp

Let me know if you'd rather me send in an hg changeset over to the dev mailing list. I didn't see anything about your repo here being read-only so I'm assuming you have a git -> mercurial process set up.

Tony

[Edit] I did a force push to remove some unnecessary commands that I copied from the arduino snap. Serial port access seems to work without manually connecting the snap.

Downloading from UV-5R using Python3 would fail with this error:

ERROR: Failed to clone: Failed to communicate with radio: can't concat str to bytes

As Tony Fuller pointed out in issue #10082, this happened because we were trying to append the radio model name as a string to the downloaded data, which was a bytes array.

To fix this, we now encode the model name before appending it to the data.

Testing: I tried this with my UV-5R and confirmed that the fix works and I can download data.

At some point we apparently started slamming data down the serial line at too high a rate for older radios. When using an ID-800, the clone dialog finishes in a few seconds, and the radio times out because it missed a huge chunk of the image because it overran its buffer. This seemed to work okay for radios that use the direct serial connection to the 2.5mm data jack, but not via the OPC-478 type interface.

This change makes us read our own echo frames before sending the next one, which slows us down a lot. It feels a lot slower, but it means we're at least pacing the physical echo.

Tested with an ID-800, ID-880 and IC-2820 and this fixes things.

This patch updates the Baojie BJ-318 driver based on a submission provided by Mark Hartong AJ4YI

1. Added two new colors ( brown and yellow)
2. Changed volume to 15
3. Modified the radio information
4. Corrected spelling

fixes #10212

This patch updated

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.
• New drivers should be accompanied by a test image in tests/images (except for thin aliases where the driver is sufficiently tested already).

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).
• 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.

This improves the readability of the items in the box, especially for nice devices that expose a user-friendly name.

I'm not happy about how this blows out the clone box width with overly long descriptive names for ports, but I think the benefit outweighs that, and perhaps something else can be done about it.

When you very kindly moved my EVT_CHOICE method for the province selector to where it should be, it broke the populating of the county Choice dropdown when user changes province Choice selector. Here's a fix. Probably not the "right" fix, but it restores it to a working state.

• New drivers and radio models will affect the Python3 test matrix. You should use "tox -emakesupported" to regenerate this file and include it in your commit.

When I run tox, I get "No Python at...." errors, so I can't regenerate this file using "tox -emakesupported"

As of now CHIRP fails to start with Python 3.9:

• Complains about missing importlib_resources module (although importlib is available as a part of the standard library)
• Application icon and stock configs can't be found (since chirp.share is not a proper python package)

With this patchset I can use CHIRP with Python 3.9.

• Added more explanatory comments
• Extracted more "magic" numbers and strings into named constants
• Removed the subclass for the Powerwerx DB750X radio, which will shortly have its own driver (based on this one, hence improving the comments here first).