Feature #6615
A driver should be allowed to force a channel to be receive-only
| Status: | In Progress | Start date: | 03/16/2019 | ||
|---|---|---|---|---|---|
| Priority: | Normal | Due date: | |||
| Assignee: | Daniel Clemmensen | % Done: | 90% |
||
| Category: | - | ||||
| Target version: | chirp-daily | Estimated time: | 0.50 hour | ||
| Chirp Version: | daily | Model affected: | (All models) |
Description
Many radios allow receive on frequency ranges that they refuse to transmit on. CHIRP currently has no way to indicate this.
in discussion with Dan Smith, the simplest way to implement this is for the driver to set the "duplex" field to "off" when the user enters anything that leads to an invalid TX frequency on the channel. RadioFeatures.valid_bands will continue to describe the valid RX bands and the UI will continue to enforce these bands for both TX and RX. duplex=="off" will be an additional restriction.
To support this, the automated test system module "run_tests.py" must be modified to treat a response of duplex == "off" as a legal response in all cases, even when the test case would otherwise expect another value.
This issue tracks only the change to run_tests. Driver changes can be made as desired after this change takes effect and can be handled as separate issues.
Associated revisions
[run_tests] Add a clarifying comment about duplex==off handling in compare_mem
Related to #6615
History
Updated by Daniel Clemmensen about 1 month ago
- Status changed from In Progress to Closed
- % Done changed from 50 to 100
Applied in changeset 7a03f1cb10bd.
Updated by Daniel Clemmensen about 1 month ago
- Status changed from Closed to In Progress
- % Done changed from 100 to 90
Reopening bug to add the need for a change to memedit.py. When the user tries to set duplex to "off" it gets set back to "" before the driver's validate_memory method is called, so the driver cannot tell that the user wanted a RO channel.