betaflight
betaflight copied to clipboard
betaflight
Rolling blackbox storage
Is your feature request related to a problem? Please describe
When storage is full, no new blackbox logs will be stored. I would like to have blackbox logging enabled at all times so that when something happens, I have a blackbox to analyze. But I don't want to check regularly if there is still sufficient free storage for new blackboxes to be recorded.
Describe the solution you'd like
When storage is full, begin overwriting existing blackboxes starting with the oldest (rolling method).
Describe alternatives you've considered
None.
Other information
Would be good to have this as an option we could turn on or off, so for anyone that prefers the way it works today, he/she would still be satisfied.
Flash erase is slow (up to seconds). It would be necessary to buffer BB data during this time.
That's a valid point and perhaps buffering introduces additional performance drawbacks. Just thinking out loud here.. Let's say we reserve xx% of storage to be free at all times and have the erasing algorithm running at all times until that xx% (so also when disarmed and not recording blackboxes). Could that work reliably?
It will be possible, but considerable code changes would be necessary. IIRC BF firmware simply uses flash as one large block, always appending data at the end.
BLACKBOX ERASE mode is available, but not that useful.
Any volunteer?
Sorry to say, if you call it "blackbox" let it behave like "black box". Overwrite old records with new ones. No much use of stale records. Otherwise call it not "black box" but "log for turning"
@albert0ly: I'd gladly review your PR that will make "blackbox" behave like "black box"
Create a new file each 1MB, first in first out. I don't know how the logging and flashing works though. Is it deleting files or reformatting the chip? I would imagine the latter would be a slower process.
When the current implementation creates a new file, does each file represent an arm/disarm? If so, I would think it would be a matter of seeing if it's possible to switch it to creating files on a size limit and then deleting in sequence as the storage fills. On startup, check storage size, establish max number of 1MB files that can be created, when the limit is reached, delete first incremented file. So if a chip is 8MB, it can create up to 8 log files but probably on the 5th or 6th it should start deleting the first though I don't know if the storage in these things or the operating system is designed to write to one file while erasing another file at the same time :/
Arm/disarms are flagged in the files rather than creating new files. The log analyzer would merge the files, and split flights based on arming flag. It seems like it would take a change to both the BF firmware as well as the log file analyzer.
Sorry to say, if you call it "blackbox" let it behave like "black box". Overwrite old records with new ones. No much use of stale records. Otherwise call it not "black box" but "log for turning"
Either way, I would think a "log for tuning" would be a rolling storage just as a "black box" would. If I'm going to fly my quad around and then analyze something I did, the thing I am interested in is probably in the last bit of flying before the logging stopped :/
Hi there, have there been any developments on this issue in the meantime? :)