Feature #6651
Allow RO frequencies on FT-4/FT-65
| Status: | Closed | Start date: | 03/28/2019 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | Daniel Clemmensen | % Done: | 100% |
|
| Category: | - | |||
| Target version: | - | Estimated time: | 2.00 hours | |
| Chirp Version: | daily | Model affected: | FT-4, FT-65 |
Description
The driver will not currently allow a frequency to be configured unless the radio can transmit it. CHIRP should permit the user to configure a channel as receive-only for any channel the radio can receive.
(Note: this fix will require that generic RO support is implemented in the UI and in the test suite: see Issue #6615)
Related issues
Associated revisions
[ft4] driver restructure (#7615)
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
History
Updated by Anonymous 5 months ago
- Status changed from New to Closed
- % Done changed from 90 to 100
Applied in changeset ea5e0a695b7b.