Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

Revive RIG_LEVEL_BWC (or equivalent) — set/get filter width independently of set_mode

未关闭
  • 哪里不对？
#2,148 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 4 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
35/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
冷清
技术栈
c
领域
backend-api-design

调研方向

Start by tracing the level-flag definitions in include/hamlib/rig.h and src/idx_builtin.h, then read the disabled bandwidth handlers in rigs/jrc/jrc.c and the existing newcat bandwidth functions and set_level/get_level dispatch. The key decision is how to represent a new level when all 64 flag bits are allocated. Done means a viable independent bandwidth level is exposed for the Yaesu family without resending the mode.

由索引模型根据 Issue 内容生成。

描述

Motivation

I'm building a hamlib-driven remote control panel intended to work
across rig models with minimal per-rig-specific config — a physical pot
mapped to filter width, for example. Currently the only entry point for
bandwidth is set_mode(rig, vfo, mode, width) / get_mode(...) — width
is bundled with mode, not independently settable via set_level. That
means every bandwidth-only change has to resend the mode too, and the
caller has to already know and pass through the current mode correctly
just to touch bandwidth — awkward for a UI element that's conceptually
unrelated to mode switching.

Prior art already in the tree

  • include/hamlib/rig.h:1103 — RIG_LEVEL_BWC ("Bandwidth Control, arg
    int (Hz)") is fully documented but the #define is commented out.
  • src/idx_builtin.h:144 — LVL_BWC mirrors this, also commented out.
  • rigs/jrc/jrc.c (NRD-535/545) has a complete get/set
    implementation wired to RIG_LEVEL_BWC — real CAT commands
    ("W%0*d" to set, "W" to query) — but both blocks are wrapped in
    #if 0 and unreachable. rigs/jrc/nrd535.c/nrd545.c's level masks
    even still carry a /*RIG_LEVEL_BWC*/ comment marking where it used
    to be included.

So this was built once, apparently disabled (likely during the 32-bit →
64-bit level-flag migration, since bit 31 was the old scheme's awkward
last bit) and never revived.

For the Yaesu/newcat family specifically, the hard part is already done:
newcat_set_rx_bandwidth/newcat_get_rx_bandwidth already implement
per-mode width get/set correctly — they're just only ever called from
inside set_mode/get_mode, never exposed as an independent level.

One real obstacle, not glossing over it

All 64 bits of the setting_t flag space (CONSTANT_64BIT_FLAG) are
already allocated, up through bit 63. So this isn't just "uncomment the
define" — either an existing, effectively-unused level would need to be
retired to free a bit, or the level-flag representation needs to grow.
That's a maintainer-level design call, not something I can resolve from
outside.

Proposal

Revive RIG_LEVEL_BWC (or a renamed equivalent) on a viable bit, wire
it into newcat's set_level/get_level dispatch for the Yaesu family
by reusing the existing newcat_set_rx_bandwidth/get_rx_bandwidth,
using JRC's disabled implementation as a design precedent for the
get/set shape. I can test against real FT-2000 hardware, and have
bench-measured per-mode width tables for it (#2147) as a correctness
reference.

Analysis of the hamlib source (rig.h, idx_builtin.h, jrc.c) and issue drafted with assistance from Claude (Anthropic).

主要语言
C
星标
851
派生
308
平均合并
5 天 5 小时
30 天内合并 PR
5

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

Hamlib/Hamlib 的其他 Issue

查看 Hamlib/Hamlib 的全部 Issue

相似的 Issue

更多 C Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。