Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#2,148 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 4 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
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時間
マージ済み PR（30日）
5

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

Hamlib/Hamlib のほかの issue

Hamlib/Hamlib の issue をすべて見る

似ている issue

C の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。