More documentation is currently being developed. I want to include the latest upcoming firmware features, so I’m not having to rewrite the manual it once they’re released. The new firmware will display system states as plain text, allowing warnings, critical states, or errors to show up clearly for easier diagnosis. Again, we aim to keep things simple and avoid overwhelming the user with information they don’t understand.
For now, if you want to test the full capacity of your battery pack and push it to its limits without exceeding safety parameters, you can monitor the lowest cell voltage displayed in the top-left corner of your hand controller’s screen. Ensure the voltage does not drop below 2.8V, as the BMS will then shut off the output to prevent excessive cell damage. At that point, the SOC percentage will read zero for quite some time, indicating you’ve gone beyond what is normally recommended. With the new system, you can keep flying past zero percent, as an extra buffer is built in.
Regarding the SOC calculation, we use a hybrid approach involving measuring the current entering and leaving the battery over time (Coulomb counting). This method continuously tracks current to estimate the remaining battery capacity. However, Coulomb counting alone may accumulate errors due to sensor inaccuracies or battery self-discharge. To mitigate these inaccuracies, the battery’s measured voltage is periodically compared against known reference voltages corresponding to specific SOC values. These voltage references periodically recalibrate the Coulomb counting calculation. Occasionally, adjustments will be made based on voltage lookup tables. These tables can be adjusted or disabled, as they’re susceptible to voltage sag, but using them is currently the most accurate way to achieve consistent and reliable SOC calculations.
Here, you can also see some of the temperature and voltage thresholds in the BMS. These will appear on the controller screen when certain values are reached, making sure the pilot has plenty of advance warning about anything that could affect flight performance. We prefer to remain conservative with these limits, but we can push them further if desired. We have people flying over water or other locations, where encountering issues could be not fun, so we are extra conservative by default.
All technical details like these would be excessive for the user manual. As most people don’t know what this information means, and they shouldn’t have to learn it. The manual should be simplified and should not contain extensive technical information. Maybe we will make a technical manual for the technical people but it does take a lot of effort to document everything is decent detail there is just so much stuff it would be hundreds of pages if not more. So for now, we will just have a simple manual coming.