The screenshot confirms it nicely — the VFO shows 7.188.060 when 7.188.000 is expected after a clean entry. Here's your report:

Title: FlexControl knob adds spurious +60 Hz offset on every tune step (macOS)

What happened?

When tuning with a FlexControl knob on macOS, each tune event applies an unwanted +60 Hz offset on top of the intended step. The offset appears to be sticky: even after manually typing a frequency ending in .000, turning the FlexControl immediately shifts the displayed frequency to .060 (or a multiple thereof). The VFO never lands on a clean integer-Hz value when the FlexControl is used. The attached screenshot shows 7.188.060 displayed after the user expected 7.188.000.

What did you expect?

Each FlexControl detent should move the VFO by exactly the selected step size (e.g. 100 Hz, 1 kHz) with no residual offset. After typing 7.188.000 and then nudging the knob one step, the display should show 7.188.100 or 7.187.900, not 7.188.060.

Steps to reproduce

1. Launch AetherSDR 26.5.3 on macOS with an AU-520 connected (fw 4.2.18.41174).
2. Connect a FlexControl knob via USB.
3. Type 7.188.000 (or any clean kHz-aligned frequency) directly into the VFO and confirm with Enter.
4. Verify the VFO reads exactly 7.188.000.
5. Turn the FlexControl one detent in either direction.
6. Observe that the displayed frequency is 7.188.060 (or 7.187.940) rather than the expected step-aligned value.
7. Repeat: type .000 again, turn the knob again — the +60 Hz offset reappears consistently.

Radio model & firmware

• Radio: AU-520
• Firmware: 4.2.18.41174

OS & version

• OS: macOS (version not specified)
• AetherSDR: 26.5.3
• Qt: 6.11.1

Developer Notes

Likely root cause — macOS HID input accumulation or step resolution mismatch:

The most probable cause is that the FlexControl HID driver on macOS is reporting relative encoder delta values that include a fractional or sub-step accumulation before AetherSDR flushes them to the radio. The persistent +60 Hz strongly suggests a fixed residual in the encoder delta-to-Hz conversion, or a Hz-resolution mismatch between the HID tick count and the step size divisor.

60 Hz is suspicious in a US/60 Hz AC context but is almost certainly coincidental — more likely it is 60 = 6 × 10 (one extra tick being counted at 10 Hz/tick resolution) or an accumulator that is initialized to 60 rather than 0.

Files and functions to investigate:

• src/core/ — look for a FlexControl, HidController, KnobController, or EncoderInput class. The delta-to-frequency conversion and any accumulator reset logic live here.
• src/models/SliceModel — specifically the method that accepts a frequency nudge command and calls slice m <freq> pan=<panId> (per CLAUDE.md, this is the correct click-to-tune path). Check whether the frequency value passed to the command is read directly from the model or computed from a running accumulator.
• src/gui/MainWindow — check how FlexControl HID events are wired to slice frequency updates. On macOS, Qt HID input arrives differently than on Linux; look for any #ifdef Q_OS_MAC blocks around encoder handling.
• Any AppSettings key related to FlexControlStep, EncoderResolution, or KnobStepHz — verify the stored value is not 60 or a multiple.

Protocol note (from CLAUDE.md):
Slice frequency is RF_frequency in status messages, not freq. Confirm the tune command sent to the radio via logs is slice m <expected_freq> and that no rounding or post-processing step is adding 60 Hz before or after the command is dispatched.

Logging to enable (Help → Support):

Enable these categories before reproducing:

• protocol — to capture the exact C<seq>|slice m <freq> commands sent and the R<seq> responses, confirming what frequency AetherSDR is actually commanding.
• hid or input (if present) — to see raw FlexControl delta values as received from the macOS HID stack.
• slice — to trace applyStatus calls and verify whether the +60 appears before or after the radio echoes the status back.

Attach the resulting support log along with a Wireshark or tcpdump capture of the TCP stream (port 4992) filtered to slice m commands if the support log alone does not show the commanded frequency.

support-bundle-20260528-232422.tar.gz