We weren't including the locale files in the builds that get generated
from setup.py, so sdist, bdist_whl. Note that the include mechanics
seem to grab more than we want, so we need an extra exclude to avoid
bundling the source files, which aren't used at runtime.
Asia region FT-25R / FT-65R radios treat repeater offsets differently
than their US siblings. This patch adds capabilities to detect such
radios and to correct the offset accordingly.
Fixes#9713Fixes#10286
Some drivers have been incorrectly including the special channels
in the memory_bounds feature attribute. This causes the UI to fetch
them as regulars in addition. This adds a test to make sure the entire
regular memory range between memory_bounds has no extd_number (which
would indicate that it's a special).
Editing a memory in a D74 file in the GUI currently fails with a message
"no such attribute 'dv_urcall'", because every memory is created as a
DVMemory, but not every memory actually has the DV fields, and this
blows up in some serialization code.
Do like other drivers do and only create a DVMemory for DV memories.
Some of the number/extd_number was assigning to mem before we even
called _get_raw_memory (and therefore before we could tell whether the
mode is DV or not), so it had to be reorganized slightly.
Tested with my own D74.
This adds some unit tests for the Baofeng FM Radio frequency encoding.
Right now it only tests the BF-T1, but has provisions for the UV-5R
as well. This uncovered a bug in the driver, so once that is fixed,
we can extend and enable that one as well.
The UV-5G (aka UV-5X) GMRS radios are preset from the factory (and
after a RESET) with 30 GMRS channels and 11 NOAA WX radio channels.
The programmed channels are not firmware locked from being changed
or erased, TX is not firmware blocked for unsanctioned frequencies.
In respect to channel programming, they are essentially the same as
any common UV-5R (136-174 MHz & 400-520 MHz and TX/RX on all 128
channels).
This patch gives CHIRP the ability to match the radio's factory
provided programming capability.
It has become apparent that some radios are making changes to the
Memory during set_memory(). That is not technically harmful, but
may indicate an attempt to change something of what the user provided,
or to reflect changes back to the user which will never be seen.
For now, define a FrozenMemory object that just logs this problem and
use that when setting memories from the UI. In the future, this should
turn into an error.
This makes us only take the bandplan-provided default step if it is
one of those valid for the radio. If not, or no default step is noted,
we will attempt to find an appropriate step for the channel that is
supported by the radio (which may not be the default) and if none is
found, report the actually-required one to the user.
Fixes#10439
This makes required_step() consider the supported steps when deciding
what to return as required. If not provided, the original set of steps
is used. It also makes validate_memory() provide the radio's supported
list and better reproduces the underlying check's error message.
This allows us to handle radios that don't support 5.0kHz
steps, which is generally assumed to be a safe default. It also allows
calculation of required steps below 2.5 for some that were in use in
the tree already.
Related to #10439
This driver wasn't properly exposing the right list of tuning steps,
as it copied the master list and modified it. That master list has
changed since, which makes it not work as intended anymore.
Related to #10439
This driver has some serious quality issues, which get in the way of
an upcoming refactor concerning tuning steps. This patch:
1. Makes sure the valid_bands are integers
2. Fixes the obviously-incorrect double-condition check for memory
emptiness. The _prep_data() method was certainly not calculating
the correct (for the usage) upper bound on the memory channels,
nor does doing that check really make any sense.
3. The get_memory() method should not be changing memory, but it was.
4. Fixes the use of floats with no decimal places.
bitdiff.py is from before we had GUI developer tools, and is not py3
compliant anyway.
img2thd72.py is no longer useful now that the thd72 driver can open
those files directly, and is not py3 compliant anyway.
elib_intl.py is something to do with internationalization on win32
(it seems). Not sure if/when we ever used that, but we don't anymore
and thus it is removed.
This makes cpep8 run flake8 on anything *not* in the manifest or
*not* in the blacklist. Thus, all new files will get flake8 run against
them by default. It adds a bunch of files to the blacklist that were
not in manifest and thus still aren't compliant. Those need to get
cleaned up, obviously.
No new files should be added to cpep8.manifest going forward so that
the stricter flake8 rules get applied by default. Ideally we'd also
remove files from cpep8.manifest as well so we can move to just one
set of rules for everything, but that will take a while.
