Add flights counter to stats

[TransientTetra]

I'm proposing a new field to be added to stats, flight counter, i.e. number of flights. I used an assumption that a flight counts once the craft is armed and disarmed and a certain time passes between the two (same as other fields); but only once per each battery pack. I also used uint32 for the field, which I feel is a bit excessive; for uint16 max number of flights would be 32768, I'm leaning on your judgement on that matter.

[MrD-RC]

I think uint16_t would be plenty to be honest. That's enough for 1 flight a day for 179 years 🤣

[MrD-RC]

I'm wondering if it needs better detection for incrementing the number of flights. Just relying on the arm/disarm action can provide false positives.

[stronnag]

Please update the PG Template version as you've added a field;

PG_REGISTER_WITH_RESET_TEMPLATE(statsConfig_t, statsConfig, PG_STATS_CONFIG, 1);

i.e. from 1 to 2

[TransientTetra]

Any updates on this?

[breadoven]

Any updates on this?

Seems OK to me other than the minor formatting comment I made.

[OptimusTi]

I'd increase this number to avoid false flights due to distance accumulation during armed workbench tests, if that makes sense.

[TransientTetra]

Any additional suggestions or requests on this? Style now is according to @breadoven request, min flight distance was changed to 30m

[TransientTetra]

Hey, how do we go forward with this?

completed

[sensei-hacker]

It sounds like all of the comments have been addressed.

Has anyone other than the developer tested this? If not, can someone please do so?
In particular, we're interested in testing for anything that might break things, as opposed to it working as expected when all conditions are good. Is there any way this can break the stats screen or otherwise cause a problem?

The request was handled

[sensei-hacker]

/review

[qodo-code-review]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 2 🔵🔵⚪⚪⚪

⚡ Recommended focus areas for review Possible Overflow stats_flight_count is defined as uint16_t, but increments are done via prev_flight_count + 1 without guarding against wraparound or capping at UINT16_MAX. Confirm intended wrap behavior or add bounds checking. void statsOnDisarm(void) { if (statsConfig()->stats_enabled) { uint32_t dt = (millis() - arm_millis) / 1000; if (dt >= MIN_FLIGHT_TIME_TO_RECORD_STATS_S) { statsConfigMutable()->stats_total_time += dt; //[s] statsConfigMutable()->stats_total_dist += (getTotalTravelDistance() - arm_distance_cm) / 100; //[m] #ifdef USE_GPS // flight counter is incremented at most once per power on if (sensors(SENSOR_GPS)) { if ((getTotalTravelDistance() - arm_distance_cm) / 100 >= MIN_FLIGHT_DISTANCE_M) { statsConfigMutable()->stats_flight_count = prev_flight_count + 1; } } else { statsConfigMutable()->stats_flight_count = prev_flight_count + 1; } #else statsConfigMutable()->stats_flight_count = prev_flight_count + 1; #endif // USE_GPS Init Timing statsInit is called late in init(); ensure no arm/disarm events can occur before prev_flight_count is captured, or make prev_flight_count lazy-loaded from statsConfig on first use to avoid a stale zero if ordering changes. void statsInit(void) { prev_flight_count = statsConfig()->stats_flight_count; } GPS Distance Threshold When GPS is present, flights shorter than MIN_FLIGHT_DISTANCE_M are not counted; when GPS absent, all qualifying time flights are counted. Verify this asymmetric behavior is intended and won’t penalize indoor GPS-enabled use or cold-starts with low distance due to poor fix. #ifdef USE_GPS // flight counter is incremented at most once per power on if (sensors(SENSOR_GPS)) { if ((getTotalTravelDistance() - arm_distance_cm) / 100 >= MIN_FLIGHT_DISTANCE_M) { statsConfigMutable()->stats_flight_count = prev_flight_count + 1; } } else { statsConfigMutable()->stats_flight_count = prev_flight_count + 1; } #else statsConfigMutable()->stats_flight_count = prev_flight_count + 1; #endif // USE_GPS