What is a flight log?
Solo’s ridiculous amount of computer overhead means the system can record a ridiculous amount of flight information in real time. We collectively call this information Solo’s “flight logs.”
Solo records 500 parameters of operational data at 20 Hz (meaning 20 times every second). It’s an almost unimaginably large store of information. You can “pull” these logs from Solo onto your computer and analyze them yourself for what you could call a highly technical story of your flight. Logs look like computer code. (In this regard, Solo isn’t exactly an exciting storyteller.)
If you’re interested in learning how to read flight logs, you can check out this tutorial.
Even more importantly, though, you can share your flight logs with us. And unlike any other drone out there, we record flight logs to the controller as well as to the drone. This means that even if you lose your drone, you still hold the “black box” in your hands and can send us your flight data immediately through the Solo app — even while you’re still in the field.
Additionally, flight logs are useful diagnostic tools for our tech support team: They can see exactly what happened in flight and when and where it happened. They’re also great information for our engineers developing the next updates for Solo.
Here’s a top-level explanation of what exactly flight logs are, what kinds of data different log types record and why it’s all useful and important to you.
Types of logs
Solo records several types of flight logs. These are mostly categorized according to which part of the Solo system they monitor (as you’ll see here, Solo is an incredibly complex system). Some of these categories are logs for the controller, the WiFi link, Smart Shots and telemetry. Here’s a breakdown of the most important logs — what data they record, and why that’s useful.
RC logs: This information mainly concerns the controller and its communication with Solo. RC logs monitor this communication (WiFi, via SoloLink) as it pertains to command and control — that is, what you have Solo do with your controller. When the WiFi signal gets from the controller in your hands to the autopilot in the copter, SoloLink has to convert that WiFi language to something called PWM, which is the language that the autopilot understands. If there’s a break in communication or some other error, we’ll see it in the RC logs.
In simple terms, RC logs show us what the user asks Solo to do and how that information has been communicated and translated.
Solo logs: This is like Solo stretching out before its flight. Solo logs record a top-down system check, a self-diagnosis that Solo performs each time you power up. Solo logs record these data from all of its major internal mechanisms: the autopilot firmware and status; Sololink firmware and status; WiFi initiation; and the controller firmware. This is Solo making sure everything’s in sync. This information is useful because if, for instance, your controller for some reason doesn’t pair with your copter, we can see exactly where the hiccup was by reading the Solo log.
Wifi logs: This is the record of your WiFi signal strength and the integrity of the connection between SoloLink’s sending and receiving hubs. One of these hubs is on the controller, created by the controller’s computer; the other is on the copter, created by the copter’s computer. If your WiFi drops any information (called “packets”) in transmission, that shows up here, too.
Data flash logs: One of the more critical logs, data flash is the record of all of the detailed information from the actual flight. This includes read-outs for all of the autopilot’s IMU sensors (accelerometers, gyros, and the two barometric altimeters), as well as Solo’s GPS and compass readings.
These data let us see the story of Solo’s orientation, direction, speed and behavior during your flight. The data flash logs are also a record of all user inputs. This means that when taken all together, we can three things: your inputs; what the copter wanted to do; and then what actually happened. If there’s an error in flight, we can check these three things against each other and find the root of the problem. From this we will know for sure whether it’s user error or something in the system itself.
Importantly for you, data flash can serve as your evidence: These logs hold all parties accountable, so our customer support is guaranteed to be totally transparent. These logs are currently saved on the SD card that plugs into Solo’s autopilot. We’re working on pulling them to the controller’s computer in a future update.
However, even if you lose the copter, you can still send us your flight evidence. To do this, you’d share your…
Telemetry logs: Data about “the pipe.” Telemetry data are shown on both your controller screen and your Solo app screen; they include stuff like altitude, heading, speed, etc. These data are sent from Solo to your controller through SoloLink’s WiFi. The telemetry flight log is a record of how long it takes to send each packet of information through the SoloLink “pipe,” how big each packet of information is, etc. Basically, the telemetry log records how and how well the flight information that you see on your controller screen has been transmitted.
The T-log also provides us with user input information and allows us to check that against Solo’s behavior. This is your evidence. For an example, check out the header image of this blog. You can see what Solo did, and you can see what the user asked it to do. In this case we can clearly see and show that the cause of the crash was user input and not system error.
Shot logs: Information about Smart Shot commands. Among other things, shot logs record how your controller buttons are programmed, as well as all GoPro information, such as the mode, battery life and when you start and stop recording.
Also, when you’re flying, the data about where Solo is supposed to point are sourced through the Solo app, and then sent as instructions to the copter through SoloLink. The shot log shows all of those actions. This means that when you set up a Smart Shot and press “play” on the app, the shot log will say, “sending Solo to x orientation at x altitude.”
Why do we record all of this stuff?
How do we use logs?
Most importantly, we do all of this so that in the case of error or a crash we (and users, if they’re familiar enough with this technology to read the logs themselves) can see exactly what went wrong. And because you hold the black box in your hands, we’ll be able to help you even without the data from the copter. Only Solo’s dual computers can deliver this.
We (and you) can also see if anything about the copter isn’t performing well. In other words, we can monitor the health of the vehicle. For instance, if one motor is taking more amps than the others, we can anticipate that motor will burn out sooner.
Our engineers also use log data internally to tweak and improve performance. The bigger and better the logs, the more comprehensive the picture we have of Solo, and the greater possibility we have for improvements. Flight data also hold possibilities for new technology and innovations that can tap into this information in real time. Basically, the more information there is to access, the greater the possibilities for using that information in an innovative way.
Is this a privacy or security issue?
You should have no more concern about privacy with flight logs than you have with something like Facebook. Well, no, don’t freak out because that’s a bit of an overstatement. That’s because unlike Facebook, with Solo you yourself have to make the conscious decision to send us your data. And even if in the future these flight data get integrated into social platforms, it will be on an opt-in basis.