Conversation
Saving the configuration already beeped, but it used beeperConfirmationBeeps(1), a single 20 ms tick that is identical to the generic single-beep acknowledgement emitted for blocked arming and for inflight adjustments. Without an OSD there was no way to tell a completed write from any other stick command acknowledgement. processSaveConfigAndNotify() now plays BEEPER_ACTION_SUCCESS instead, two short 50 ms beeps. It is emitted after writeEEPROM() and readEEPROM() have returned, so it confirms that the settings really were written and read back, not merely that a stick gesture was seen. BEEPER_ACTION_SUCCESS is an existing table entry, already used for the waypoint list save and load in the same stick command handler, so the sound is one pilots already associate with "that worked". Reusing it leaves the beeperMode_e ordering, the beeper name table and the beeper mask bit numbering exposed over MSP untouched. The beep belongs in the save path rather than in the stick handler because the gesture only queues the write, the commit itself happens in a later loop iteration via processDelayedSave(). Placing it there also covers the remaining notify-saves, which is intended: every one of them already raises the OSD "EEPROM SAVED" notification, so the audible cue now matches the visual one. Configurator saves are unchanged, as MSP_EEPROM_WRITE does not use this path, and profile switching is unchanged as well, since it writes the EEPROM directly and keeps its "N beeps means profile N" confirmation. Ref iNavFlight#8359
Raffi1202
marked this pull request as ready for review
September 11, 2026 15:39
Contributor
|
ⓘ Qodo reviews are paused because the subscription is no longer active. Ask your workspace admin to reactivate the subscription to resume reviews. Manage billing |
PR Summary by QodoPlay distinct success beeps after configuration saves
AI Description
Diagram
High-Level Assessment
Files changed (1)
|
Code Review by Qodo🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)
Great, no issues found!Qodo reviewed your code and found no material issues that require reviewTip of the day💡 Did you know, you can switch off images and animations for a plain-text comment |
A save by stick command now plays this sequence, so the row needed the second meaning. Its index and name were also stale: the table said 10 ACC_CALIBRATION where beeper.c has 11 ACTION_SUCCESS. Only this row is corrected - the rest of the table is off by one against beeper.c and is worth its own pass.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Saving settings with the stick command gives no audible sign that the save actually completed. The reporter of #8359 flies without goggles when maidening and tuning: the beep after the gesture only says that some stick input was seen, so a wrong gesture and a completed save sound the same, and the OSD "EEPROM SAVED" notice is not visible. Fixes #8359.
Cause
src/main/fc/config.c:381on maintenance-10.x:processSaveConfigAndNotify()callsbeeperConfirmationBeeps(1), a single 20 ms tick (src/main/io/beeper.c:156). The same tick is used for a blocked arm (src/main/fc/fc_core.c:643), a flight-mode change (src/main/fc/runtime_config.c:100) and a downward inflight adjustment (src/main/fc/rc_adjustments.c:381).Change
Replaces the tick with
beeper(BEEPER_ACTION_SUCCESS), the existing two-short-beeps sequence (src/main/io/beeper.c:117) that the stick handler already plays for waypoint list save and load (src/main/fc/rc_controls.c:273). It sounds afterwriteEEPROM()andreadEEPROM()return, so it reports the completed write, not the gesture. EverysaveConfigAndNotify()caller (stick command, CMS, calibrations, autotrim) gets the same sequence; Configurator saves viaMSP_EEPROM_WRITE(src/main/fc/fc_msp.c:3088) do not use this path and are unchanged. No new setting, beeper mode or MSP change.Test
Not run on hardware or SITL. Cause verified by reading the files above on maintenance-10.x;
Flash / RAM
Not measured yet. The upstream firmware CI has not been released for this PR, so no size report exists.
Docs
docs/Buzzer.md: the success-beep row now names the settings save as a second meaning. Its index and name were also stale (the table said 10 ACC_CALIBRATION wherebeeper.chas 11 ACTION_SUCCESS) and are corrected. The rest of that table is off by one againstbeeper.cand is left for its own pass.