With this commit, the _set_tone_val() function now properly creates
binary-coded decimal (BCD) numbers, depending on how dcs_enc_base and
tone_enc_base are set when constructing a tone model.
The test cases were expanded to cover all permutations of valid values
for dcs_enc_base (8, 10, and 16) and tone_enc_base (10 and 16). All of
these test cases allow testing new inputs and outputs, as well as
validating that the new settings do not interfere with parsing when it
is not expected to.
As part of the 5RH driver work, it was suggested to look at using the
kenwood_tone functions as the data appeared to be similar. A closer
look showed that they were similar, but not enough to be functional.
The existing Kenwood function puts the tone frequency * 10 into a 16-bit
integer, such that 100.0 Hz becomes 1000 which becomes 0x03E8.
For the 5RH, the tone frequency * 10 is stored as a BCD (which is
effectively hexadecimal with six digits ignored). In this case, 100.0 Hz
becomes 1000 which becomes 0x1000.
In the process of testing the code, I modified the h777 driver to use it,
and discovered that those radios also stored the DCS code as BCD. Meaning
that a DCS code of 031, which would be stored as 0x0019 in octal or 0x001F
in decimal, would instead be stored as 0x0031.
The addition of the tone_enc_base variable for processing tone frequencies
as BCD, and the ability to set dcs_enc_base to 16 (effectively processing
as BCD), should widen the pool of potential users for this function, and
cut down on the number of separate tone implemenations and their tests.
With Dan's suggestion, this PR has been split into two parts: implementing
the first half (decoding with _get_tone_val()) to test against existing
code for encoding. The next commit will then implement the encoding half.
All test cases were duplicated using two tone models; model_dec with
dcs_enc_base defaulted to 8 and tone_enc_base defaulted to 10, and
model_bcd with dcs_enc_base and tone_enc_base both set to 16.
Both models allow testing new inputs and outputs, as well as validating
that the new settings do not interfere with parsing when it is not
expected to.
Fixes:
- Store and use ETag to prevent pulling unchanged data sets
- Return our cache if we get a failure from the server, if present
- Return our cache if we are unable to contact the server at all
A lot of drivers were reimplementing a couple of common checksum
routines. This puts them in a central place (along with the recent
CRC16 centralization, renaming crc to checksum).
Some drivers were modifying the memory in validate_memory() to
side-step the rest of the UI validations. This removes that behavior
from those drivers and also passes FrozenMemory to validate_memory()
in strict mode to prevent this from creeping back in again.
This moves CHIRP to use a proxy for repeaterbook at chirpmyradio.com
to reduce load on the repeaterbook API and improve performance for
our users.
Also, don't run the network tests in CI as they're less important
now and also their failing probably has nothing to do with the patch
being submitted.
These have been long broken and noted as such in the tests but were
never fixed.
The icq7 driver was dependent on this broken behavior in from_GHz(),
so change that driver to do the math it was expecting.
This makes the timeout sanity checking also consider a large write
before a read in determining how much time must be available for the
data to flush in and out.
Some drivers try to read more data in a single call than could
possibly fit within the timeout. Thus, unless the radio is ahead of
us, we'll definitely timeout before having read everything. This
makes our SerialTrace calculate our bytes-per-second and complain if
we try to read more than we could possibly receive in that time. This
will likely false-positive on some drivers that do their own serial
line flushing, but we should fix those anyway.
This commit ensures that when setting an RX tone of any kind,
the radio will only play audio that has a matching tone.
Without this commit, the radio will play any audio that breaks
squelch vs audio that has the matching tone.
On the radio this maps to the 5:signal setting in the function
menu.
Tested on an Anytone779. Should also be the same for Retivis RA25
and Radioddity DB-20G
Man, what a mess 8.33 aircraft band is. This makes us able to support
the pseudo-frequency channel "names" that Eurocontrol thought were
a good idea.
Related to #12316
This fixes the step-based frequency rounding function that Yaesu
(and a few other) radios use to determine the real frequency from the
partial one stored in memory. It also improves 8.33kHz step detection
by allowing for more remainders which are possible when more digits
are entered.
This also fixes the is_8_33() function considering 25kHz-aligned
channels to be 8.33kHz, which is not correct.
Fixes#12214
This adds support to bitwise for a "union", which has the same
behavior as in other languages. Every item in a union occupies the
same memory space, allowing multiple interpretations of the same set
of data.
This causes us to wrap all serial object usage in a module that will
trace (hex and ascii) communication in a generic way. These traces
will be stored (max 10 per session) separately, submitted as part of
a debug report, and purged at exit.
Note that this also makes us gzip any files over 1MB, which is the
limit for attachment sizes on the website.
This has gotten too complicated over the years. Process the list of
allowed steps in order, or a default list if none is provided that
mostly adheres to the behavior we had before.
Fix TK8180 to not pass max=True anymore and just pass the steps in
order of preference.
This makes SEPCHAR a property of the parent class, and also allows
CSV to read and write from a string instead of a file. Adds TSVRadio
class (not registered) to make it easier to handle data payloads
encoded that way.
Related to #11843
Some spreadsheets put cells on the clipboard as unformatted TSV lines.
If these are *exactly* our CSV format, but in TSV, then try to
consume them, but fail quietly. Also support multiple lines from a
plaintext paste.
In the parser "count" has always allowed hex values (0x12) but we
would not actually interpret those properly. Also, arrays of zero
are useful sometimes so add a test to make sure those work (with hex
counts only to make them stand out as intentional).
There has been a bug since forever that an array of one is considered
not an array at all in bitwise. That's obviously not right and there
are some legit reasons to have an array of one. This fixes that and
also fixes the drivers that (for some reason) defined an array of one
and then used it as not an array.
There are a lot of ways a RepeaterBook query can fail, so this adds
some more logging of the results, as well as includes the reason
message if we get >2xx, which is likely rate limiting.
Also change the GMRS query to California, since that has a lot more
repeaters and more opportunities for detecting failing edge cases.
This test assumes that the drivers will upload the 50-58 address range,
which may not always be correct. Update it to use the first bit of
memory uploaded, according to _ranges
This makes the UI consider the radio's tuning steps, if defined as
the first course of action. The existing code tried the standard
set followed by the radio's set, assuming the radio's would be a
subset, which is of course not always true.
This also makes required_step() consider the radio-specific steps
after the standard ones, if there are any strange ones to allow the
radio to define ones that are not in the standard list.
Related to #10968
Some software that spits out CSV may just quote everything, even when
not needed. Doing that prevents us from recognizing the header and
thus makes us think a file isn't in a known format.
Fixes: #11519
These radios (annoyingly) treat frequencies in airband as AM, which
really isn't how chirp was designed to work. Before, we were making
them immutable, but that brings all sorts of problems with it. Instead,
coerce the values on get/set, and return a warning from
validate_memory() so the user is warned.
In reality, we should probably be doing that more places where we have
immutable fields, where the immutable-ness depends on the content of
the memory (i.e the frequency) than the location.
Fixes: #11441
The TD-H8 Ham variant never got the proper _rxbands list which it needs
to allow users to put in the full range of receive-only frequencies.
Fixes#11473
A number of things weren't right with this, likely for a while, since
we had no tests or examples in the tree. This adds three user-supplied
sample files and a test to hopefully keep it working. Fixes:
- Ignore blank entries
- Tolerate a missing "Channel Number" column
- Support the "Scan" (meaning not skip) column type
- Fix detection by being looser about what we look for
Fixes#11389
This is long overdue, but we can flip the NEEDS_COMPAT_SERIAL flag
to off now, since almost everything is migrated and then new drivers
won't have to add it.
The fact that there are no changes to the test matrix shows that this
doesn't change the status of any drivers. All the ones that were
inheriting the old default have been explicitly opted into compat
behavior.
This makes import_logic fail early if the frequency is outside the
supported range of the destination radio. Otherwise other checks
may be run and fail when the radio shouldn't even expect to have to
deal with them.
This makes us keep detected models separate per class that they
were @detected_by. Before this, we would end up with a mashup of all
the detected subclasses in the highest parent class that was a detect
target (i.e. TID H3 and H8 mixed together). Now, we keep them
separate at import/class define time so we don't have to further
filter them. Also, this builds in the include-self behavior to
detected_models() to avoid having to repeat that everwhere.
This also fixes a download..upload..download bug where we will corrupt
the last_model with the detected model name, which isn't selectable
on download (since it's detected and not listed).
The work to enable comments in CSV files broke the detection of those
files when a BOM is present and there are no comments before the
header.
Fixes: #11303
