Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
  • Is something wrong?
#2,148 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
c
Domain
backend-api-design

Research direction

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.

Written by the indexing model from the issue text.

Description

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).

Dominant language
C
Stars
851
Forks
308
Avg merge
2d 21h
Merged PRs (30d)
9

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Hamlib/Hamlib

All issues in Hamlib/Hamlib

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.