Blackbox estimated data logging time

[Remleyfpv]

Is your feature request related to a problem? Please describe

It would be nice to get an estimated logging time in the blackbox section of BF configurator. So that the user will now how long he can tune before blackbox is full

Describe the solution you'd like

A simpel textbox in the betaflight config window that calculates the datarate (would be cool to see that too in mb/s) of the blackbox logging and looks at the size left of the onboard blackbox storage. And then calculates the estimated logging time.

Describe alternatives you've considered

calculating it myself but thats a hassle with the new optional logging points

Other information

No response

[YarosMallorca]

I'm going to look into this.
Does anyone know how to calculate the space per sample when given a debug log mode?

[haslinghuis]

Guess this would depend on logging rate, perhaps number of debug fields in the debug and maybe gyro and pid loop time.
Flash device speed (NOR / NAND) and driver optimization also matters for the timing part.
It is also possible to disable certain data included in the log reducing size.

[ramonsaraiva]

Maybe getting to an approximate number can be a start?

It sounds pretty complex to get to a good final bytes per frame

bytes_per_frame =
    base_frame_overhead +
    (n_motors * motor_output_bytes) +
    (3 * gyro_bytes) +
    (3 * pid_controller_bytes) +
    (rc_input_bytes) +
    (debug_bytes) +
    ...

but could we specify an average that could work for most debug modes? e.g. 30-60 bytes per frame

Then I guess the logging sample rate would be
logging_sample_rate = pid_loop_frequency / logging_rate
e.g. ratio 1:2 and PID loop 8,000 Hz
logging_sample_rate = 8000 / 2 = 4000

And the data rate in bytes/sec would be
data_rate = logging_sample_rate * bytes_per_frame

Then finally we could compute the amount of seconds we could store based on the capacity of the logging medium

log_time_seconds = storage_bytes / data_rate

A full example:

PID loop: 4 kHz = 4,000 Hz
Blackbox ratio: 1:2 (2,000 frames/sec)
Frame size: ~40bytes/frame (example)
Onboard flash: 8MB = 8,388,608 bytes

logging_sample_rate = 4000 / 2 = 2000 frames/s
bytes_per_frame = 40 bytes
data_rate = 2000 * 40 = 80,000 bytes/s
log_time_seconds = 8,388,608 / 80,000 ~= 105 seconds ~= 1.75 minutes (1m45s of available logging)

I'm down to play around with this if we could start with an average bytes per frame value, and then possibly improve the precision of this in the future.

[haslinghuis]

Perhaps @demvlad can help with some python code to reveal some data here

[demvlad]

I have not python code for this.
My blackbox explorer algorithm checks real log data rate as log_rows_count/log_time_length.
This value is not just equal required log rate in really. Its have some difference. If error is great than 5%, then red warning is showed in BBExplorer status line. And spectrum graphs uses real log rate instead of required in this case.
You can use black box decode tools to get csv file from source log and see how log works. The csv file contains simulation tact counter and simulations time value. The log records are not just regular in the really...
... the raw log data format is not easy. The some data have different log time interval and data coding (compression) are exists too. Therefore using of tottal file size and time is not correctly i think.