aethersdr / aethersdr/AetherSDR

Keyboard and Midi Commands to navigate the spectrum

Open
#4,358 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement external devices GUI maintainer-review spectrum
Dominant language
C++
Stars
221
Forks
117
Avg merge
2d 7h
Merged PRs (30d)
299

Description

Request preparation
  • I used an AI assistant to help structure this request
  • I checked for existing issues covering the same feature
What would you like?

Add keyboard and MIDI navigation between detected signals

What

Add commands that tune the active receiver to the next or previous detected signal in the panadapter.

The commands should be available through:

  • Configurable keyboard shortcuts
  • MIDI mappings
  • Other external-control mappings supported by AetherSDR

The initial implementation should focus on practical spectrum-navigation features suitable for normal and contest operation:

  • Move to the next signal above the current frequency
  • Move to the previous signal below the current frequency
  • Fine-tune the selected signal up or down
  • Optionally snap spectrum clicks to the nearest detected signal
  • Stop cleanly at the visible spectrum boundaries, or recenter the panadapter when appropriate

Why

During busy-band operation, operators frequently need to move quickly between visible signals. At present, this requires clicking each signal accurately or manually turning a tuning control until it is centred.

Keyboard and MIDI commands for moving between detected signals would make band searching substantially faster, particularly for:

  • Contest operation
  • CW operation
  • Operators using MIDI control surfaces
  • Operators who prefer keyboard-driven workflows
  • Users working with dense panadapter displays
  • Users with limited mouse precision or accessibility requirements

This is different from ordinary frequency-step commands. A fixed tuning step moves by a predetermined number of hertz, whereas signal navigation moves directly to the next spectral peak that AetherSDR has identified as a likely signal.

How Other Clients Do It

N1MM Logger+ and DXLog provide spectrum-aware navigation intended for contest operation.

In N1MM:

  • Shift+Up moves to the next detected signal above the current frequency.
  • Shift+Down moves to the next detected signal below the current frequency.
  • Signals can be skipped when they represent duplicates or stations that are not workable.
  • Navigation stops at the spectrum limits and can recenter the spectrum when necessary.
  • The normal Up and Down keys can fine-tune the selected signal.
  • An optional “Snap to signal” mode tunes to the nearest signal when the spectrum is clicked.
  • The signal-detection threshold can be adjusted to control which peaks are considered signals.

Some N1MM features depend on its logging database, such as skipping duplicate contacts and selecting recommended CQ frequencies. Those features are outside the scope of the initial AetherSDR implementation unless a logger or automation integration can provide the required information.

The core next-signal, previous-signal, fine-tuning and click-to-snap behaviour is useful independently of a logging application.

Suggested Behavior

Configurable actions

Add the following actions to AetherSDR's keyboard and external-control command system:

  • Tune to next detected signal
  • Tune to previous detected signal
  • Fine tune signal up
  • Fine tune signal down
  • Toggle snap to signal
  • Optional: Adjust signal detection threshold

These actions should be assignable from the existing keyboard-shortcut and MIDI/Aether Control mapping interfaces.

Suggested default keyboard shortcuts, where they do not conflict with existing mappings:

  • Shift+Up: next detected signal
  • Shift+Down: previous detected signal
  • Up: fine-tune upward
  • Down: fine-tune downward

The shortcuts must remain configurable.

Signal detection

The spectrum display should maintain a list of candidate signals derived from the FFT data currently visible in the panadapter.

A candidate signal should normally:

  • Exceed an adjustable threshold above the estimated noise floor
  • Represent a local spectral peak rather than every FFT bin above the threshold
  • Be separated from adjacent candidates by an appropriate minimum bandwidth
  • Remain stable enough that minor FFT fluctuations do not constantly change the navigation order

Detection parameters may initially use sensible defaults, with advanced controls added later.

Navigation

When the user invokes next or previous signal:

  1. Determine the target RxApplet or slice using the same active-slice rules used by other tuning commands.
  2. Find the nearest qualifying signal in the requested frequency direction.
  3. Tune the slice so the signal is positioned at the appropriate receive passband or CW pitch.
  4. Briefly highlight the selected peak in the panadapter.
  5. Update the corresponding VfoWidget and RxApplet normally.

For CW modes, the tuned frequency should account for the configured CW pitch and CW/CW-R direction so that the detected carrier produces the expected audio tone.

For SSB and other wider modes, the initial implementation may tune to the detected peak or use a mode-appropriate offset.

If no signal exists in the requested direction:

  • Do not wrap unexpectedly to the opposite side.
  • Stop at the visible spectrum boundary, or recenter/scroll the panadapter and continue only when that behaviour is enabled.
  • Give subtle visual feedback indicating that no further signal was found.
MIDI support

Expose next-signal and previous-signal as discrete MIDI actions so they can be assigned to:

  • Buttons
  • Pads
  • Encoder presses
  • Relative encoder movements

For a relative encoder, clockwise movement could invoke next signal and anticlockwise movement could invoke previous signal.

The MIDI action should support the same target selection as other receiver controls:

  • Active slice
  • A specifically configured slice, where supported by the existing MIDI mapping model
Snap to signal

Add an optional Snap to signal setting to the panadapter or spectrum context menu.

When enabled:

  • Clicking close to a detected signal on the spectrum tunes to the detected peak rather than the exact clicked FFT position.
  • Snapping only occurs within a configurable or sensible maximum distance, for example approximately 2 kHz.
  • Clicking the waterfall may retain its existing exact-frequency behaviour.
  • The selected signal should be briefly highlighted so the user can see where AetherSDR snapped.

Possible UI locations include:

  • Panadapter right-click menu
  • Spectrum settings in AppletPanel
  • An advanced section of RxApplet
  • Keyboard and MIDI mapping settings

Protocol Hints

Signal detection should be primarily client-side because AetherSDR already receives FFT/panadapter data through the radio's VITA-49 spectrum stream.

Likely implementation areas include:

  • FFT/panadapter data processing
  • Noise-floor estimation
  • Peak detection and peak grouping
  • Active-slice resolution
  • AppletPanel
  • VfoWidget
  • RxApplet
  • Keyboard shortcut actions
  • MIDI/Aether Control mappings

Once a target frequency has been selected, AetherSDR should tune the relevant Flex slice using the same slice-frequency mechanism used by existing direct tuning actions.

Exact FlexLib command details: Unknown — needs research.

No new radio-side protocol capability should be required if signal detection and navigation are performed within the client.

Acceptance Criteria

  • Users can assign keyboard shortcuts for tuning to the next and previous detected signals.
  • The same next/previous-signal actions can be assigned to MIDI buttons or relative encoders.
  • Navigation uses detected spectral peaks rather than fixed frequency steps and operates on the intended active or mapped slice.
  • Signal detection uses a noise-relative threshold and avoids stopping repeatedly on adjacent FFT bins belonging to the same signal.
  • Optional snap-to-signal behaviour tunes spectrum clicks to a nearby detected signal and provides visible feedback.

Suggested Labels

  • enhancement
  • spectrum
  • GUI
  • external devices

Contributor guide

Open the contributing guide

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.

Research direction

Start by tracing the existing FFT/panadapter processing and the keyboard, MIDI, and direct-tuning command paths. Inspect AppletPanel, VfoWidget, and RxApplet to understand active-slice selection and spectrum interaction. Done means detected peaks can drive next/previous and fine-tuning actions through keyboard and MIDI mappings, with optional click snapping and visible feedback meeting the listed acceptance criteria.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
desktop
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
28/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.