Feature: G-Load and Speed Exceedance Storage

[AndHager]

Removed delay for G-Load digital display in order to enhance usability for aerobatics.

Implemented:

• Speed, G-Load and exceedance duration storage, to be able to track excesses.
• Web frontend for querying and deleting exeedances.
• Web backend handling of the requests

[iltis42]

Great work, will check this closer next day's.
In general there are ideas from several acrobatic pilots close to my place:

• Reset the current maxima automatically with each flight (e.g. by airspeed lower than 30 km/h for a minute)
• Save the a history of the maxima of last 20 flights in cyclic history record
• Provide means to download this history (if there is flarm, preferrably together with date, or just flight #N-1, #N-2 ...)

Just to provide a future vision, and maybe you have more ideas and time to add parts of this ^^^^ ?

[AndHager]

Currently, I track all exceedances for G-Loads greater than 10 G or smaller -7.5 G and speed greater than 285 kmh.
These rows of the two float values (Speed, G-Load) are stored with the Preferences API in a 20 KB (should be enugh?) storage and are accessible via the Web-Frontend as shown in the image.

The Download Button downloads all exceedance values in a CSV file sorted by it's the occurrence.
So the first entry is the oldest and the last is the newest (Implicit numerated by order).
Then these file can be analyzed separately.

The Clear button deletes all entries and frees the permanent memory.

Currently, I plan on implementing the following points relate to this feature (and maby more... :) ):

• Configurable bounds for the upper and lower G-Load as well as for the speed
• Dynamic bounds (express the G-Bounds as a function of the Speed [Flight Envelope])

[iltis42]

The excess based on the flight envelope might be a good point. I see above e.g. 180 km/h the maximum load gets lower, and should be configurable and regarded.
Beside the .csv download, later it may also be useful to provide tab created on the device that already shows the data in a readable format, e.g. green/yellow/red background, red of course when there was an excess, green when all was okay.
20K of date might be a bit much with the current ESP32 with two banks of 2MB, hence not needed maybe. Not every 0.1 second a value might be needed to be stored, it could be recorded how long there this limit was overstepped a a certain time and or flight.

[AndHager]

Well I currently only track excesses so everything would be yellow/red, or do I misunderstand you?

Good point, I'll implement the timebased overstep tracking.

[iltis42]

Yes, i see, in your PR currently only excesses are tracked, normal G meters track also maxima/minima. Maybe we can bring that together.

[AndHager]

Yes, i see, in your PR currently only excesses are tracked, normal G meters track also maxima/minima. Maybe we can bring that together.

Of course, I can write an entry for every max/min update in it's own namespace (to avoid confusion and extra memory usage for a flag).