From 57fe5377b2a872fbd8f6662c877dd15c6c21589a Mon Sep 17 00:00:00 2001 From: Raphael Hunziker Date: Thu, 10 Sep 2026 22:31:44 +0200 Subject: [PATCH 1/2] beeper: play the success sequence when a config save completes 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 #8359 --- src/main/fc/config.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/main/fc/config.c b/src/main/fc/config.c index 5e1c87ac145..f9fddd848e9 100755 --- a/src/main/fc/config.c +++ b/src/main/fc/config.c @@ -378,7 +378,8 @@ void processSaveConfigAndNotify(void) writeEEPROM(); readEEPROM(); resumeRxSignal(); - beeperConfirmationBeeps(1); + // Distinct sequence so the pilot can tell a completed save from a plain stick command acknowledgement + beeper(BEEPER_ACTION_SUCCESS); #ifdef USE_OSD osdShowEEPROMSavedNotification(); #endif From af21965b16d4e0e324c2c043898885051fc888a7 Mon Sep 17 00:00:00 2001 From: Raphael Hunziker Date: Sun, 13 Sep 2026 21:22:11 +0200 Subject: [PATCH 2/2] docs: cover the settings save in the success beep row 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. --- docs/Buzzer.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/Buzzer.md b/docs/Buzzer.md index 19969a4a6b8..1d94e5428f2 100644 --- a/docs/Buzzer.md +++ b/docs/Buzzer.md @@ -36,7 +36,7 @@ Sequences: 7 BAT_LOW 25, 50 Battery is getting low (repeats) 8 NULL multi beeps GPS status (sat count) 9 RX_SET 10, 10 RX is set (when aux channel is set for beep or beep sequence how many satellites has found if GPS enabled) - 10 ACC_CALIBRATION 5, 5, 5, 5 ACC inflight calibration completed + 11 ACTION_SUCCESS 5, 5, 5, 5 An action succeeded: ACC inflight calibration, or settings saved by stick command 11 ACC_CALIBRATION_FAIL 20, 15, 35, 5 ACC inflight calibration failed 12 READY_BEEP 4, 5, 4, 5, 8, 5, 15, 5, 8, 5, 4, 5, 4, 5 GPS locked and copter ready 13 NULL multi beeps Variable # of beeps (confirmation, GPS sat count, etc)