Signed in as:
Signed in as:
'ThrottleRamp-YourName-Rig.bbl' , 'PDbal-Tests-YourName-Rig.bbl' , 'MasterMult-Tests-YourName-Rig.bbl', and so on)
A 'throttle ramp' is a flight with a slow 0 to 100% throttle increase, typically ~5-10 seconds in duration. It is the primary method of analyzing un-commanded motion and vibration (example throttle ramp)
Under CLI, type 'set debug mode = gyro_scaled' (Betaflight / Emuflight), 'set debug mode = gyro' (INAV)
Besides the issue of limited storage space, all the necessary information about a drone can be gathered in less than 1min. PTB runs off a single core of a computer and tends to function very slowly with large log-files. In fact, the key tests for the PTB tuning method requires only a ~15sec throttle ramp, or a 20-30sec step response test. Final test flights of ~2min are about as large as log-files ever should be.
If logging is not assigned to a switch, Betaflight makes individual subfiles each time you arm, and it's common for pilots to sometimes quickly arm then disarm as a quick check that the rig is ready to go. The problem with this is it makes unusable subfiles that sometimes confuse PTB when trying to properly associate the bbl header with the proper csv file extracted by the blackbox_decode program. The best practice is to put logging on a switch and only switch logging on when you are ready to fly and collect data. The recommended steps should be as follows: (1) log switch on, (2) arm, (3) fly, (4) land/disarm, (5) log switch off.
As flight firmware and multi-rotor technology advances, the quality of your RC signal becomes ever important (especially for Betaflight's feedforward system). This is especially important for crossfire (crsf) users, who still make up 90% of the cinelifter community. If you use crsf, make sure your running crsf-shot, and that you're updated to the latest openTX or whatever radio protocol you're using (e.g., freedomTX, or edgeTX). Also, for crsf users, do not use dynamic rx mode; lock at 50hz or 150hz (for cinelifter guys I recommend 50Hz, as lower rates will be a more rock solid signal; you don't want to fall out of the sky with an expensive cam on board). I am no expert on all the available radio firmwares but I know a bad RC signal when I see it and it can really ruin your copter's flight characteristics and smoothness. So do a Google and YouTube search on your particular radio and firmware. There are tons of resources out there these days, and it will serve you well to get this right. Here are a few links I found very useful:
Stating the obvious here, but once you have a tuned rig that's flying well, save the settings. In CLI type 'diff all', then save the contents to a file for future reference. 'dump all' is too extensive and unnecessary. 'diff all' contains all the info you need and it's easy to find the necessary parameters without having to go through a mountain of information.