This needs to be somewhere other than __init__.py because we overwrite that as
part of the win32 build, so just put it in chirp_common.
Related to #6563
Yes, this is the crazy way you have to do this for the OG urllib, but it
works in our favor here to just make sure everything is using the right thing.
Obviously we need to move this code to requests at some point, but since
repeaterbook just broke us with the cloudflare change, this is a point fix
for a current issue.
Fixes#6563
Tone encode and decode both now derive from A single shared mapping table.
This also patch includes whitespace changes, but only to pass cpep8. Another
patch follows to fix other whitespace and minor cleanups.
Add 20.0 KHz and 50.0 KHz steps that are also supported by the BTech UV-5X3.
This patch and the previous patch also fixes the "STEP" issue for other
Baofeng and BTech radio models whose drivers use baofeng_common.py (such
as the Baofeng UV-6R, Baofeng WP970i variants such as the GT-3WP, BTech
GMRS-V1 and BTech MURS-V1).
related to #6501
a few fixups that dont fall into other categories.
the US fersons (FT-4XR and FT65R) don't allow the
6.25 KHz frequency step. The FT-65 has a feature the
FT-4 lacks (compander). The code had a leftover
"valid_frequencies statement.
This driver was importing and then mangling the uv5r.STEPS variable, which made
it incorrect for use in get_features(). This patch makes it copy the list
before doing so.
Fixes: #6503
This radio stores some flags indicating the tuning step of the frequency, and the
frequency as a multiple of the tuning step. This patch adds support for a
frequency that is a multiple of 6.25 kHz for both the frequency and offset.
Still missing is support for a multiple of 25/3 kHz.
The uv5r driver was taking the default list of steps, which after the recent change
to make that smaller, regressed the values it should be able to support. Since the
driver defines the compatible set, it should expose that in features.
#6469#6467
The adapter was ignoring tests that collect and return multiple failures at once,
so any CopyAll failures were ignored. This makes the adapter just pick off the first
one and raise it.
Found while reviewing the driver for #4787
This test was completely wrong, and not really running for any driver. Realized it was
doing something stupid while trying to run it against the CSV driver (which supports
DC->daylight).
Some radios were claiming to support steps they don't support because they were taking
the full list in chirp_common as a default, which is clearly wrong. This patch changes
the default to a very conservative set, which may cause some drivers to no longer accept
some frequencies that may be valid because they were not declaring their real supported
list.
This also uncovered at least one buggy driver that can't support anything other than
5kHz step frequencies (ic2730).
Found in the pursuit of #495
Shockingly we were missing an automated test for memory delete. Adding that
uncovered several issues in various drivers. Some drivers explicitly do not
do delete operations, so mark those in radiofeatures so we can skip the test
for them.
Related to #6455#6453#6451#6449
