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.
Adds MP31Radio as a subclass of H777Radio. Overrides memory format
for 38 channels at 0x0000, settings2 at 0x026B, and memsize capped
at 0x0400 (radio silent above this address). Alias for Pxton 999S
added to model_alias_map.yaml. Tested on live hardware with CH340
cable on macOS.
Fixes#11505
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
The IC-2730E speaks the initial clone handshake at 19200 baud (not
9600 like the IC-2730A) and only responds to the CLONE_ID query
when the payload contains the radio's own model code with the last
byte zeroed, instead of the all-zeros payload sent by every other
Icom clone-mode driver. It also returns "Icom Inc.4D" as the
end-of-clone frame instead of ".4E".
Add a thin IC2730ERadio subclass with these three overrides,
leaving the existing IC-2730A driver untouched (no A variant
hardware available for testing). Behavior is gated by a new
opt-in flag _id_query_with_model on IcomCloneModeRadio with a
default of False, so the 25 other Icom clone-mode drivers are
unchanged. icf.IcomCloneModeRadio.sync_out now reads self.BAUD_RATE
instead of hardcoding 9600; this is a no-op for every existing
clone-mode driver (24 inherit the 9600 default; IcomM710Radio
overrides sync_out itself).
Diagnosed by capturing the Icom CS-2730 protocol exchange under
Parallels and isolating each variable; the radio responds only
when both baud=19200 AND the query payload contains the model
code.
Tested with a real IC-2730E: full clone-from-radio (21312 bytes)
and clone-to-radio both succeed.
Fixes#12481
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Fixes#12014Fixes#11289
Add Channel Memory support for Wouxun XS20G, XS20G Plus and XS20H
Simplify power selections
XS20 clean up
Only include changed items in subclasses - eliminate unnecessary VENDOR and _model line
XS20 update
Put Vendor back in for convention on subclasses
fix power setting logic for XS20 and 935 series
minimize _set_power code based on PR comments
Add the Baofeng BF-V12D as a new model in the baofeng_digital driver.
The V12D requires a ucbfpwd unlock sequence before entering programming
mode, implemented via a custom _get_radio_id() override.
Fixes: #12439
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
Add support for the Radioddity GS-10B, an RT-900 BT variant with
256 channels. Same magic string, fingerprints, and protocol as the
RT-900 BT but with a reduced channel count. Confirmed on firmware
V0.03 with 512- and 999-channel modes tested and verified as
unsupported by the hardware.
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).
This has been a warning for a while, so most of the popular drivers
are fixed by now. This fixes the two remaining (obvious) ones and adds
a test to prevent more from being added.
Note that there may be some that still only modify the memory in
edge cases that this test doesn't cover.
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.
New standalone driver for the Radioddity DB40-G GMRS mobile radio.
40W UHF, 199 channels, 8-character names, 3 power levels (5/20/40W),
50 CTCSS + 104 DCS tones, 400-480 MHz RX.
Protocol: SMP558 family with page-based addressing (0x10 stride,
32-byte pages), 19200 baud. Read responses echo R prefix (not W
as in the T18 family). No ACK after reads. Frequencies stored as
big-endian 32-bit Hz (not BCD). Tones stored as big-endian 16-bit
with CTCSS as Hz*10 and DCS as 0x2800+code (normal) or
0xA800+code (inverted).
Settings: Busy Lock, Key Tone, TX Timeout, Squelch Level.
GMRS enforcement uses ValidationWarning (not immutable fields)
since the radio accepts writes to all channels including the
30 fixed GMRS channels. Firmware enforces TX restrictions by
frequency, not channel number.
Fixes#11341
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.
Add driver for the Baofeng UV-28Plus, a tri-band (VHF/220/UHF) radio
with GPS, Bluetooth, AM airband receive, and three power levels
(10W/5W/2W). Subclasses UV17ProGPS with UV21ProV2 band plan.
Fixes#12085
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 adds support for two GMRS-only UV-17ProGPS variants.
GM-30 Pro is like GM-30 Plus but -GPS, +Bluetooth, and for whatever
reason also adds the "scramble" setting to the menu (same per-channel
setting as K6). Baofeng GM-21 is the same without scramble.
Found bluetooth enable in unknown5[0]; added _has_bt flag and setting.
Refactored scramble from BFK6-specific to _has_scramble flag. Extracted
GMRS implied modes variant logic from GM-30 Plus into intermediate
class. Removed vestigial MODEL_ID in RadioddityGM30Plus.
Fixes#11266Fixes#11805
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
These drivers are known to be problematic in general, but also have
not been converted for use in chirp-next. This removes these from the
tree as there is no plan to modernize or fix them at this time. Also,
Vertex and Yaesu radios are very fragile (as Vertex/Yaesu has stated)
and so removing support for them is probably best anyway. The Yaesu
drivers are, at least, widely used but these Vertex ones are clearly
not. So, this also reduces/removes potential problems.
If someone comes back to fix them in the future, they can be added
back. Since they're only usable in/by chirp-legacy there's really no
need to keep them alive in the main tree. Note that this will remove
them from the supported radios list.
Related to #11319
Related to #679
Related to #677
Related to #605
Related to #7599
Related to #9499
