This family of radios (like other brands and models) has a feature which
automatically determines whether an offset is to be applied in positive
or negative direction. When a user programmed the radio manually and didn't
explicitly select positive or negative offset, then the radio saved the fact
that it was automatically pre-selected, and not the actual selection. The
driver was able to read that, but didn't know what to do with it.
Data from an FT-65R (for North America models) and a FT-4XE (for European
models) was obtained, and a table built from it. Code to determine the
correct value for "duplex" (0 for +, or 2 for -, instead of 5 for auto) has
been added. Now, instead of saving "auto", the image will be saved with the
correct selection for duplex (something Yaesu should have done in the first
place).
Mentioned in #6677.
This patch adds support for the Yaesu FT-25 to Chirp. The European version is commented out; we can activate as soon as we obtain an image (it can be downloaded using FT-25R as selected radio).
This patch adds support for the Yaesu FT-4V to Chirp. The European version is commented out; we can activate as soon as we obtain an image (it can be downloaded using FT-25R as selected radio).
The FT-4 driver restricted allowed frequencies to what the radios allowed for transmit. This patch opens allowed ranges to what the radios offer for receiving. Also mentioned in #6869.
After a CSV file was imported, all imported channels were displayed and uploaded with low power. This patch ensures the recommended high power setting will now be used.
When user programmed radio manually and added a name shorter than 8 characters, the remaining characters were filled with garbage on the Chirp UI. This was due to padding with 0x7F used by the Yaesu; the solution is to pad with 0x20 (space characters) instead.
While implementing two more radios of the Yaesu FT-4 family (the FT-25, see #7543, and the FT-4V, see #7387), I found that with some moderate reorganization, implementation of new radios will become easier. The proposed reorganization implements one more interstitial layer of inheritance to support the sub families of FT-4 (containing the FT-4X and FT-4V) and FT-65 (containing FT-65 and FT-25). Also, some variable assignments have been moved from the individual radio classes to the SCU-35 base class and to the interstitial classes named above.
This change also adds the infrastructure for adding European or Asian models, and as such prepare for addressing a number of currently open issues (6.25kHz tune step issues on EU models, frequency limitations; see #6619, #6651, #6677, #6761, #6869). It will also make it easier for a few additional fixes for issues which were found during my work on this driver (#7601, #7603, #7605). I will submit these fixes in additional patches.
Fixes: #7615
There is a 5+ years old issue which I could reproduce: the Yaesu VX-8
didn't support Chirp NFM (as in "half channel bandwidth", not as in
Yaesu's meaning: Yaesu calls the normal 25 kHz bandwidth "NFM", as
opposed to broadcast "WFM"; to achieve what's called "NFM" in Chirp,
one needs to enable "half deviation" in the VX-8).
This patch introduces Chirp NFM support to the VX-8 driver.
Tested on a VX-8DR.
73
Bernhard AE6YN
#1615
(resubmission)
Users complained that under certain circumstances 2m repeaters with negative
offsets were not programmed correctly and resulted in a frequency offset or
even an incorrect transmit/receive mode. Both issues #129 and #1735
essentially describe that same problem for the Yaesu VX-8. I ran into the
same issue with a VX-8DR I just got - which made me dig into Chirp
Two bytes were found to be initialized differently when manually programmed,
both were marked "unknown". After a few experiments these bytes could be
(at least partially) identified. (A side product was that I found the bit
responsible for narrowband transmit - that will be used in another patch
fixing issue #1615 to enable this radio for Chirp's "NFM" mode).
Tested with a VX-8DR.
73
Bernhard AE6YN
#129#1735
This solves the BF-888 refused to enter programming mode problem in
some cases where more time is needed waiting for radio identification
data.
This change also increases the timeout when uploading data blocks,
which is required for some individual radios.
This adds the additional FRS channels (15-22) and expands GMRS channels include
all frequencies add in the 2017 rule changes.
It also adds the GMRS repeater channels with the prescribed +5.0MHz offset
(though you'll have to find the correct tones for your local GMRS repeaters).
After some feedback on the mailing list, I've chosen to number the channels
according to the FRS numbering, rather than try to preserve the obsolete
numbering, and I've chosen to name the GMRS repeater channels with both the
"550" style numbering that's common in repeater naming and the "15R" name that
makes it clear that it's receiving on channel 15.
This refactors the driver code to allow the D700 radio driver
to leverage the settings support that is in the D7 driver. Only
a few setting support differences between the two radios were
handled. Also setting the packet path and callsign seems to be
only partially working, or the radio has some very old and outdated
restrictions on what can be set.
Closes#7407
While working on #7407 it became clear that the recent HF rig support
almost entirely broke talking to the D700 (and probably others). This
makes some changes to the ID routines:
- Prioritizes the baud scan for the regular delimiter ahead of the HF
one, since the vast majority of users will be using the former. The
delimiter change substantially increased the ID time for regular
radios set to a high baud rate.
- Prioritizes fast baud rates over the slow ones in the scan.
- Adds a quick recovery to the case where the radio responds at the
desired baud rate with "?" meaning "what is all this junk you have
been sending me", which fixes the case where the ID fails on the
first attempt and succeeds on the second.
As reported by Paul on #7339, a leftover debug message was referring to
a data variable (likely copy pasta from download) and causing a NameError.
This log message is unnecessary, so just remove it.
Old CHIRP Radio Images (*.img) from Baofeng UV-82 series radio models
that do not have a "metadata blob trailer" are incorrectly dectected
as being from a Radioddity UV-82X3.
This patch separates the UV-82X3 into a separate "basetype" to address
this issue.
#7217
