Skip to content

Conversation

@sensei-hacker
Copy link
Member

@sensei-hacker sensei-hacker commented Dec 23, 2025

User description

Summary

Rate-limit updateArmingStatus() from every PID loop iteration (2000 Hz) to 200 Hz, reducing CPU overhead by 10-13%.

Changes

  • Added rate divider to call updateArmingStatus() every 10th PID loop iteration
  • No functional change to arming safety checks, LED updates, or status monitoring

Rationale

The updateArmingStatus() function performs 20+ safety checks (GPS fix quality, battery voltage, sensor health, failsafe status, LED indicators) that don't require millisecond-level updates:

  • GPS updates at 5-10 Hz
  • Battery voltage changes gradually
  • Human reaction time is ~200ms
  • 200 Hz (5ms response) is well within safety margins

Testing

Tested on AT32F435 hardware (BLUEBERRYF435WING):

  • Before: 187 µs average PID loop time
  • After: 163 µs average PID loop time
  • Improvement: 24 µs (12.8%)

All arming safety checks, LED indicators, and mode switching remain fully functional.

Impact

  • Benefits all INAV targets (F4, F7, H7, AT32)
  • Frees CPU headroom for navigation features
  • No settings changes required
  • No breaking changes

PR Type

Enhancement


Description

  • Rate-limit updateArmingStatus() from 2000 Hz to 200 Hz

  • Reduces CPU overhead by 10-13% on PID loop execution

  • Maintains all safety checks and functional behavior

  • No configuration changes or breaking changes required


Diagram Walkthrough

flowchart LR
  A["PID Loop 2000 Hz"] -- "every 10th iteration" --> B["updateArmingStatus 200 Hz"]
  B --> C["Safety Checks"]
  B --> D["LED Updates"]
  B --> E["Status Monitoring"]
  C --> F["No Functional Impact"]
  D --> F
  E --> F
Loading

File Walkthrough

Relevant files
Enhancement
fc_core.c
Implement rate divider for updateArmingStatus() function 

src/main/fc/fc_core.c

  • Added static rate divider counter to skip updateArmingStatus() calls
  • Executes updateArmingStatus() every 10th PID loop iteration instead of
    every iteration
  • Reduces function call frequency from 2000 Hz to 200 Hz
  • Added explanatory comment documenting the 200 Hz rate-limiting
+6/-1     

The updateArmingStatus() function performs 20+ safety checks (GPS fix,
battery voltage, sensor health, LED updates, etc.) that don't need
millisecond-level updates. Previously called every PID loop iteration
(2000 Hz), now rate-limited to 200 Hz.

Testing on AT32F435 hardware showed 10-13% PID loop performance
improvement with no functional impact. 200 Hz (5ms response time)
is well within human reaction time (~200ms) and exceeds the update
rate of the sensors being checked (GPS: 5-10 Hz, battery: slow).
@qodo-code-review
Copy link
Contributor

ⓘ Your approaching your monthly quota for Qodo. Upgrade your plan

PR Compliance Guide 🔍

All compliance sections have been disabled in the configurations.

Comment on lines +947 to +951
static uint8_t armingStatusDivider = 0;
if (++armingStatusDivider >= 10) {
armingStatusDivider = 0;
updateArmingStatus();
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggestion: Replace the iteration-based counter with a time-based check using currentTimeUs to ensure updateArmingStatus() runs at a consistent 200 Hz. [general, importance: 7]

Suggested change
static uint8_t armingStatusDivider = 0;
if (++armingStatusDivider >= 10) {
armingStatusDivider = 0;
updateArmingStatus();
}
static timeUs_t lastArmingStatusTimeUs = 0;
if ((int32_t)(currentTimeUs - lastArmingStatusTimeUs) >= 5000) {
lastArmingStatusTimeUs = currentTimeUs;
updateArmingStatus();
}

@sensei-hacker sensei-hacker added this to the 9.1 milestone Dec 23, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant