http://www.olliw.eu/storm32bgc-v2-wiki/api.php?action=feedcontributions&feedformat=atom&user=OlliWSTorM32-BGC Wiki - User contributions [en]2026-04-28T21:21:41ZUser contributionsMediaWiki 1.43.3http://www.olliw.eu/storm32bgc-v2-wiki/index.php?title=Where_to_buy_STorM32_components&diff=11922Where to buy STorM32 components2026-03-26T07:50:44Z<p>OlliW: </p>
<hr />
<div>__NOTOC__<br />
''This list of vendors is collected solely for your convenience! It is '''NOT''' an official seller list, nor implies any recommendation. The list may not be complete, the order of the listings is arbitrary, and vendors not mentioned are equally trustworthy.''<br />
<!--<br />
== Plug & Play STorM32 Gimbals ==<br />
<br />
[https://www.gohstanddesigns.com/ Gohstand Designs] used to sell 3-axis and 2-axis gimbals. They seem to be currently under revision. These gimbals use proprietary electronics, but are compatible with v3.3 firmware.<br />
<br />
* 3 Axis Gimbal: [https://www.gohstanddesigns.com/products/p/namaste-3axis-gimbal link]<br />
* 2 Axis Gimbal: [https://www.gohstanddesigns.com/products/p/namaste-2axis-gimbal link]--><br />
<br />
== v4.1 STorM32 Board == <br />
<br />
The v4.1 STorM32 board has been designed by Krattworks, and they make it available for purchase upon direct contact. It is fully compatible with the official firmware.<br />
<br />
Write to sales@krattworks.com, they will respond and send you as many boards as you need.<br />
<br />
(see https://www.rcgroups.com/forums/showpost.php?p=52740843&postcount=15419)<br />
<br />
== v4.1 STorM32 Board, NT Modules ==<br />
<br />
link: https://www.gordiansystems.nl/<br />
<br />
== ENSYS NT Modules == <br />
<br />
ENSYS provides a selection of proprietary NT modules, including NT IMU modules and NT Motor modules. Their offers and the product availability vary, so one needs to check their web page to know what is available. The ENSYS NT modules are mostly based on propietary designs, and use propietary firmwares.<br />
<br />
link: http://www.ensys.lt/<br />
<br />
== NT IMU based on STM32G4 ==<br />
<br />
Rcgroups user @jpou has designed NT IMU modules based on the v4 design, and put them up for sale. The design is a modified version of the official v4 design, andt is fully compatible with the official firmware.<br />
<br />
link: https://www.rcgroups.com/forums/showpost.php?p=52887733&postcount=15483<br />
<br />
== v1.x Boards ==<br />
<br />
The v1.3 STorM32 boards or STorM32 gimbals using the v1.3 board are still available from Chinese sites such as aliexpress or on ebay. These offers generally use I2C IMUs and are thus not compatible with the latest firmware, but need to run v0.96 firmware.<br />
<br />
* [https://www.ebay.com/sch/i.html?_from=R40&_trksid=p2380057.m570.l1313.TR11.TRC1.A0.H0.Xstorm32.TRS0&_nkw=storm32&_sacat=0 ebay]<br />
* [http://www.aliexpress.com/wholesale?catId=0&initiative_id=SB_20150517161817&isPremium=y&SearchText=storm32 AliExpress]</div>OlliWhttp://www.olliw.eu/storm32bgc-v2-wiki/index.php?title=Yaw&diff=11921Yaw2026-01-23T12:29:09Z<p>OlliW: </p>
<hr />
<div>The yaw angle is a pretty difficult topic for gimbals which are based on 6DOF MEMS inertial sensors (gyroscope, accelerometer). This page aims at providing some understanding of the challenges and how the STorM32 controller handles yaw.<br />
<br />
The fundamental issue with these sensors is that yaw cannot be measured in absolute terms (e.g. with respect to North) and that moreover the yaw angle drifts quite significantly with time (typically several degrees per minute). This is in striking contrast to the pitch and roll angle which using the accelerometers can be determined with respect to the gravitation axis. <br />
<br />
Fundamentally, due to the limitations set by the available sensors, the STorM32 controller has no notion of an absolute yaw, in the sense that yaw could be referenced to a specific direction, like North (aka yaw in earth frame, or absolute yaw) or the gimbal forward orientation (aka yaw in vehicle frame, or relative yaw). Accordingly, it uses what one may call a '''''synthetic yaw reference'''''. The STorM32 controller tries its best to adjust the yaw reference such that the reported yaw angle may make sense to a user, but this very much depends on the operation conditions, and depending on the particular operation condition and the pervious history it is more or less successful in achieving this. However, fundamentally, the yaw reference wanders with time, and along with it does the reported yaw angle.<br />
<br />
For instance, the yaw angle shown in the GUI's DataDisplay can drift substantially, while the camera itself may not move at all. This by itself is not worrysome as it only shows that for the current operation condition the synthetic yaw reference can not be maintained to a constant value but wanders. Unfortunately, the displayed yaw angle may also drift due to a actual malfunction, like an exessively drifting gyro sensor or incorrect IMU orientation, and it is not always easy to distinguish the root cause.<br />
<br />
In order to produce a yaw angle which is aligned with the gimbal forward orientation, the STorM32 tries as best as it can to make use of its knowledge of the gimbal motor positions, but this also depends very much on the operation conditions and in addition on the gimbal construction (no encoders and no 2nd IMU, no encoders with 2nd IMU, with encoders). Obviously, an encodered gimbal provides the best information on the motor positions while a gimbal with no encoders and unpowered motors cannot provide any information.<br />
<br />
The situation improves substantially if STorM32-Link is available. Then the STorM32 controller does know the orientation of the gimbal base in absolute terms, and can adjust its synthetic yaw reference by using the motor positions (as far as these are known, see previous paragraph), such as to achieve a synthetic yaw reference which has a fixed relation to the North direction. However, obviously, the success of this approach depends on the accuracy of the yaw angle provided by STorM32-Link. Providing an accurate yaw angle it thus crucial, but can be difficult to achieve. <br />
<br />
The STorM32 controller provides several means to read out a yaw angle, like serial commands or MAVLink messages, and what is reported as yaw angle depends on the particular method and operation condition. In some cases it reports the yaw angle with reference to its synthetic yaw reference, in other cases it reports its best guestimate for the relative yaw angle, and if the STorM32-Link is available it also can provide absolute yaw angles. <br />
<br />
This can be admittedly confusing to the user, but this page hopefully helps at least insofar as to better understand why it is that confusing.</div>OlliWhttp://www.olliw.eu/storm32bgc-v2-wiki/index.php?title=Yaw&diff=11920Yaw2026-01-23T12:22:19Z<p>OlliW: </p>
<hr />
<div>The yaw angle is a pretty difficult topic for gimbals which are based on 6DOF MEMS inertial sensors (gyroscope, accelerometer). This page aims at providing some understanding of the challenges and how the STorM32 controller handles yaw.<br />
<br />
The fundamental issue with such a gimbal setup is that yaw cannot be measured in absolute terms (e.g. with respect to North) and that moreover the yaw angle drifts quite significantly with time (typically several degrees per minute). This is in striking contrast to the pitch and roll angle which using the accelerometers can be determined with respect to the gravitation axis. <br />
<br />
Fundamentally, due to the limitations set by the available sensors, the STorM32 controller has no notion of an absolute yaw, in the sense that yaw could be referenced to a specific direction, like North (aka yaw in earth frame, or absolute yaw) or the gimbal forward orientation (aka yaw in vehicle frame, or relative yaw). Accordingly, it uses what one may call a '''''synthetic yaw reference'''''. The STorM32 controller tries its best to adjust the yaw reference such that the reported yaw angle may make sense to a user, but this very much depends on the operation conditions, and depending on the particular operation condition and the pervious history it is more or less successful in achieving this. However, fundamentally, the yaw reference wanders with time, and along with it does the reported yaw angle.<br />
<br />
For instance, the yaw angle shown in the GUI's DataDisplay can drift substantially, while the camera itself may not move at all. This by itself is not worrysome as it only shows that for the current operation condition the synthetic yaw reference can not be maintained to a constant value but wanders. Unfortunately, the displayed yaw angle may also drift due to a malfunction, like an exessively drifting gyro sensor or incorrect IMU orientation, and it is not always easy to distinguish the root cause.<br />
<br />
In order to produce a yaw angle which is aligned with the gimbal forward orientation, the STorM32 tries as best as it can to make use of its knowledge of the gimbal motor positions, but this also depends very much on the operation conditions and in addition on the gimbal construction (no encoders and no 2nd IMU, no encoders with 2nd IMU, with encoders). Obviously, an encodered gimbal provides the best information on the motor positions while a gimbal with no encoders and unpowered motors cannot provide any information.<br />
<br />
The situation improves substantially if the STorM32-Link is available. Then the STorM32 controller does know the orientation of the gimbal base in absolute terms, and can adjust its synthetic yaw reference by using the motor positions (as far as these are known, see previous paragraph), such as to achieve a synthetic yaw reference which has a fixed relation to the North direction. However, obviously, if this works well or not depends on how accurate the yaw angle is, which is provided by the STorM32-Link. So, it is important to provide an accurate yaw angle, which can be difficult to achieve. <br />
<br />
The STorM32 controller provides several means to read out a yaw angle, like serial commands or MAVLink messages, and what is reported as yaw angle depends on the particular method and operation condition. In some cases it reports the yaw angle with reference to its synthetic yaw reference, in other cases it reports its best guestimate for the relative yaw angle, and if the STorM32-Link is available it also can provide absolute yaw angles. <br />
<br />
This can be admittedly confusing to the user, but this page hopefully helps at least insofar as to better understand why it is that confusing.</div>OlliWhttp://www.olliw.eu/storm32bgc-v2-wiki/index.php?title=Yaw&diff=11919Yaw2026-01-23T12:21:42Z<p>OlliW: </p>
<hr />
<div>The yaw angle is a pretty difficult topic for gimbals which are based on 6DOF MEMS inertial sensors (gyroscope, accelerometer). This page aims at providing at least some insight into the implications and how the STorM32 controller handles yaw.<br />
<br />
The fundamental issue with such a gimbal setup is that yaw cannot be measured in absolute terms (e.g. with respect to North) and that moreover the yaw angle drifts quite significantly with time (typically several degrees per minute). This is in striking contrast to the pitch and roll angle which using the accelerometers can be determined with respect to the gravitation axis. <br />
<br />
Fundamentally, due to the limitations set by the available sensors, the STorM32 controller has no notion of an absolute yaw, in the sense that yaw could be referenced to a specific direction, like North (aka yaw in earth frame, or absolute yaw) or the gimbal forward orientation (aka yaw in vehicle frame, or relative yaw). Accordingly, it uses what one may call a '''''synthetic yaw reference'''''. The STorM32 controller tries its best to adjust the yaw reference such that the reported yaw angle may make sense to a user, but this very much depends on the operation conditions, and depending on the particular operation condition and the pervious history it is more or less successful in achieving this. However, fundamentally, the yaw reference wanders with time, and along with it does the reported yaw angle.<br />
<br />
For instance, the yaw angle shown in the GUI's DataDisplay can drift substantially, while the camera itself may not move at all. This by itself is not worrysome as it only shows that for the current operation condition the synthetic yaw reference can not be maintained to a constant value but wanders. Unfortunately, the displayed yaw angle may also drift due to a malfunction, like an exessively drifting gyro sensor or incorrect IMU orientation, and it is not always easy to distinguish the root cause.<br />
<br />
In order to produce a yaw angle which is aligned with the gimbal forward orientation, the STorM32 tries as best as it can to make use of its knowledge of the gimbal motor positions, but this also depends very much on the operation conditions and in addition on the gimbal construction (no encoders and no 2nd IMU, no encoders with 2nd IMU, with encoders). Obviously, an encodered gimbal provides the best information on the motor positions while a gimbal with no encoders and unpowered motors cannot provide any information.<br />
<br />
The situation improves substantially if the STorM32-Link is available. Then the STorM32 controller does know the orientation of the gimbal base in absolute terms, and can adjust its synthetic yaw reference by using the motor positions (as far as these are known, see previous paragraph), such as to achieve a synthetic yaw reference which has a fixed relation to the North direction. However, obviously, if this works well or not depends on how accurate the yaw angle is, which is provided by the STorM32-Link. So, it is important to provide an accurate yaw angle, which can be difficult to achieve. <br />
<br />
The STorM32 controller provides several means to read out a yaw angle, like serial commands or MAVLink messages, and what is reported as yaw angle depends on the particular method and operation condition. In some cases it reports the yaw angle with reference to its synthetic yaw reference, in other cases it reports its best guestimate for the relative yaw angle, and if the STorM32-Link is available it also can provide absolute yaw angles. <br />
<br />
This can be admittedly confusing to the user, but this page hopefully helps at least insofar as to better understand why it is that confusing.</div>OlliWhttp://www.olliw.eu/storm32bgc-v2-wiki/index.php?title=STorM32_Parameters&diff=11918STorM32 Parameters2025-11-30T10:48:32Z<p>OlliW: /* Expert Tool Window */</p>
<hr />
<div><span style="font-size:88%">''The information on this page refers to firmware v2.72e.''</span><br />
<br />
List of all STorM32 parameters, and some GUI features, with brief explanations and/or links to more comprehensive articles.<br />
<br />
{{COMMENT|The parameters are displayed and enabled in the GUI depending on whether the STorM32 gimbal is in "'''Conventional Mode'''" or "'''T-STorM32 Mode'''". The active mode can be inferred from the GUI's title, and is updated to the correct current mode upon a connection to a STorM32 controller.}}<br />
<br />
<div class="toclimit-2">__TOC__</div><br />
<br />
== Dashboard Tab ==<br />
<br />
{{GUIFIELD|Change Name}}:<br><br />
Opens a dialog, which allows you to change the name of the board.<br />
<br />
{{GUIFIELD|Share Settings}}:<br><br />
Opens a dialog, which presents all parameters comprehensively. Taking a screen shot by pressing one of the "Save Screenshot" buttons provides a useful method for sharing parameter settings.<br />
<br />
{{GUIFIELD|Check for Updates}}:<br><br />
Opens a dialog, which connects to the STorM32 github repository to check if a new firmware is available.<br />
<br />
== PID Tab ==<br />
<br />
=== In Conventional Mode: ===<br />
<br />
{{PARAMNAMEDEF|Gyro LPF}}: <br> Digital low pass filter applied to the raw gyro data. Can help to avoid vibrations and/or reach higher PID values. Values relate to the time constant of the filter.<br />
<br />
{{PARAMNAMEDEF|Imu2 FeedForward LPF}}: <br> Digital low pass filter applied to the attitude data of the 2nd IMU before it enters the feedforward channel in the PID controller. Effective only when the 2nd IMU is enabled, i.e., when {{PARAMNAME|Imu2 Configuration}} is not {{PARAMVALUE|off}}. Values relate to the time constant of the filter.<br />
<br />
{{PARAMNAMEDEF|Pitch P}}, {{PARAMNAMEDEF|Roll P}}, {{PARAMNAMEDEF|Yaw P}}: <br> Proportional term of the PID controller for the pitch, roll or yaw axis, respectively. See also [[Tuning_Recipe#Tuning_Procedure|Tuning Recipe: Tuning Procedure]].<br />
<br />
{{PARAMNAMEDEF|Pitch I}}, {{PARAMNAMEDEF|Roll I}}, {{PARAMNAMEDEF|Yaw I}}: <br> Integral term of the PID controller for the pitch, roll or yaw axis, respectively. See also [[Tuning_Recipe#Tuning_Procedure|Tuning Recipe: Tuning Procedure]].<br />
<br />
{{PARAMNAMEDEF|Pitch D}}, {{PARAMNAMEDEF|Roll D}}, {{PARAMNAMEDEF|Yaw D}}: <br> Derivative term of the PID controller for the pitch, roll or yaw axis, respectively. See also [[Tuning_Recipe#Tuning_Procedure|Tuning Recipe: Tuning Procedure]].<br />
<br />
{{PARAMNAMEDEF|Pitch Motor Vmax}}, {{PARAMNAMEDEF|Roll Motor Vmax}}, {{PARAMNAMEDEF|Yaw Motor Vmax}}: <br> Maximal average voltage for the pitch, roll or yaw motor, respectively. Range is 0 - 255. See also [[Tuning_Recipe#Setting_Motor_Vmax|Tuning Recipe: Setting Motor Vmax]].<br />
<br />
{{PARAMNAMEDEF|Voltage Correction}}: <br> Attempts to compensate the effects of a (slowly) varying battery voltage on the PID controller tuning, see [[Advanced_Functions#Voltage_Correction|Advanced Functions: Voltage Correction]].<br />
<br />
{{PARAMNAMEDEF|Controller}}: <br> Enables the model-based controller. The settings {{PARAMVALUE|default}} and {{PARAMVALUE|roll mixing}} are available, where the first corresponds to the "old" behavior, and the second enables improved roll mixing.<br />
<br />
{{GUIFIELD|Use simplified PID tuning}}: <br> Toggles between the standard PID tuning, in which the P, I D values are adjusted, and a simplified mechanism, in which tuning is achieved by only two parameters, called Damping and Stability.<br />
<br />
=== In T-STorM32 Mode: ===<br />
<br />
{{PARAMNAMEDEF|Foc Gyro LPF}}: <br> Digital low pass filter applied to the raw gyro data. Can help to avoid vibrations and/or reach higher PID values. Values relate to the time constant of the filter.<br />
<br />
{{PARAMNAMEDEF|Foc Pitch P}}, {{PARAMNAMEDEF|Foc Roll P}}, {{PARAMNAMEDEF|Foc Yaw P}}: <br> Proportional term of the PID controller for the pitch, roll or yaw axis, respectively.<br />
<br />
{{PARAMNAMEDEF|Foc Pitch I}}, {{PARAMNAMEDEF|Foc Roll I}}, {{PARAMNAMEDEF|Foc Yaw I}}: <br> Integral term of the PID controller for the pitch, roll or yaw axis, respectively.<br />
<br />
{{PARAMNAMEDEF|Foc Pitch D}}, {{PARAMNAMEDEF|Foc Roll D}}, {{PARAMNAMEDEF|Foc Yaw D}}: <br> Derivative term of the PID controller for the pitch, roll or yaw axis, respectively.<br />
<br />
{{PARAMNAMEDEF|Foc Pitch K}}, {{PARAMNAMEDEF|Foc Roll K}}, {{PARAMNAMEDEF|Foc Yaw K}}: <br> Factor which multiplies the P, I, and D values.<br />
<br />
{{PARAMNAMEDEF|Foc Controller}}: <br> Enables the model-based controller. The setting {{PARAMVALUE|default}} corresponds to the "old" behavior.<br />
<br />
=== All Modes: ===<br />
<br />
{{PARAMNAMEDEF|D Source}}: <br> The settings “default” and “gyro” are available. "gyro" enables the "new" lag-free and lower-noise controller D-term calculation. This setting is enabled per default. "default" enables the "old" method of D-term calculation. This parameter may be removed in upcoming firmwares.<br />
<br />
{{GUIFIELD|Auto write PID changes}}:<br><br />
When checked, any change to the PID values (and only to the PID values) is written to the STorM32 board after ca. 1 sec.<br />
<br />
== Pan Tab ==<br />
<br />
The parameters in the {{GUI|Pan}} tab are comprehensively described in the article [[Hold_versus_Pan_Mode|Hold versus pan Mode]].<br />
<br />
{{PARAMNAMEDEF|Pan Mode Control}}: <br> Selects the input channel used for changing the pan mode. <br />
<br />
{{PARAMNAMEDEF|Pan Mode Default Setting}}, {{PARAMNAMEDEF|Pan Mode Setting #1}}, {{PARAMNAMEDEF|Pan Mode Setting #2}}, {{PARAMNAMEDEF|Pan Mode Setting #3}}: <br><br />
Selects the pan states for each axis, for each of the four possible states of the input channel.<br />
<br />
{{PARAMNAMEDEF|Pitch Pan}}, {{PARAMNAMEDEF|Roll Pan}}, {{PARAMNAMEDEF|Yaw Pan}}: <br><br />
Sets the pan speed for pitch, roll and yaw, respectively.<br />
<br />
{{PARAMNAMEDEF|Pitch Pan Deadband}}, {{PARAMNAMEDEF|Roll Pan Deadband}}, {{PARAMNAMEDEF|Yaw Pan Deadband}}:<br><br />
Sets the pan deadband for pitch, roll and yaw, respectively.<br />
<br />
{{PARAMNAMEDEF|Pitch Pan Expo}}, {{PARAMNAMEDEF|Roll Pan Expo}}, {{PARAMNAMEDEF|Yaw Pan Expo}}: <br><br />
Sets the pan expo for pitch, roll and yaw, respectively.<br />
<br />
{{PARAMNAMEDEF|Pitch Pan Method}}, {{PARAMNAMEDEF|Roll Pan Method}}: <br><br />
Sets the pan method for pitch and roll, respectively. Can be "normal" or "plane". <br />
<br />
{{PARAMNAMEDEF|Yaw Pan Deadband LPF}}: <br><br />
Sets the pan deadband low-pass filter for the yaw axis.<br />
<br />
== Rc Inputs Tab ==<br />
<br />
The parameters in the {{GUI|Rc Inputs}} tab are comprehensively described in the article [[Configure_the_RC_Input|Configure the RC Input]].<br />
<br />
{{PARAMNAMEDEF|Rc Dead Band}}: <br> Sets a deadband around zero input, to suppress noise on the input. Effective for all three axes.<br />
<br />
{{PARAMNAMEDEF|Rc Hysteresis}}: <br> Sets a hysteresis to value changes, to suppress noise on the input. Effective for all three axes.<br />
<br />
{{PARAMNAMEDEF|Rc Pitch Trim}}, {{PARAMNAMEDEF|Rc Roll Trim}}, {{PARAMNAMEDEF|Rc Yaw Trim}}: <br> Sets the mid position for teh pitch, roll and yaw axis, respectively. <br />
<br />
{{PARAMNAMEDEF|Rc Pitch}}, {{PARAMNAMEDEF|Rc Roll}}, {{PARAMNAMEDEF|Rc Yaw}}: <br> Selects the input channel used for controlling the pitch, roll, and yaw axis, respectively.<br />
<br />
{{PARAMNAMEDEF|Rc Pitch Mode}}, {{PARAMNAMEDEF|Rc Roll Mode}}, {{PARAMNAMEDEF|Rc Yaw Mode}}: <br> Sets the mode for the pitch, roll, and yaw axis, respectively.<br />
<br />
{{PARAMNAMEDEF|Rc Pitch Min}}, {{PARAMNAMEDEF|Rc Roll Min}}, {{PARAMNAMEDEF|Rc Yaw Min}}: <br> Sets the minimum angle for the pitch, roll, and yaw axis, respectively.<br />
<br />
{{PARAMNAMEDEF|Rc Pitch Max}}, {{PARAMNAMEDEF|Rc Roll Max}}, {{PARAMNAMEDEF|Rc Yaw Max}}: <br> Sets the maximum angle for the pitch, roll, and yaw axis, respectively.<br />
<br />
{{PARAMNAMEDEF|Rc Pitch Speed Limit}}, {{PARAMNAMEDEF|Rc Roll Speed Limit}}, {{PARAMNAMEDEF|Rc Yaw Speed Limit}}: <br> Sets the maximum speed for the pitch, roll, and yaw axis, respectively. A value of 0 disables the speed limiter (it is not fully deactivated, the speed limit is set to 100 deg/s).<br />
<br />
{{PARAMNAMEDEF|Rc Pitch Accel Limit}}, {{PARAMNAMEDEF|Rc Roll Accel Limit}}, {{PARAMNAMEDEF|Rc Yaw Accel Limit}}: <br> Sets the maximum acceleration for the pitch, roll, and yaw axis, respectively. A value of 0 disables the acceleration limiter (it is not fully deactivated, a small limit remains).<br />
<br />
{{PARAMNAMEDEF|Rc Pitch Expo}}, {{PARAMNAMEDEF|Rc Roll Expo}}, {{PARAMNAMEDEF|Rc Yaw Expo}}: <br> Sets the expo for the pitch, roll, and yaw axis, respectively.<br />
<br />
{{GUIFIELD|Auto Trim}}:<br> Reads the current input values and adjusts the trim values such as to make them zero.<br />
<br />
== Functions Tab ==<br />
<br />
{{PARAMNAMEDEF|Re-center Camera}}, {{PARAMNAMEDEF|Re-center Camera Axes}}, {{PARAMNAMEDEF|Re-center Camera Mode}}: <br> See [[Advanced_Functions#Re-center_Camera|Advanced Functions: Re-center Camera]].<br />
<br />
{{PARAMNAMEDEF|Retract}}: <br> Puts the gimbal in retract mode.<br />
<br />
{{PARAMNAMEDEF|Standby}}: <br> See [[Advanced_Functions#Standby|Advanced Functions: Standby]].<br />
<br />
{{PARAMNAMEDEF|Camera Control}}, {{PARAMNAMEDEF|Camera Control2}}, {{PARAMNAMEDEF|Camera Model}}, {{PARAMNAMEDEF|Camera Control Mode}}, {{PARAMNAMEDEF|Time Interval}}, {{PARAMNAMEDEF|Camera ComPort}}: <br> See [[Advanced_Functions#Camera_Remote_Control|Advanced Functions: Camera Remote Control]].<br />
<br />
{{PARAMNAMEDEF|Pwm Out Control}}, {{PARAMNAMEDEF|Pwm Out Mid}}, {{PARAMNAMEDEF|Pwm Out Min}}, {{PARAMNAMEDEF|Pwm Out Max}}, {{PARAMNAMEDEF|Pwm Out Speed Limit}}: <br> See [[Advanced_Functions#Pwm_Out|Advanced Functions: Pwm Out]].<br />
<br />
== Scripts Tab ==<br />
<br />
The parameters in the {{GUI|Scripts}} tab are comprehensively described in the article [[STorM32_Scripts|STorM32 Scripts]].<br />
<br />
== Setup Tab ==<br />
<br />
=== In Conventional Mode: ===<br />
<br />
{{PARAMNAMEDEF|Imu2 Configuration}}: <br><br />
Selects how a 2nd IMU is used. See also [[Using a 2nd IMU]].<br />
<br />
{{PARAMNAMEDEF|Startup Mode}}: <br><br />
Selects the startup algorithm. Can be set to {{PARAMVALUE|fast}} for invoking fast startup. For fast startup to be activated, additional conditions have to be met: IMU2 must be present, the motor directions and positions must have been configured, and IMU1 and IMU2 must have be calibrated. The gimbal should also have been tuned.<br />
<br />
=== All Modes: ===<br />
<br />
{{PARAMNAMEDEF|Startup Delay}}: <br><br />
Sets a startup delay time.<br />
<br />
{{PARAMNAMEDEF|Prearm Checks}}: <br><br />
Bitmask to enable various pre-arming checks, i.e., conditions which need to be fulfilled before the STroM32 goes into NORMAL mode. <br />
<br />
{{PARAMNAMEDEF|Virtual Channel Configuration}}: <br><br />
Selects the physical source for the {{PARAMVALUE|Virtual-1}}, ..., {{PARAMVALUE|Virtual-16}} input values. See [[Inputs and Functions]] for understanding the STorM32's concept of inputs, and [[Configure_the_RC_Input#Wiring_for_SUM-PPM_Signals|Configure the RC Input: Wiring for SUM-PPM Signals]] and [[Configure_the_RC_Input#Wiring_for_Digital_Signals|Configure the RC Input: Wiring for Digital Signals]] for typical use cases.<br />
<br />
{{PARAMNAMEDEF|Pwm Out Configuration}}: <br><br />
Enables the pwm out function, see [[Advanced_Functions#Pwm_Out|Advanced Functions: Pwm Out]].<br />
<br />
{{PARAMNAMEDEF|Rc Pitch Offset}}, {{PARAMNAMEDEF|Rc Roll Offset}}, {{PARAMNAMEDEF|Rc Yaw Offset}}: <br><br />
Adds a permanent offset to the camera orientation. <br />
<br />
{{PARAMNAMEDEF|UartX Configuration}}: <br> <br />
Reconfigures the RC-0, RC-1 pins to work as UART, depending on the setting. Allows to enable the OLed display support on pin RC-1 (see [[Advanced_Functions#OLED_Display|Advanced Functions: OLED Display]]) or enables the UartX serial for the [[NT_Camera|NT Camera]].<br />
<br />
{{PARAMNAMEDEF|Low Voltage Limit}}: <br> Voltage level at which the lipo-saver function is triggered, see [[Advanced_Functions#Lipo_Saver|Advanced Functions: Lipo Saver]]. <br />
<br />
{{PARAMNAMEDEF|Beep with Motors}}: <br><br />
Enables the emission of beeps by the motors, see [[Advanced_Functions#Beeps|Advanced Functions: Beeps]].<br />
<br />
{{PARAMNAMEDEF|NT Logging}}:<br><br />
Adjusts which parameters are logged, see [[NT_Data_Logging#GUI_Settings|NT Data Logging: GUI Settings]].<br />
<br />
{{PARAMNAMEDEF|Pitch Motor Usage}}, {{PARAMNAMEDEF|Roll Motor Usage}}, {{PARAMNAMEDEF|Yaw Motor Usage}}: <br><br />
Selects the operation mode of the pitch, roll, or yaw motor, respectively. When {{PARAMVALUE|disabled}} is selected, the motor does not receive any power.<br />
<br />
== Gimbal Configuration Tab ==<br />
<br />
=== In Conventional Mode: ===<br />
<br />
{{PARAMNAMEDEF|Pitch Motor Poles}}, {{PARAMNAMEDEF|Roll Motor Poles}}, {{PARAMNAMEDEF|Yaw Motor Poles}}:<br><br />
Number of magnet poles of the pitch, roll or yaw motor, respectively. Range is 8 - 42.<br />
<br />
{{PARAMNAMEDEF|Pitch Motor Direction}}, {{PARAMNAMEDEF|Roll Motor Direction}}, {{PARAMNAMEDEF|Yaw Motor Direction}}:<br><br />
Rotation direction of the pitch, roll or yaw motor, respectively. <br />
<br />
{{PARAMNAMEDEF|Pitch Startup Motor Pos}}, {{PARAMNAMEDEF|Roll Startup Motor Pos}}, {{PARAMNAMEDEF|Yaw Startup Motor Pos}}:<br><br />
Orientation of the pitch, roll or yaw motor at power up, respectively.<br />
<br />
=== In T-STorM32 Mode: ===<br />
<br />
{{PARAMNAMEDEF|Foc Pitch Motor Direction}}, {{PARAMNAMEDEF|Foc Roll Motor Direction}}, {{PARAMNAMEDEF|Foc Yaw Motor Direction}}:<br><br />
Rotation direction of the pitch, roll or yaw motor, respectively. <br />
<br />
{{PARAMNAMEDEF|Foc Pitch Zero Pos}}, {{PARAMNAMEDEF|Foc Roll Zero Pos}}, {{PARAMNAMEDEF|Foc Yaw Zero Pos}}:<br><br />
Motor position at zero Imu angle for the pitch, roll or yaw axis, respectively.<br />
<br />
=== All Modes: ===<br />
<br />
{{PARAMNAMEDEF|Imu Orientation}}, {{PARAMNAMEDEF|Imu2 Orientation}}:<br><br />
Orientation number of the IMU1 or IMU2, respectively. <br />
<br />
{{PARAMNAMEDEF|Pitch Offset}}, {{PARAMNAMEDEF|Roll Offset}}, {{PARAMNAMEDEF|Yaw Offset}}:<br><br />
Coefficients to correct for slight inaccuracies in the calibration of the IMU1 accelerometer.<br />
<br />
== Interfaces Tool Window ==<br />
<br />
{{PARAMNAMEDEF|Mavlink Gimbal}}, {{PARAMNAMEDEF|Mavlink Gimbal Stream}}, {{PARAMNAMEDEF|Mavlink ComPort}}, {{PARAMNAMEDEF|Mavlink System ID}}, {{PARAMNAMEDEF|Mavlink Camera}}:<br><br />
Parameters for handling Mavlink messages, see [[MAVLink Communication]].<br />
<br />
{{PARAMNAMEDEF|STorM32Link Configuration}}<!--, {{PARAMNAMEDEF|STorM32Link AHRS Factor}}-->:<br><br />
Parameters for handling the [[STorM32-Link|STorM32 Link]]. The setting {{PARAMNAMEDEF|STorM32Link Configuration}} = {{PARAMVALUE|yaw drift comp.}} enables the yaw drift compensation, but not horizon drift compensation. The setting {{PARAMNAMEDEF|STorM32Link Configuration}} = {{PARAMVALUE|v1}} enables both the yaw drift compensation and horizon drift compensation. For further info on the STorM32-Link see the article [[STorM32-Link]].<br />
<br />
{{PARAMNAMEDEF|Uart Baudrate}}, {{PARAMNAMEDEF|Uart2 Baudrate}}, {{PARAMNAMEDEF|Usb Baudrate}}:<br><br />
Baudrates used for the UART, USB, and UART2 ports. The default baudrates are 115200 bps.<br />
<br />
== Expert Tool Window ==<br />
<br />
=== In Conventional Mode: ===<br />
<br />
{{PARAMNAMEDEF|Motor Mapping}}:<br><br />
Allows us to change the assignment of the pitch, roll and yaw motors to the ports MOT0, MOT1, MOT2. The default assignment is pitch = MOT0, roll = MOT1, yaw = MOT2.<br />
<br />
{{PARAMNAMEDEF|Imu2 Rotation}}: <br><br />
Allows us to configure for different mounting options of the 2nd IMU. See also [[Using a 2nd IMU]].<br />
<br />
{{PARAMNAMEDEF|Flip Gimbal Control}}: <br><br />
Allows us to use an input signal to switch the configuration of the gimbal between "down-hanging" and "up-standing".<br />
<br />
=== All Modes: ===<br />
<br />
{{PARAMNAMEDEF|Imu Mapping}}: <br><br />
Allows us to swap IMU1 and IMU2 (this swaps NT IMU1 and NT IMU2, not the on-board IMU, which always will be IMU2 if used) .<br />
<br />
{{PARAMNAMEDEF|Lipo Cells}}: <br><br />
Sets the number of cells of the battery. Default is {{PARAMVALUE|auto}}, which determines the number of cells from the battery voltage at power up.<br />
<br />
{{PARAMNAMEDEF|Lipo Voltage per Cell}}: <br><br />
Full charge voltage of a battery cell. Default is 4.20 V, appropriate for a LIPO.<br />
<br />
{{PARAMNAMEDEF|ADC Calibration}}: <br><br />
Calibration constant for voltage measurement. The default value {{PARAMVALUE|1550}} is slightly below the theoretically correct value of 1581.<br />
<br />
{{PARAMNAMEDEF|Imu AHRS}}: <br><br />
Adjusts how strongly the accelerometer data are included in the data fusing for the attitude estimation. The shorter the time the stronger the accelerometer data are weighted (0 = accelerometer only, 20 = gyro only).<br />
<br />
{{PARAMNAMEDEF|Startup Gyro Calibration}}: <br><br />
Sets the gyro calibration at startup. Default is {{PARAMVALUE|normal}}.<br />
<br />
==== The following parameters should be set with care. Normally, there should be no reason to modify them. ====<br />
<br />
{{PARAMNAMEDEF|Acc LPF}}: <br> <br />
Digital low pass filter applied to the raw accelerometer data. It also affects the behavior of the AHRS.<br />
<br />
{{PARAMNAMEDEF|Rc Adc LPF}}: <br> <br />
Digital low pass filter applied to the Rc Input values. Might be helpful for very noisy RC transmitters.<br />
<br />
{{PARAMNAMEDEF|Pan Hold Transition Time}}, {{PARAMNAMEDEF|Pan Speed Limit}}, {{PARAMNAMEDEF|Pan Accel Limit}}: <br><br />
These parameters are related to the pan-to-hold and hold-to-pan transition behavior. The parameter {{PARAMNAMEDEF|Pan Hold Transition Time}} determines for how long a trajectory filter is applied to smooth the transition. The two limit parameters determine the speed and acceleration limits of the trajectory filter.<br />
<br />
{{PARAMNAMEDEF|Foc Emergency}}: <br> <br />
Sets the level of the emergency detection mechanism.<br />
<br />
{{PARAMNAMEDEF|Acc Compensation Method}}:<br><br />
Selects the algorithm which is used for fusing the accelerometer and gyro data. Can be {{PARAMVALUE|standard}} or {{PARAMVALUE|advanced}}. The parameter affects the AHRS, and should be set with understanding. These posts might be useful: [http://www.rcgroups.com/forums/showthread.php?t=2055844&page=27&pp=50#post29173129], [http://www.rcgroups.com/forums/showthread.php?t=2055844&page=27&pp=50#post29176384], [http://www.rcgroups.com/forums/showthread.php?t=2055844&page=27&pp=50#post29176832].<br />
<br />
== Filter Tool Window ==<br />
<br />
The parameters in the {{GUI|Filter}} tab allow to set notch/band-pass filters.<br />
<br />
* {{PARAMNAME|Filter1 Source}}, {{PARAMNAME|Filter2 Source}}, {{PARAMNAME|Filter3 Source}}: Selects the filter source. <br />
* {{PARAMNAME|Filter1 Center Frequency}}, {{PARAMNAME|Filter2 Center Frequency}}, {{PARAMNAME|Filter3 Center Frequency}}: Selects the center or cut-off frequency of the filter.<br />
* {{PARAMNAME|Filter1 Bandwidth}}, {{PARAMNAME|Filter2 Bandwidth}}, {{PARAMNAME|Filter3 Bandwidth}}: Selects the bandwidth for notch or band-cut filters.<br />
* {{PARAMNAME|Filter1 Attenuation}}, {{PARAMNAME|Filter2 Attenuation}}, {{PARAMNAME|Filter3 Attenuation}}: Selects the attenuation of the band-cut filters. {{PARAMVALUE|inf}} results in a notch filter.<br />
<br />
== Gimbal Mechanics Tool Window ==<br />
<br />
The parameters in the {{GUI|Gimbal Mechanics}} tab allow to set mechanical gimbal limits. They are experimental.<br />
<br />
=== All Modes: ===<br />
<br />
{{PARAMNAMEDEF|Yaw Motor Limit}}:<br> Limit for yaw axis.<br />
<br />
{{PARAMNAMEDEF|Setpoint Speed Limit}}, {{PARAMNAMEDEF|Setpoint Accel Limit}}:<br> Speed and acceleration limits for changes of the setpoint.<br />
<br />
=== In T-STorM32 Mode: ===<br />
<br />
{{PARAMNAMEDEF|Pitch Motor Limit Min}}, {{PARAMNAMEDEF|Pitch Motor Limit Max}}, {{PARAMNAMEDEF|Roll Motor Limit}}:<br> Limits for pitch and roll axes.<br />
<br />
== Gimbal Model Tool Window ==<br />
<br />
The parameters in the {{GUI|Gimbal Model}} tab are comprehensively described in the article [[Model-based_Control|Model-based Control]].<br />
<br />
=== In T-STorM32 Mode: ===<br />
<br />
{{PARAMNAMEDEF|T1 Pitch}}, {{PARAMNAMEDEF|T1 Roll}}, {{PARAMNAMEDEF|T1 Yaw}}:<br><br />
Relative moments of inertia of the camera along the pitch, roll and yaw directions.<br />
<br />
{{PARAMNAMEDEF|T2 Roll}}, {{PARAMNAMEDEF|T2 Yaw}}:<br><br />
Relative moments of inertia of the roll arm along the roll and yaw directions.<br />
<br />
== Servo Tool Window ==<br />
<br />
=== In T-STorM32 Mode: ===<br />
<br />
{{PARAMNAMEDEF|Servo Pitch P}}, {{PARAMNAMEDEF|Servo Pitch I}}, {{PARAMNAMEDEF|Servo Pitch D}}, {{PARAMNAMEDEF|Servo Pitch DLPF}}:<br><br />
Parameters for the position PID controller in servo mode for the pitch axis.<br />
<br />
{{PARAMNAMEDEF|Servo Roll P}}, {{PARAMNAMEDEF|Servo Roll I}}, {{PARAMNAMEDEF|Servo Roll D}}, {{PARAMNAMEDEF|Servo Roll DLPF}}:<br><br />
Parameters for the position PID controller in servo mode for the roll axis.<br />
<br />
{{PARAMNAMEDEF|Servo Yaw P}}, {{PARAMNAMEDEF|Servo Yaw I}}, {{PARAMNAMEDEF|Servo Yaw D}}, {{PARAMNAMEDEF|Servo Yaw DLPF}}:<br><br />
Parameters for the position PID controller in servo mode for the yaw axis.<br />
<!--<br />
{{PARAMNAMEDEF|Imu Acc Threshold}}:<br><br />
Maximal residual acceleration up to which the accelerometer data are taken into account in the attitude estimation. This parameter is effective only when {{PARAMNAME|Acc Compensation Method}} is set to {{PARAMVALUE|standard}}.<br />
<br />
{{PARAMNAMEDEF|Acc Noise Level}}:<br><br />
Residual acceleration up to which the accelerometer data are taken into account with maximal weight in the attitude estimation. Effective only when {{PARAMNAME|Acc Compensation Method}} = {{PARAMVALUE|advanced}}.<br />
<br />
{{PARAMNAMEDEF|Acc Threshold}}:<br><br />
Maximal residual acceleration up to which the accelerometer data are taken into account in the attitude estimation with non-zero weight. Effective only when {{PARAMNAME|Acc Compensation Method}} = {{PARAMVALUE|advanced}}.<br />
<br />
{{PARAMNAMEDEF|Acc Vertical Weight}}:<br><br />
Weight of the vertical residual acceleration in determining the weight of the accelerometer data in the attitude estimation. Effective only when {{PARAMNAME|Acc Compensation Method}} = {{PARAMVALUE|advanced}}.<br />
<br />
{{PARAMNAMEDEF|Acc Zentrifugal Correction}}:<br><br />
Weight of the centrifugal acceleration in determining the weight of the accelerometer data in the attitude estimation. Effective only when {{PARAMNAME|Acc Compensation Method}} = {{PARAMVALUE|advanced}}.<br />
<br />
{{PARAMNAMEDEF|Acc Recover Time}}:<br><br />
Fall time for recovering from a reduced weight of the accelerometer data in the attitude estimation. The rise time is determined implicitly by the {{PARAMNAME|Acc LPF}} parameter value. Effective only when {{PARAMNAME|Acc Compensation Method}} = {{PARAMVALUE|advanced}}.<br />
--></div>OlliWhttp://www.olliw.eu/storm32bgc-v2-wiki/index.php?title=STorM32_Parameters&diff=11917STorM32 Parameters2025-11-30T10:46:35Z<p>OlliW: </p>
<hr />
<div><span style="font-size:88%">''The information on this page refers to firmware v2.72e.''</span><br />
<br />
List of all STorM32 parameters, and some GUI features, with brief explanations and/or links to more comprehensive articles.<br />
<br />
{{COMMENT|The parameters are displayed and enabled in the GUI depending on whether the STorM32 gimbal is in "'''Conventional Mode'''" or "'''T-STorM32 Mode'''". The active mode can be inferred from the GUI's title, and is updated to the correct current mode upon a connection to a STorM32 controller.}}<br />
<br />
<div class="toclimit-2">__TOC__</div><br />
<br />
== Dashboard Tab ==<br />
<br />
{{GUIFIELD|Change Name}}:<br><br />
Opens a dialog, which allows you to change the name of the board.<br />
<br />
{{GUIFIELD|Share Settings}}:<br><br />
Opens a dialog, which presents all parameters comprehensively. Taking a screen shot by pressing one of the "Save Screenshot" buttons provides a useful method for sharing parameter settings.<br />
<br />
{{GUIFIELD|Check for Updates}}:<br><br />
Opens a dialog, which connects to the STorM32 github repository to check if a new firmware is available.<br />
<br />
== PID Tab ==<br />
<br />
=== In Conventional Mode: ===<br />
<br />
{{PARAMNAMEDEF|Gyro LPF}}: <br> Digital low pass filter applied to the raw gyro data. Can help to avoid vibrations and/or reach higher PID values. Values relate to the time constant of the filter.<br />
<br />
{{PARAMNAMEDEF|Imu2 FeedForward LPF}}: <br> Digital low pass filter applied to the attitude data of the 2nd IMU before it enters the feedforward channel in the PID controller. Effective only when the 2nd IMU is enabled, i.e., when {{PARAMNAME|Imu2 Configuration}} is not {{PARAMVALUE|off}}. Values relate to the time constant of the filter.<br />
<br />
{{PARAMNAMEDEF|Pitch P}}, {{PARAMNAMEDEF|Roll P}}, {{PARAMNAMEDEF|Yaw P}}: <br> Proportional term of the PID controller for the pitch, roll or yaw axis, respectively. See also [[Tuning_Recipe#Tuning_Procedure|Tuning Recipe: Tuning Procedure]].<br />
<br />
{{PARAMNAMEDEF|Pitch I}}, {{PARAMNAMEDEF|Roll I}}, {{PARAMNAMEDEF|Yaw I}}: <br> Integral term of the PID controller for the pitch, roll or yaw axis, respectively. See also [[Tuning_Recipe#Tuning_Procedure|Tuning Recipe: Tuning Procedure]].<br />
<br />
{{PARAMNAMEDEF|Pitch D}}, {{PARAMNAMEDEF|Roll D}}, {{PARAMNAMEDEF|Yaw D}}: <br> Derivative term of the PID controller for the pitch, roll or yaw axis, respectively. See also [[Tuning_Recipe#Tuning_Procedure|Tuning Recipe: Tuning Procedure]].<br />
<br />
{{PARAMNAMEDEF|Pitch Motor Vmax}}, {{PARAMNAMEDEF|Roll Motor Vmax}}, {{PARAMNAMEDEF|Yaw Motor Vmax}}: <br> Maximal average voltage for the pitch, roll or yaw motor, respectively. Range is 0 - 255. See also [[Tuning_Recipe#Setting_Motor_Vmax|Tuning Recipe: Setting Motor Vmax]].<br />
<br />
{{PARAMNAMEDEF|Voltage Correction}}: <br> Attempts to compensate the effects of a (slowly) varying battery voltage on the PID controller tuning, see [[Advanced_Functions#Voltage_Correction|Advanced Functions: Voltage Correction]].<br />
<br />
{{PARAMNAMEDEF|Controller}}: <br> Enables the model-based controller. The settings {{PARAMVALUE|default}} and {{PARAMVALUE|roll mixing}} are available, where the first corresponds to the "old" behavior, and the second enables improved roll mixing.<br />
<br />
{{GUIFIELD|Use simplified PID tuning}}: <br> Toggles between the standard PID tuning, in which the P, I D values are adjusted, and a simplified mechanism, in which tuning is achieved by only two parameters, called Damping and Stability.<br />
<br />
=== In T-STorM32 Mode: ===<br />
<br />
{{PARAMNAMEDEF|Foc Gyro LPF}}: <br> Digital low pass filter applied to the raw gyro data. Can help to avoid vibrations and/or reach higher PID values. Values relate to the time constant of the filter.<br />
<br />
{{PARAMNAMEDEF|Foc Pitch P}}, {{PARAMNAMEDEF|Foc Roll P}}, {{PARAMNAMEDEF|Foc Yaw P}}: <br> Proportional term of the PID controller for the pitch, roll or yaw axis, respectively.<br />
<br />
{{PARAMNAMEDEF|Foc Pitch I}}, {{PARAMNAMEDEF|Foc Roll I}}, {{PARAMNAMEDEF|Foc Yaw I}}: <br> Integral term of the PID controller for the pitch, roll or yaw axis, respectively.<br />
<br />
{{PARAMNAMEDEF|Foc Pitch D}}, {{PARAMNAMEDEF|Foc Roll D}}, {{PARAMNAMEDEF|Foc Yaw D}}: <br> Derivative term of the PID controller for the pitch, roll or yaw axis, respectively.<br />
<br />
{{PARAMNAMEDEF|Foc Pitch K}}, {{PARAMNAMEDEF|Foc Roll K}}, {{PARAMNAMEDEF|Foc Yaw K}}: <br> Factor which multiplies the P, I, and D values.<br />
<br />
{{PARAMNAMEDEF|Foc Controller}}: <br> Enables the model-based controller. The setting {{PARAMVALUE|default}} corresponds to the "old" behavior.<br />
<br />
=== All Modes: ===<br />
<br />
{{PARAMNAMEDEF|D Source}}: <br> The settings “default” and “gyro” are available. "gyro" enables the "new" lag-free and lower-noise controller D-term calculation. This setting is enabled per default. "default" enables the "old" method of D-term calculation. This parameter may be removed in upcoming firmwares.<br />
<br />
{{GUIFIELD|Auto write PID changes}}:<br><br />
When checked, any change to the PID values (and only to the PID values) is written to the STorM32 board after ca. 1 sec.<br />
<br />
== Pan Tab ==<br />
<br />
The parameters in the {{GUI|Pan}} tab are comprehensively described in the article [[Hold_versus_Pan_Mode|Hold versus pan Mode]].<br />
<br />
{{PARAMNAMEDEF|Pan Mode Control}}: <br> Selects the input channel used for changing the pan mode. <br />
<br />
{{PARAMNAMEDEF|Pan Mode Default Setting}}, {{PARAMNAMEDEF|Pan Mode Setting #1}}, {{PARAMNAMEDEF|Pan Mode Setting #2}}, {{PARAMNAMEDEF|Pan Mode Setting #3}}: <br><br />
Selects the pan states for each axis, for each of the four possible states of the input channel.<br />
<br />
{{PARAMNAMEDEF|Pitch Pan}}, {{PARAMNAMEDEF|Roll Pan}}, {{PARAMNAMEDEF|Yaw Pan}}: <br><br />
Sets the pan speed for pitch, roll and yaw, respectively.<br />
<br />
{{PARAMNAMEDEF|Pitch Pan Deadband}}, {{PARAMNAMEDEF|Roll Pan Deadband}}, {{PARAMNAMEDEF|Yaw Pan Deadband}}:<br><br />
Sets the pan deadband for pitch, roll and yaw, respectively.<br />
<br />
{{PARAMNAMEDEF|Pitch Pan Expo}}, {{PARAMNAMEDEF|Roll Pan Expo}}, {{PARAMNAMEDEF|Yaw Pan Expo}}: <br><br />
Sets the pan expo for pitch, roll and yaw, respectively.<br />
<br />
{{PARAMNAMEDEF|Pitch Pan Method}}, {{PARAMNAMEDEF|Roll Pan Method}}: <br><br />
Sets the pan method for pitch and roll, respectively. Can be "normal" or "plane". <br />
<br />
{{PARAMNAMEDEF|Yaw Pan Deadband LPF}}: <br><br />
Sets the pan deadband low-pass filter for the yaw axis.<br />
<br />
== Rc Inputs Tab ==<br />
<br />
The parameters in the {{GUI|Rc Inputs}} tab are comprehensively described in the article [[Configure_the_RC_Input|Configure the RC Input]].<br />
<br />
{{PARAMNAMEDEF|Rc Dead Band}}: <br> Sets a deadband around zero input, to suppress noise on the input. Effective for all three axes.<br />
<br />
{{PARAMNAMEDEF|Rc Hysteresis}}: <br> Sets a hysteresis to value changes, to suppress noise on the input. Effective for all three axes.<br />
<br />
{{PARAMNAMEDEF|Rc Pitch Trim}}, {{PARAMNAMEDEF|Rc Roll Trim}}, {{PARAMNAMEDEF|Rc Yaw Trim}}: <br> Sets the mid position for teh pitch, roll and yaw axis, respectively. <br />
<br />
{{PARAMNAMEDEF|Rc Pitch}}, {{PARAMNAMEDEF|Rc Roll}}, {{PARAMNAMEDEF|Rc Yaw}}: <br> Selects the input channel used for controlling the pitch, roll, and yaw axis, respectively.<br />
<br />
{{PARAMNAMEDEF|Rc Pitch Mode}}, {{PARAMNAMEDEF|Rc Roll Mode}}, {{PARAMNAMEDEF|Rc Yaw Mode}}: <br> Sets the mode for the pitch, roll, and yaw axis, respectively.<br />
<br />
{{PARAMNAMEDEF|Rc Pitch Min}}, {{PARAMNAMEDEF|Rc Roll Min}}, {{PARAMNAMEDEF|Rc Yaw Min}}: <br> Sets the minimum angle for the pitch, roll, and yaw axis, respectively.<br />
<br />
{{PARAMNAMEDEF|Rc Pitch Max}}, {{PARAMNAMEDEF|Rc Roll Max}}, {{PARAMNAMEDEF|Rc Yaw Max}}: <br> Sets the maximum angle for the pitch, roll, and yaw axis, respectively.<br />
<br />
{{PARAMNAMEDEF|Rc Pitch Speed Limit}}, {{PARAMNAMEDEF|Rc Roll Speed Limit}}, {{PARAMNAMEDEF|Rc Yaw Speed Limit}}: <br> Sets the maximum speed for the pitch, roll, and yaw axis, respectively. A value of 0 disables the speed limiter (it is not fully deactivated, the speed limit is set to 100 deg/s).<br />
<br />
{{PARAMNAMEDEF|Rc Pitch Accel Limit}}, {{PARAMNAMEDEF|Rc Roll Accel Limit}}, {{PARAMNAMEDEF|Rc Yaw Accel Limit}}: <br> Sets the maximum acceleration for the pitch, roll, and yaw axis, respectively. A value of 0 disables the acceleration limiter (it is not fully deactivated, a small limit remains).<br />
<br />
{{PARAMNAMEDEF|Rc Pitch Expo}}, {{PARAMNAMEDEF|Rc Roll Expo}}, {{PARAMNAMEDEF|Rc Yaw Expo}}: <br> Sets the expo for the pitch, roll, and yaw axis, respectively.<br />
<br />
{{GUIFIELD|Auto Trim}}:<br> Reads the current input values and adjusts the trim values such as to make them zero.<br />
<br />
== Functions Tab ==<br />
<br />
{{PARAMNAMEDEF|Re-center Camera}}, {{PARAMNAMEDEF|Re-center Camera Axes}}, {{PARAMNAMEDEF|Re-center Camera Mode}}: <br> See [[Advanced_Functions#Re-center_Camera|Advanced Functions: Re-center Camera]].<br />
<br />
{{PARAMNAMEDEF|Retract}}: <br> Puts the gimbal in retract mode.<br />
<br />
{{PARAMNAMEDEF|Standby}}: <br> See [[Advanced_Functions#Standby|Advanced Functions: Standby]].<br />
<br />
{{PARAMNAMEDEF|Camera Control}}, {{PARAMNAMEDEF|Camera Control2}}, {{PARAMNAMEDEF|Camera Model}}, {{PARAMNAMEDEF|Camera Control Mode}}, {{PARAMNAMEDEF|Time Interval}}, {{PARAMNAMEDEF|Camera ComPort}}: <br> See [[Advanced_Functions#Camera_Remote_Control|Advanced Functions: Camera Remote Control]].<br />
<br />
{{PARAMNAMEDEF|Pwm Out Control}}, {{PARAMNAMEDEF|Pwm Out Mid}}, {{PARAMNAMEDEF|Pwm Out Min}}, {{PARAMNAMEDEF|Pwm Out Max}}, {{PARAMNAMEDEF|Pwm Out Speed Limit}}: <br> See [[Advanced_Functions#Pwm_Out|Advanced Functions: Pwm Out]].<br />
<br />
== Scripts Tab ==<br />
<br />
The parameters in the {{GUI|Scripts}} tab are comprehensively described in the article [[STorM32_Scripts|STorM32 Scripts]].<br />
<br />
== Setup Tab ==<br />
<br />
=== In Conventional Mode: ===<br />
<br />
{{PARAMNAMEDEF|Imu2 Configuration}}: <br><br />
Selects how a 2nd IMU is used. See also [[Using a 2nd IMU]].<br />
<br />
{{PARAMNAMEDEF|Startup Mode}}: <br><br />
Selects the startup algorithm. Can be set to {{PARAMVALUE|fast}} for invoking fast startup. For fast startup to be activated, additional conditions have to be met: IMU2 must be present, the motor directions and positions must have been configured, and IMU1 and IMU2 must have be calibrated. The gimbal should also have been tuned.<br />
<br />
=== All Modes: ===<br />
<br />
{{PARAMNAMEDEF|Startup Delay}}: <br><br />
Sets a startup delay time.<br />
<br />
{{PARAMNAMEDEF|Prearm Checks}}: <br><br />
Bitmask to enable various pre-arming checks, i.e., conditions which need to be fulfilled before the STroM32 goes into NORMAL mode. <br />
<br />
{{PARAMNAMEDEF|Virtual Channel Configuration}}: <br><br />
Selects the physical source for the {{PARAMVALUE|Virtual-1}}, ..., {{PARAMVALUE|Virtual-16}} input values. See [[Inputs and Functions]] for understanding the STorM32's concept of inputs, and [[Configure_the_RC_Input#Wiring_for_SUM-PPM_Signals|Configure the RC Input: Wiring for SUM-PPM Signals]] and [[Configure_the_RC_Input#Wiring_for_Digital_Signals|Configure the RC Input: Wiring for Digital Signals]] for typical use cases.<br />
<br />
{{PARAMNAMEDEF|Pwm Out Configuration}}: <br><br />
Enables the pwm out function, see [[Advanced_Functions#Pwm_Out|Advanced Functions: Pwm Out]].<br />
<br />
{{PARAMNAMEDEF|Rc Pitch Offset}}, {{PARAMNAMEDEF|Rc Roll Offset}}, {{PARAMNAMEDEF|Rc Yaw Offset}}: <br><br />
Adds a permanent offset to the camera orientation. <br />
<br />
{{PARAMNAMEDEF|UartX Configuration}}: <br> <br />
Reconfigures the RC-0, RC-1 pins to work as UART, depending on the setting. Allows to enable the OLed display support on pin RC-1 (see [[Advanced_Functions#OLED_Display|Advanced Functions: OLED Display]]) or enables the UartX serial for the [[NT_Camera|NT Camera]].<br />
<br />
{{PARAMNAMEDEF|Low Voltage Limit}}: <br> Voltage level at which the lipo-saver function is triggered, see [[Advanced_Functions#Lipo_Saver|Advanced Functions: Lipo Saver]]. <br />
<br />
{{PARAMNAMEDEF|Beep with Motors}}: <br><br />
Enables the emission of beeps by the motors, see [[Advanced_Functions#Beeps|Advanced Functions: Beeps]].<br />
<br />
{{PARAMNAMEDEF|NT Logging}}:<br><br />
Adjusts which parameters are logged, see [[NT_Data_Logging#GUI_Settings|NT Data Logging: GUI Settings]].<br />
<br />
{{PARAMNAMEDEF|Pitch Motor Usage}}, {{PARAMNAMEDEF|Roll Motor Usage}}, {{PARAMNAMEDEF|Yaw Motor Usage}}: <br><br />
Selects the operation mode of the pitch, roll, or yaw motor, respectively. When {{PARAMVALUE|disabled}} is selected, the motor does not receive any power.<br />
<br />
== Gimbal Configuration Tab ==<br />
<br />
=== In Conventional Mode: ===<br />
<br />
{{PARAMNAMEDEF|Pitch Motor Poles}}, {{PARAMNAMEDEF|Roll Motor Poles}}, {{PARAMNAMEDEF|Yaw Motor Poles}}:<br><br />
Number of magnet poles of the pitch, roll or yaw motor, respectively. Range is 8 - 42.<br />
<br />
{{PARAMNAMEDEF|Pitch Motor Direction}}, {{PARAMNAMEDEF|Roll Motor Direction}}, {{PARAMNAMEDEF|Yaw Motor Direction}}:<br><br />
Rotation direction of the pitch, roll or yaw motor, respectively. <br />
<br />
{{PARAMNAMEDEF|Pitch Startup Motor Pos}}, {{PARAMNAMEDEF|Roll Startup Motor Pos}}, {{PARAMNAMEDEF|Yaw Startup Motor Pos}}:<br><br />
Orientation of the pitch, roll or yaw motor at power up, respectively.<br />
<br />
=== In T-STorM32 Mode: ===<br />
<br />
{{PARAMNAMEDEF|Foc Pitch Motor Direction}}, {{PARAMNAMEDEF|Foc Roll Motor Direction}}, {{PARAMNAMEDEF|Foc Yaw Motor Direction}}:<br><br />
Rotation direction of the pitch, roll or yaw motor, respectively. <br />
<br />
{{PARAMNAMEDEF|Foc Pitch Zero Pos}}, {{PARAMNAMEDEF|Foc Roll Zero Pos}}, {{PARAMNAMEDEF|Foc Yaw Zero Pos}}:<br><br />
Motor position at zero Imu angle for the pitch, roll or yaw axis, respectively.<br />
<br />
=== All Modes: ===<br />
<br />
{{PARAMNAMEDEF|Imu Orientation}}, {{PARAMNAMEDEF|Imu2 Orientation}}:<br><br />
Orientation number of the IMU1 or IMU2, respectively. <br />
<br />
{{PARAMNAMEDEF|Pitch Offset}}, {{PARAMNAMEDEF|Roll Offset}}, {{PARAMNAMEDEF|Yaw Offset}}:<br><br />
Coefficients to correct for slight inaccuracies in the calibration of the IMU1 accelerometer.<br />
<br />
== Interfaces Tool Window ==<br />
<br />
{{PARAMNAMEDEF|Mavlink Gimbal}}, {{PARAMNAMEDEF|Mavlink Gimbal Stream}}, {{PARAMNAMEDEF|Mavlink ComPort}}, {{PARAMNAMEDEF|Mavlink System ID}}, {{PARAMNAMEDEF|Mavlink Camera}}:<br><br />
Parameters for handling Mavlink messages, see [[MAVLink Communication]].<br />
<br />
{{PARAMNAMEDEF|STorM32Link Configuration}}<!--, {{PARAMNAMEDEF|STorM32Link AHRS Factor}}-->:<br><br />
Parameters for handling the [[STorM32-Link|STorM32 Link]]. The setting {{PARAMNAMEDEF|STorM32Link Configuration}} = {{PARAMVALUE|yaw drift comp.}} enables the yaw drift compensation, but not horizon drift compensation. The setting {{PARAMNAMEDEF|STorM32Link Configuration}} = {{PARAMVALUE|v1}} enables both the yaw drift compensation and horizon drift compensation. For further info on the STorM32-Link see the article [[STorM32-Link]].<br />
<br />
{{PARAMNAMEDEF|Uart Baudrate}}, {{PARAMNAMEDEF|Uart2 Baudrate}}, {{PARAMNAMEDEF|Usb Baudrate}}:<br><br />
Baudrates used for the UART, USB, and UART2 ports. The default baudrates are 115200 bps.<br />
<br />
== Expert Tool Window ==<br />
<br />
=== In Conventional Mode: ===<br />
<br />
{{PARAMNAMEDEF|Motor Mapping}}:<br><br />
Allows us to change the assignment of the pitch, roll and yaw motors to the ports MOT0, MOT1, MOT2. The default assignment is pitch = MOT0, roll = MOT1, yaw = MOT2.<br />
<br />
{{PARAMNAMEDEF|Imu2 Rotation}}: <br><br />
Allows us to configure for different mounting options of the 2nd IMU. See also [[Using a 2nd IMU]].<br />
<br />
{{PARAMNAMEDEF|Flip Gimbal Control}}: <br><br />
Allows us to use an input signal to switch the configuration of the gimbal between "down-hanging" and "up-standing".<br />
<br />
=== All Modes: ===<br />
<br />
{{PARAMNAMEDEF|Imu Mapping}}: <br><br />
Allows us to swap IMU1 and IMU2 (this swaps NT IMU1 and NT IMU2, not the on-board IMU, which always will be IMU2 if used) .<br />
<br />
{{PARAMNAMEDEF|Lipo Cells}}: <br><br />
Sets the number of cells of the battery. Default is {{PARAMVALUE|auto}}, which determines the number of cells from the battery voltage at power up.<br />
<br />
{{PARAMNAMEDEF|Lipo Voltage per Cell}}: <br><br />
Full charge voltage of a battery cell. Default is 4.20 V, appropriate for a LIPO.<br />
<br />
{{PARAMNAMEDEF|ADC Calibration}}: <br><br />
Calibration constant for voltage measurement. The default value {{PARAMVALUE|1550}} is slightly below the theoretically correct value of 1581.<br />
<br />
{{PARAMNAMEDEF|Imu AHRS}}: <br><br />
Adjusts how strongly the accelerometer data are included in the data fusing for the attitude estimation. The shorter the time the stronger the accelerometer data are weighted (0 = accelerometer only, 20 = gyro only).<br />
<br />
{{PARAMNAMEDEF|Startup Gyro Calibration}}: <br><br />
Sets the gyro calibration at startup. Default is {{PARAMVALUE|normal}}.<br />
<br />
==== The following parameters should be set with care. Normally, there should be no reason to modify them. ====<br />
<br />
{{PARAMNAMEDEF|Acc LPF}}: <br> <br />
Digital low pass filter applied to the raw accelerometer data. It also affects the behavior of the AHRS.<br />
<br />
{{PARAMNAMEDEF|Rc Adc LPF}}: <br> <br />
Digital low pass filter applied to the Rc Input values. Might be helpful for very noisy RC transmitters.<br />
<br />
{{PARAMNAMEDEF|Pan Hold Transition Time}}, {{PARAMNAMEDEF|Pan Speed Limit}}, {{PARAMNAMEDEF|Pan Accel Limit}}: <br><br />
These parameters are related to the pan-to-hold and hold-to-pan transition behavior. The parameter {{PARAMNAMEDEF|Pan Hold Transition Time}} determines for how long a trajectory filter is applied to smooth the transition. The two limit parameters determine the speed and acceleration limits of the trajectory filter.<br />
<br />
{{PARAMNAMEDEF|Foc Emergency}}: <br> <br />
Sets the level of the emergency detection mechanism.<br />
<br />
{{PARAMNAMEDEF|Acc Compensation Method}}:<br><br />
Selects the algorithm which is used for fusing the accelerometer and gyro data. Can be {{PARAMVALUE|standard}} or {{PARAMVALUE|advanced}}. The parameter affects the AHRS, and should be set with understanding. These posts might be useful: [http://www.rcgroups.com/forums/showthread.php?t=2055844&page=27&pp=50#post29173129], [http://www.rcgroups.com/forums/showthread.php?t=2055844&page=27&pp=50#post29176384], [http://www.rcgroups.com/forums/showthread.php?t=2055844&page=27&pp=50#post29176832].<br />
<br />
== Expert Tool Window ==<br />
<br />
The parameters in the {{GUI|Filter}} tab allow to set norh/band-pass filters.<br />
<br />
<br />
== Gimbal Mechanics Tool Window ==<br />
<br />
The parameters in the {{GUI|Gimbal Mechanics}} tab allow to set mechanical gimbal limits. They are experimental.<br />
<br />
=== All Modes: ===<br />
<br />
{{PARAMNAMEDEF|Yaw Motor Limit}}:<br> Limit for yaw axis.<br />
<br />
{{PARAMNAMEDEF|Setpoint Speed Limit}}, {{PARAMNAMEDEF|Setpoint Accel Limit}}:<br> Speed and acceleration limits for changes of the setpoint.<br />
<br />
=== In T-STorM32 Mode: ===<br />
<br />
{{PARAMNAMEDEF|Pitch Motor Limit Min}}, {{PARAMNAMEDEF|Pitch Motor Limit Max}}, {{PARAMNAMEDEF|Roll Motor Limit}}:<br> Limits for pitch and roll axes.<br />
<br />
== Gimbal Model Tool Window ==<br />
<br />
The parameters in the {{GUI|Gimbal Model}} tab are comprehensively described in the article [[Model-based_Control|Model-based Control]].<br />
<br />
=== In T-STorM32 Mode: ===<br />
<br />
{{PARAMNAMEDEF|T1 Pitch}}, {{PARAMNAMEDEF|T1 Roll}}, {{PARAMNAMEDEF|T1 Yaw}}:<br><br />
Relative moments of inertia of the camera along the pitch, roll and yaw directions.<br />
<br />
{{PARAMNAMEDEF|T2 Roll}}, {{PARAMNAMEDEF|T2 Yaw}}:<br><br />
Relative moments of inertia of the roll arm along the roll and yaw directions.<br />
<br />
== Servo Tool Window ==<br />
<br />
=== In T-STorM32 Mode: ===<br />
<br />
{{PARAMNAMEDEF|Servo Pitch P}}, {{PARAMNAMEDEF|Servo Pitch I}}, {{PARAMNAMEDEF|Servo Pitch D}}, {{PARAMNAMEDEF|Servo Pitch DLPF}}:<br><br />
Parameters for the position PID controller in servo mode for the pitch axis.<br />
<br />
{{PARAMNAMEDEF|Servo Roll P}}, {{PARAMNAMEDEF|Servo Roll I}}, {{PARAMNAMEDEF|Servo Roll D}}, {{PARAMNAMEDEF|Servo Roll DLPF}}:<br><br />
Parameters for the position PID controller in servo mode for the roll axis.<br />
<br />
{{PARAMNAMEDEF|Servo Yaw P}}, {{PARAMNAMEDEF|Servo Yaw I}}, {{PARAMNAMEDEF|Servo Yaw D}}, {{PARAMNAMEDEF|Servo Yaw DLPF}}:<br><br />
Parameters for the position PID controller in servo mode for the yaw axis.<br />
<!--<br />
{{PARAMNAMEDEF|Imu Acc Threshold}}:<br><br />
Maximal residual acceleration up to which the accelerometer data are taken into account in the attitude estimation. This parameter is effective only when {{PARAMNAME|Acc Compensation Method}} is set to {{PARAMVALUE|standard}}.<br />
<br />
{{PARAMNAMEDEF|Acc Noise Level}}:<br><br />
Residual acceleration up to which the accelerometer data are taken into account with maximal weight in the attitude estimation. Effective only when {{PARAMNAME|Acc Compensation Method}} = {{PARAMVALUE|advanced}}.<br />
<br />
{{PARAMNAMEDEF|Acc Threshold}}:<br><br />
Maximal residual acceleration up to which the accelerometer data are taken into account in the attitude estimation with non-zero weight. Effective only when {{PARAMNAME|Acc Compensation Method}} = {{PARAMVALUE|advanced}}.<br />
<br />
{{PARAMNAMEDEF|Acc Vertical Weight}}:<br><br />
Weight of the vertical residual acceleration in determining the weight of the accelerometer data in the attitude estimation. Effective only when {{PARAMNAME|Acc Compensation Method}} = {{PARAMVALUE|advanced}}.<br />
<br />
{{PARAMNAMEDEF|Acc Zentrifugal Correction}}:<br><br />
Weight of the centrifugal acceleration in determining the weight of the accelerometer data in the attitude estimation. Effective only when {{PARAMNAME|Acc Compensation Method}} = {{PARAMVALUE|advanced}}.<br />
<br />
{{PARAMNAMEDEF|Acc Recover Time}}:<br><br />
Fall time for recovering from a reduced weight of the accelerometer data in the attitude estimation. The rise time is determined implicitly by the {{PARAMNAME|Acc LPF}} parameter value. Effective only when {{PARAMNAME|Acc Compensation Method}} = {{PARAMVALUE|advanced}}.<br />
--></div>OlliWhttp://www.olliw.eu/storm32bgc-v2-wiki/index.php?title=STorM32_Parameters&diff=11916STorM32 Parameters2025-11-30T10:44:59Z<p>OlliW: </p>
<hr />
<div><span style="font-size:88%">''The information on this page refers to firmware v2.72e.''</span><br />
<br />
List of all STorM32 parameters, and some GUI features, with brief explanations and/or links to more comprehensive articles.<br />
<br />
{{COMMENT|The parameters are displayed and enabled in the GUI depending on whether the STorM32 gimbal is in "'''Conventional Mode'''" or "'''T-STorM32 Mode'''". The active mode can be inferred from the GUI's title, and is updated to the correct current mode upon a connection to a STorM32 controller.}}<br />
<br />
<div class="toclimit-2">__TOC__</div><br />
<br />
== Dashboard Tab ==<br />
<br />
{{GUIFIELD|Change Name}}:<br><br />
Opens a dialog, which allows you to change the name of the board.<br />
<br />
{{GUIFIELD|Share Settings}}:<br><br />
Opens a dialog, which presents all parameters comprehensively. Taking a screen shot by pressing one of the "Save Screenshot" buttons provides a useful method for sharing parameter settings.<br />
<br />
{{GUIFIELD|Check for Updates}}:<br><br />
Opens a dialog, which connects to the STorM32 github repository to check if a new firmware is available.<br />
<br />
== PID Tab ==<br />
<br />
=== In Conventional Mode: ===<br />
<br />
{{PARAMNAMEDEF|Gyro LPF}}: <br> Digital low pass filter applied to the raw gyro data. Can help to avoid vibrations and/or reach higher PID values. Values relate to the time constant of the filter.<br />
<br />
{{PARAMNAMEDEF|Imu2 FeedForward LPF}}: <br> Digital low pass filter applied to the attitude data of the 2nd IMU before it enters the feedforward channel in the PID controller. Effective only when the 2nd IMU is enabled, i.e., when {{PARAMNAME|Imu2 Configuration}} is not {{PARAMVALUE|off}}. Values relate to the time constant of the filter.<br />
<br />
{{PARAMNAMEDEF|Pitch P}}, {{PARAMNAMEDEF|Roll P}}, {{PARAMNAMEDEF|Yaw P}}: <br> Proportional term of the PID controller for the pitch, roll or yaw axis, respectively. See also [[Tuning_Recipe#Tuning_Procedure|Tuning Recipe: Tuning Procedure]].<br />
<br />
{{PARAMNAMEDEF|Pitch I}}, {{PARAMNAMEDEF|Roll I}}, {{PARAMNAMEDEF|Yaw I}}: <br> Integral term of the PID controller for the pitch, roll or yaw axis, respectively. See also [[Tuning_Recipe#Tuning_Procedure|Tuning Recipe: Tuning Procedure]].<br />
<br />
{{PARAMNAMEDEF|Pitch D}}, {{PARAMNAMEDEF|Roll D}}, {{PARAMNAMEDEF|Yaw D}}: <br> Derivative term of the PID controller for the pitch, roll or yaw axis, respectively. See also [[Tuning_Recipe#Tuning_Procedure|Tuning Recipe: Tuning Procedure]].<br />
<br />
{{PARAMNAMEDEF|Pitch Motor Vmax}}, {{PARAMNAMEDEF|Roll Motor Vmax}}, {{PARAMNAMEDEF|Yaw Motor Vmax}}: <br> Maximal average voltage for the pitch, roll or yaw motor, respectively. Range is 0 - 255. See also [[Tuning_Recipe#Setting_Motor_Vmax|Tuning Recipe: Setting Motor Vmax]].<br />
<br />
{{PARAMNAMEDEF|Voltage Correction}}: <br> Attempts to compensate the effects of a (slowly) varying battery voltage on the PID controller tuning, see [[Advanced_Functions#Voltage_Correction|Advanced Functions: Voltage Correction]].<br />
<br />
{{PARAMNAMEDEF|Controller}}: <br> Enables the model-based controller. The settings {{PARAMVALUE|default}} and {{PARAMVALUE|roll mixing}} are available, where the first corresponds to the "old" behavior, and the second enables improved roll mixing.<br />
<br />
{{GUIFIELD|Use simplified PID tuning}}: <br> Toggles between the standard PID tuning, in which the P, I D values are adjusted, and a simplified mechanism, in which tuning is achieved by only two parameters, called Damping and Stability.<br />
<br />
=== In T-STorM32 Mode: ===<br />
<br />
{{PARAMNAMEDEF|Foc Gyro LPF}}: <br> Digital low pass filter applied to the raw gyro data. Can help to avoid vibrations and/or reach higher PID values. Values relate to the time constant of the filter.<br />
<br />
{{PARAMNAMEDEF|Foc Pitch P}}, {{PARAMNAMEDEF|Foc Roll P}}, {{PARAMNAMEDEF|Foc Yaw P}}: <br> Proportional term of the PID controller for the pitch, roll or yaw axis, respectively.<br />
<br />
{{PARAMNAMEDEF|Foc Pitch I}}, {{PARAMNAMEDEF|Foc Roll I}}, {{PARAMNAMEDEF|Foc Yaw I}}: <br> Integral term of the PID controller for the pitch, roll or yaw axis, respectively.<br />
<br />
{{PARAMNAMEDEF|Foc Pitch D}}, {{PARAMNAMEDEF|Foc Roll D}}, {{PARAMNAMEDEF|Foc Yaw D}}: <br> Derivative term of the PID controller for the pitch, roll or yaw axis, respectively.<br />
<br />
{{PARAMNAMEDEF|Foc Pitch K}}, {{PARAMNAMEDEF|Foc Roll K}}, {{PARAMNAMEDEF|Foc Yaw K}}: <br> Factor which multiplies the P, I, and D values.<br />
<br />
{{PARAMNAMEDEF|Foc Controller}}: <br> Enables the model-based controller. The setting {{PARAMVALUE|default}} corresponds to the "old" behavior.<br />
<br />
=== All Modes: ===<br />
<br />
{{PARAMNAMEDEF|D Source}}: <br> The settings “default” and “gyro” are available. "gyro" enables the "new" lag-free and lower-noise controller D-term calculation. This setting is enabled per default. "default" enables the "old" method of D-term calculation. This parameter may be removed in upcoming firmwares.<br />
<br />
{{GUIFIELD|Auto write PID changes}}:<br><br />
When checked, any change to the PID values (and only to the PID values) is written to the STorM32 board after ca. 1 sec.<br />
<br />
== Pan Tab ==<br />
<br />
The parameters in the {{GUI|Pan}} tab are comprehensively described in the article [[Hold_versus_Pan_Mode|Hold versus pan Mode]].<br />
<br />
{{PARAMNAMEDEF|Pan Mode Control}}: <br> Selects the input channel used for changing the pan mode. <br />
<br />
{{PARAMNAMEDEF|Pan Mode Default Setting}}, {{PARAMNAMEDEF|Pan Mode Setting #1}}, {{PARAMNAMEDEF|Pan Mode Setting #2}}, {{PARAMNAMEDEF|Pan Mode Setting #3}}: <br><br />
Selects the pan states for each axis, for each of the four possible states of the input channel.<br />
<br />
{{PARAMNAMEDEF|Pitch Pan}}, {{PARAMNAMEDEF|Roll Pan}}, {{PARAMNAMEDEF|Yaw Pan}}: <br><br />
Sets the pan speed for pitch, roll and yaw, respectively.<br />
<br />
{{PARAMNAMEDEF|Pitch Pan Deadband}}, {{PARAMNAMEDEF|Roll Pan Deadband}}, {{PARAMNAMEDEF|Yaw Pan Deadband}}:<br><br />
Sets the pan deadband for pitch, roll and yaw, respectively.<br />
<br />
{{PARAMNAMEDEF|Pitch Pan Expo}}, {{PARAMNAMEDEF|Roll Pan Expo}}, {{PARAMNAMEDEF|Yaw Pan Expo}}: <br><br />
Sets the pan expo for pitch, roll and yaw, respectively.<br />
<br />
{{PARAMNAMEDEF|Pitch Pan Method}}, {{PARAMNAMEDEF|Roll Pan Method}}: <br><br />
Sets the pan method for pitch and roll, respectively. Can be "normal" or "plane". <br />
<br />
{{PARAMNAMEDEF|Yaw Pan Deadband LPF}}: <br><br />
Sets the pan deadband low-pass filter for the yaw axis.<br />
<br />
== Rc Inputs Tab ==<br />
<br />
The parameters in the {{GUI|Rc Inputs}} tab are comprehensively described in the article [[Configure_the_RC_Input|Configure the RC Input]].<br />
<br />
{{PARAMNAMEDEF|Rc Dead Band}}: <br> Sets a deadband around zero input, to suppress noise on the input. Effective for all three axes.<br />
<br />
{{PARAMNAMEDEF|Rc Hysteresis}}: <br> Sets a hysteresis to value changes, to suppress noise on the input. Effective for all three axes.<br />
<br />
{{PARAMNAMEDEF|Rc Pitch Trim}}, {{PARAMNAMEDEF|Rc Roll Trim}}, {{PARAMNAMEDEF|Rc Yaw Trim}}: <br> Sets the mid position for teh pitch, roll and yaw axis, respectively. <br />
<br />
{{PARAMNAMEDEF|Rc Pitch}}, {{PARAMNAMEDEF|Rc Roll}}, {{PARAMNAMEDEF|Rc Yaw}}: <br> Selects the input channel used for controlling the pitch, roll, and yaw axis, respectively.<br />
<br />
{{PARAMNAMEDEF|Rc Pitch Mode}}, {{PARAMNAMEDEF|Rc Roll Mode}}, {{PARAMNAMEDEF|Rc Yaw Mode}}: <br> Sets the mode for the pitch, roll, and yaw axis, respectively.<br />
<br />
{{PARAMNAMEDEF|Rc Pitch Min}}, {{PARAMNAMEDEF|Rc Roll Min}}, {{PARAMNAMEDEF|Rc Yaw Min}}: <br> Sets the minimum angle for the pitch, roll, and yaw axis, respectively.<br />
<br />
{{PARAMNAMEDEF|Rc Pitch Max}}, {{PARAMNAMEDEF|Rc Roll Max}}, {{PARAMNAMEDEF|Rc Yaw Max}}: <br> Sets the maximum angle for the pitch, roll, and yaw axis, respectively.<br />
<br />
{{PARAMNAMEDEF|Rc Pitch Speed Limit}}, {{PARAMNAMEDEF|Rc Roll Speed Limit}}, {{PARAMNAMEDEF|Rc Yaw Speed Limit}}: <br> Sets the maximum speed for the pitch, roll, and yaw axis, respectively. A value of 0 disables the speed limiter (it is not fully deactivated, the speed limit is set to 100 deg/s).<br />
<br />
{{PARAMNAMEDEF|Rc Pitch Accel Limit}}, {{PARAMNAMEDEF|Rc Roll Accel Limit}}, {{PARAMNAMEDEF|Rc Yaw Accel Limit}}: <br> Sets the maximum acceleration for the pitch, roll, and yaw axis, respectively. A value of 0 disables the acceleration limiter (it is not fully deactivated, a small limit remains).<br />
<br />
{{PARAMNAMEDEF|Rc Pitch Expo}}, {{PARAMNAMEDEF|Rc Roll Expo}}, {{PARAMNAMEDEF|Rc Yaw Expo}}: <br> Sets the expo for the pitch, roll, and yaw axis, respectively.<br />
<br />
{{GUIFIELD|Auto Trim}}:<br> Reads the current input values and adjusts the trim values such as to make them zero.<br />
<br />
== Functions Tab ==<br />
<br />
{{PARAMNAMEDEF|Re-center Camera}}, {{PARAMNAMEDEF|Re-center Camera Axes}}, {{PARAMNAMEDEF|Re-center Camera Mode}}: <br> See [[Advanced_Functions#Re-center_Camera|Advanced Functions: Re-center Camera]].<br />
<br />
{{PARAMNAMEDEF|Retract}}: <br> Puts the gimbal in retract mode.<br />
<br />
{{PARAMNAMEDEF|Standby}}: <br> See [[Advanced_Functions#Standby|Advanced Functions: Standby]].<br />
<br />
{{PARAMNAMEDEF|Camera Control}}, {{PARAMNAMEDEF|Camera Control2}}, {{PARAMNAMEDEF|Camera Model}}, {{PARAMNAMEDEF|Camera Control Mode}}, {{PARAMNAMEDEF|Time Interval}}, {{PARAMNAMEDEF|Camera ComPort}}: <br> See [[Advanced_Functions#Camera_Remote_Control|Advanced Functions: Camera Remote Control]].<br />
<br />
{{PARAMNAMEDEF|Pwm Out Control}}, {{PARAMNAMEDEF|Pwm Out Mid}}, {{PARAMNAMEDEF|Pwm Out Min}}, {{PARAMNAMEDEF|Pwm Out Max}}, {{PARAMNAMEDEF|Pwm Out Speed Limit}}: <br> See [[Advanced_Functions#Pwm_Out|Advanced Functions: Pwm Out]].<br />
<br />
== Scripts Tab ==<br />
<br />
The parameters in the {{GUI|Scripts}} tab are comprehensively described in the article [[STorM32_Scripts|STorM32 Scripts]].<br />
<br />
== Setup Tab ==<br />
<br />
=== In Conventional Mode: ===<br />
<br />
{{PARAMNAMEDEF|Imu2 Configuration}}: <br><br />
Selects how a 2nd IMU is used. See also [[Using a 2nd IMU]].<br />
<br />
{{PARAMNAMEDEF|Startup Mode}}: <br><br />
Selects the startup algorithm. Can be set to {{PARAMVALUE|fast}} for invoking fast startup. For fast startup to be activated, additional conditions have to be met: IMU2 must be present, the motor directions and positions must have been configured, and IMU1 and IMU2 must have be calibrated. The gimbal should also have been tuned.<br />
<br />
=== All Modes: ===<br />
<br />
{{PARAMNAMEDEF|Startup Delay}}: <br><br />
Sets a startup delay time.<br />
<br />
{{PARAMNAMEDEF|Prearm Checks}}: <br><br />
Bitmask to enable various pre-arming checks, i.e., conditions which need to be fulfilled before the STroM32 goes into NORMAL mode. <br />
<br />
{{PARAMNAMEDEF|Virtual Channel Configuration}}: <br><br />
Selects the physical source for the {{PARAMVALUE|Virtual-1}}, ..., {{PARAMVALUE|Virtual-16}} input values. See [[Inputs and Functions]] for understanding the STorM32's concept of inputs, and [[Configure_the_RC_Input#Wiring_for_SUM-PPM_Signals|Configure the RC Input: Wiring for SUM-PPM Signals]] and [[Configure_the_RC_Input#Wiring_for_Digital_Signals|Configure the RC Input: Wiring for Digital Signals]] for typical use cases.<br />
<br />
{{PARAMNAMEDEF|Pwm Out Configuration}}: <br><br />
Enables the pwm out function, see [[Advanced_Functions#Pwm_Out|Advanced Functions: Pwm Out]].<br />
<br />
{{PARAMNAMEDEF|Rc Pitch Offset}}, {{PARAMNAMEDEF|Rc Roll Offset}}, {{PARAMNAMEDEF|Rc Yaw Offset}}: <br><br />
Adds a permanent offset to the camera orientation. <br />
<br />
{{PARAMNAMEDEF|UartX Configuration}}: <br> <br />
Reconfigures the RC-0, RC-1 pins to work as UART, depending on the setting. Allows to enable the OLed display support on pin RC-1 (see [[Advanced_Functions#OLED_Display|Advanced Functions: OLED Display]]) or enables the UartX serial for the [[NT_Camera|NT Camera]].<br />
<br />
{{PARAMNAMEDEF|Low Voltage Limit}}: <br> Voltage level at which the lipo-saver function is triggered, see [[Advanced_Functions#Lipo_Saver|Advanced Functions: Lipo Saver]]. <br />
<br />
{{PARAMNAMEDEF|Beep with Motors}}: <br><br />
Enables the emission of beeps by the motors, see [[Advanced_Functions#Beeps|Advanced Functions: Beeps]].<br />
<br />
{{PARAMNAMEDEF|NT Logging}}:<br><br />
Adjusts which parameters are logged, see [[NT_Data_Logging#GUI_Settings|NT Data Logging: GUI Settings]].<br />
<br />
{{PARAMNAMEDEF|Pitch Motor Usage}}, {{PARAMNAMEDEF|Roll Motor Usage}}, {{PARAMNAMEDEF|Yaw Motor Usage}}: <br><br />
Selects the operation mode of the pitch, roll, or yaw motor, respectively. When {{PARAMVALUE|disabled}} is selected, the motor does not receive any power.<br />
<br />
== Gimbal Configuration Tab ==<br />
<br />
=== In Conventional Mode: ===<br />
<br />
{{PARAMNAMEDEF|Pitch Motor Poles}}, {{PARAMNAMEDEF|Roll Motor Poles}}, {{PARAMNAMEDEF|Yaw Motor Poles}}:<br><br />
Number of magnet poles of the pitch, roll or yaw motor, respectively. Range is 8 - 42.<br />
<br />
{{PARAMNAMEDEF|Pitch Motor Direction}}, {{PARAMNAMEDEF|Roll Motor Direction}}, {{PARAMNAMEDEF|Yaw Motor Direction}}:<br><br />
Rotation direction of the pitch, roll or yaw motor, respectively. <br />
<br />
{{PARAMNAMEDEF|Pitch Startup Motor Pos}}, {{PARAMNAMEDEF|Roll Startup Motor Pos}}, {{PARAMNAMEDEF|Yaw Startup Motor Pos}}:<br><br />
Orientation of the pitch, roll or yaw motor at power up, respectively.<br />
<br />
=== In T-STorM32 Mode: ===<br />
<br />
{{PARAMNAMEDEF|Foc Pitch Motor Direction}}, {{PARAMNAMEDEF|Foc Roll Motor Direction}}, {{PARAMNAMEDEF|Foc Yaw Motor Direction}}:<br><br />
Rotation direction of the pitch, roll or yaw motor, respectively. <br />
<br />
{{PARAMNAMEDEF|Foc Pitch Zero Pos}}, {{PARAMNAMEDEF|Foc Roll Zero Pos}}, {{PARAMNAMEDEF|Foc Yaw Zero Pos}}:<br><br />
Motor position at zero Imu angle for the pitch, roll or yaw axis, respectively.<br />
<br />
=== All Modes: ===<br />
<br />
{{PARAMNAMEDEF|Imu Orientation}}, {{PARAMNAMEDEF|Imu2 Orientation}}:<br><br />
Orientation number of the IMU1 or IMU2, respectively. <br />
<br />
{{PARAMNAMEDEF|Pitch Offset}}, {{PARAMNAMEDEF|Roll Offset}}, {{PARAMNAMEDEF|Yaw Offset}}:<br><br />
Coefficients to correct for slight inaccuracies in the calibration of the IMU1 accelerometer.<br />
<br />
== Interfaces Tool Window ==<br />
<br />
{{PARAMNAMEDEF|Mavlink Gimbal}}, {{PARAMNAMEDEF|Mavlink Gimbal Stream}}, {{PARAMNAMEDEF|Mavlink ComPort}}, {{PARAMNAMEDEF|Mavlink System ID}}, {{PARAMNAMEDEF|Mavlink Camera}}:<br><br />
Parameters for handling Mavlink messages, see [[MAVLink Communication]].<br />
<br />
{{PARAMNAMEDEF|STorM32Link Configuration}}<!--, {{PARAMNAMEDEF|STorM32Link AHRS Factor}}-->:<br><br />
Parameters for handling the [[STorM32-Link|STorM32 Link]]. The setting {{PARAMNAMEDEF|STorM32Link Configuration}} = {{PARAMVALUE|yaw drift comp.}} enables the yaw drift compensation, but not horizon drift compensation. The setting {{PARAMNAMEDEF|STorM32Link Configuration}} = {{PARAMVALUE|v1}} enables both the yaw drift compensation and horizon drift compensation. For further info on the STorM32-Link see the article [[STorM32-Link]].<br />
<br />
{{PARAMNAMEDEF|Uart Baudrate}}, {{PARAMNAMEDEF|Uart2 Baudrate}}, {{PARAMNAMEDEF|Usb Baudrate}}:<br><br />
Baudrates used for the UART, USB, and UART2 ports. The default baudrates are 115200 bps.<br />
<br />
== Expert Tool Window ==<br />
<br />
=== In Conventional Mode: ===<br />
<br />
{{PARAMNAMEDEF|Motor Mapping}}:<br><br />
Allows us to change the assignment of the pitch, roll and yaw motors to the ports MOT0, MOT1, MOT2. The default assignment is pitch = MOT0, roll = MOT1, yaw = MOT2.<br />
<br />
{{PARAMNAMEDEF|Imu2 Rotation}}: <br><br />
Allows us to configure for different mounting options of the 2nd IMU. See also [[Using a 2nd IMU]].<br />
<br />
{{PARAMNAMEDEF|Flip Gimbal Control}}: <br><br />
Allows us to use an input signal to switch the configuration of the gimbal between "down-hanging" and "up-standing".<br />
<br />
=== All Modes: ===<br />
<br />
{{PARAMNAMEDEF|Imu Mapping}}: <br><br />
Allows us to swap IMU1 and IMU2 (this swaps NT IMU1 and NT IMU2, not the on-board IMU, which always will be IMU2 if used) .<br />
<br />
{{PARAMNAMEDEF|Lipo Cells}}: <br><br />
Sets the number of cells of the battery. Default is {{PARAMVALUE|auto}}, which determines the number of cells from the battery voltage at power up.<br />
<br />
{{PARAMNAMEDEF|Lipo Voltage per Cell}}: <br><br />
Full charge voltage of a battery cell. Default is 4.20 V, appropriate for a LIPO.<br />
<br />
{{PARAMNAMEDEF|ADC Calibration}}: <br><br />
Calibration constant for voltage measurement. The default value {{PARAMVALUE|1550}} is slightly below the theoretically correct value of 1581.<br />
<br />
{{PARAMNAMEDEF|Imu AHRS}}: <br><br />
Adjusts how strongly the accelerometer data are included in the data fusing for the attitude estimation. The shorter the time the stronger the accelerometer data are weighted (0 = accelerometer only, 20 = gyro only).<br />
<br />
{{PARAMNAMEDEF|Startup Gyro Calibration}}: <br><br />
Sets the gyro calibration at startup. Default is {{PARAMVALUE|normal}}.<br />
<br />
==== The following parameters should be set with care. Normally, there should be no reason to modify them. ====<br />
<br />
{{PARAMNAMEDEF|Acc LPF}}: <br> <br />
Digital low pass filter applied to the raw accelerometer data. It also affects the behavior of the AHRS.<br />
<br />
{{PARAMNAMEDEF|Rc Adc LPF}}: <br> <br />
Digital low pass filter applied to the Rc Input values. Might be helpful for very noisy RC transmitters.<br />
<br />
{{PARAMNAMEDEF|Pan Hold Transition Time}}, {{PARAMNAMEDEF|Pan Speed Limit}}, {{PARAMNAMEDEF|Pan Accel Limit}}: <br><br />
These parameters are related to the pan-to-hold and hold-to-pan transition behavior. The parameter {{PARAMNAMEDEF|Pan Hold Transition Time}} determines for how long a trajectory filter is applied to smooth the transition. The two limit parameters determine the speed and acceleration limits of the trajectory filter.<br />
<br />
{{PARAMNAMEDEF|Foc Emergency}}: <br> <br />
Sets the level of the emergency detection mechanism.<br />
<br />
{{PARAMNAMEDEF|Acc Compensation Method}}:<br><br />
Selects the algorithm which is used for fusing the accelerometer and gyro data. Can be {{PARAMVALUE|standard}} or {{PARAMVALUE|advanced}}. The parameter affects the AHRS, and should be set with understanding. These posts might be useful: [http://www.rcgroups.com/forums/showthread.php?t=2055844&page=27&pp=50#post29173129], [http://www.rcgroups.com/forums/showthread.php?t=2055844&page=27&pp=50#post29176384], [http://www.rcgroups.com/forums/showthread.php?t=2055844&page=27&pp=50#post29176832].<br />
<br />
== Gimbal Mechanics Tool Window ==<br />
<br />
The parameters in the {{GUI|Gimbal Mechanics}} tab allow to set mechanical gimbal limits. They are experimental.<br />
<br />
=== All Modes: ===<br />
<br />
{{PARAMNAMEDEF|Yaw Motor Limit}}:<br> Limit for yaw axis.<br />
<br />
{{PARAMNAMEDEF|Setpoint Speed Limit}}, {{PARAMNAMEDEF|Setpoint Accel Limit}}:<br> Speed and acceleration limits for changes of the setpoint.<br />
<br />
=== In T-STorM32 Mode: ===<br />
<br />
{{PARAMNAMEDEF|Pitch Motor Limit Min}}, {{PARAMNAMEDEF|Pitch Motor Limit Max}}, {{PARAMNAMEDEF|Roll Motor Limit}}:<br> Limits for pitch and roll axes.<br />
<br />
== Gimbal Model Tool Window ==<br />
<br />
The parameters in the {{GUI|Gimbal Model}} tab are comprehensively described in the article [[Model-based_Control|Model-based Control]].<br />
<br />
=== In T-STorM32 Mode: ===<br />
<br />
{{PARAMNAMEDEF|T1 Pitch}}, {{PARAMNAMEDEF|T1 Roll}}, {{PARAMNAMEDEF|T1 Yaw}}:<br><br />
Relative moments of inertia of the camera along the pitch, roll and yaw directions.<br />
<br />
{{PARAMNAMEDEF|T2 Roll}}, {{PARAMNAMEDEF|T2 Yaw}}:<br><br />
Relative moments of inertia of the roll arm along the roll and yaw directions.<br />
<br />
== Servo Tool Window ==<br />
<br />
=== In T-STorM32 Mode: ===<br />
<br />
{{PARAMNAMEDEF|Servo Pitch P}}, {{PARAMNAMEDEF|Servo Pitch I}}, {{PARAMNAMEDEF|Servo Pitch D}}, {{PARAMNAMEDEF|Servo Pitch DLPF}}:<br><br />
Parameters for the position PID controller in servo mode for the pitch axis.<br />
<br />
{{PARAMNAMEDEF|Servo Roll P}}, {{PARAMNAMEDEF|Servo Roll I}}, {{PARAMNAMEDEF|Servo Roll D}}, {{PARAMNAMEDEF|Servo Roll DLPF}}:<br><br />
Parameters for the position PID controller in servo mode for the roll axis.<br />
<br />
{{PARAMNAMEDEF|Servo Yaw P}}, {{PARAMNAMEDEF|Servo Yaw I}}, {{PARAMNAMEDEF|Servo Yaw D}}, {{PARAMNAMEDEF|Servo Yaw DLPF}}:<br><br />
Parameters for the position PID controller in servo mode for the yaw axis.<br />
<!--<br />
{{PARAMNAMEDEF|Imu Acc Threshold}}:<br><br />
Maximal residual acceleration up to which the accelerometer data are taken into account in the attitude estimation. This parameter is effective only when {{PARAMNAME|Acc Compensation Method}} is set to {{PARAMVALUE|standard}}.<br />
<br />
{{PARAMNAMEDEF|Acc Noise Level}}:<br><br />
Residual acceleration up to which the accelerometer data are taken into account with maximal weight in the attitude estimation. Effective only when {{PARAMNAME|Acc Compensation Method}} = {{PARAMVALUE|advanced}}.<br />
<br />
{{PARAMNAMEDEF|Acc Threshold}}:<br><br />
Maximal residual acceleration up to which the accelerometer data are taken into account in the attitude estimation with non-zero weight. Effective only when {{PARAMNAME|Acc Compensation Method}} = {{PARAMVALUE|advanced}}.<br />
<br />
{{PARAMNAMEDEF|Acc Vertical Weight}}:<br><br />
Weight of the vertical residual acceleration in determining the weight of the accelerometer data in the attitude estimation. Effective only when {{PARAMNAME|Acc Compensation Method}} = {{PARAMVALUE|advanced}}.<br />
<br />
{{PARAMNAMEDEF|Acc Zentrifugal Correction}}:<br><br />
Weight of the centrifugal acceleration in determining the weight of the accelerometer data in the attitude estimation. Effective only when {{PARAMNAME|Acc Compensation Method}} = {{PARAMVALUE|advanced}}.<br />
<br />
{{PARAMNAMEDEF|Acc Recover Time}}:<br><br />
Fall time for recovering from a reduced weight of the accelerometer data in the attitude estimation. The rise time is determined implicitly by the {{PARAMNAME|Acc LPF}} parameter value. Effective only when {{PARAMNAME|Acc Compensation Method}} = {{PARAMVALUE|advanced}}.<br />
--></div>OlliWhttp://www.olliw.eu/storm32bgc-v2-wiki/index.php?title=STorM32_Parameters&diff=11915STorM32 Parameters2025-11-30T10:40:20Z<p>OlliW: /* PID Tab */</p>
<hr />
<div><span style="font-size:88%">''The information on this page refers to firmware v2.72e.''</span><br />
<br />
List of all STorM32 parameters, and some GUI features, with brief explanations and/or links to more comprehensive articles.<br />
<br />
{{COMMENT|The parameters are displayed and enabled in the GUI depending on whether the STorM32 gimbal is in "'''Conventional Mode'''" or "'''T-STorM32 Mode'''". The active mode can be inferred from the GUI's title, and is updated to the correct current mode upon a connection to a STorM32 controller.}}<br />
<br />
<div class="toclimit-2">__TOC__</div><br />
<br />
== Dashboard Tab ==<br />
<br />
{{GUIFIELD|Change Name}}:<br><br />
Opens a dialog, which allows you to change the name of the board.<br />
<br />
{{GUIFIELD|Share Settings}}:<br><br />
Opens a dialog, which presents all parameters comprehensively. Taking a screen shot by pressing one of the "Save Screenshot" buttons provides a useful method for sharing parameter settings.<br />
<br />
{{GUIFIELD|Check for Updates}}:<br><br />
Opens a dialog, which connects to the STorM32 github repository to check if a new firmware is available.<br />
<br />
== PID Tab ==<br />
<br />
=== In Conventional Mode: ===<br />
<br />
{{PARAMNAMEDEF|Gyro LPF}}: <br> Digital low pass filter applied to the raw gyro data. Can help to avoid vibrations and/or reach higher PID values. Values relate to the time constant of the filter.<br />
<br />
{{PARAMNAMEDEF|Imu2 FeedForward LPF}}: <br> Digital low pass filter applied to the attitude data of the 2nd IMU before it enters the feedforward channel in the PID controller. Effective only when the 2nd IMU is enabled, i.e., when {{PARAMNAME|Imu2 Configuration}} is not {{PARAMVALUE|off}}. Values relate to the time constant of the filter.<br />
<br />
{{PARAMNAMEDEF|Pitch P}}, {{PARAMNAMEDEF|Roll P}}, {{PARAMNAMEDEF|Yaw P}}: <br> Proportional term of the PID controller for the pitch, roll or yaw axis, respectively. See also [[Tuning_Recipe#Tuning_Procedure|Tuning Recipe: Tuning Procedure]].<br />
<br />
{{PARAMNAMEDEF|Pitch I}}, {{PARAMNAMEDEF|Roll I}}, {{PARAMNAMEDEF|Yaw I}}: <br> Integral term of the PID controller for the pitch, roll or yaw axis, respectively. See also [[Tuning_Recipe#Tuning_Procedure|Tuning Recipe: Tuning Procedure]].<br />
<br />
{{PARAMNAMEDEF|Pitch D}}, {{PARAMNAMEDEF|Roll D}}, {{PARAMNAMEDEF|Yaw D}}: <br> Derivative term of the PID controller for the pitch, roll or yaw axis, respectively. See also [[Tuning_Recipe#Tuning_Procedure|Tuning Recipe: Tuning Procedure]].<br />
<br />
{{PARAMNAMEDEF|Pitch Motor Vmax}}, {{PARAMNAMEDEF|Roll Motor Vmax}}, {{PARAMNAMEDEF|Yaw Motor Vmax}}: <br> Maximal average voltage for the pitch, roll or yaw motor, respectively. Range is 0 - 255. See also [[Tuning_Recipe#Setting_Motor_Vmax|Tuning Recipe: Setting Motor Vmax]].<br />
<br />
{{PARAMNAMEDEF|Voltage Correction}}: <br> Attempts to compensate the effects of a (slowly) varying battery voltage on the PID controller tuning, see [[Advanced_Functions#Voltage_Correction|Advanced Functions: Voltage Correction]].<br />
<br />
{{PARAMNAMEDEF|Controller}}: <br> Enables the model-based controller. The settings {{PARAMVALUE|default}} and {{PARAMVALUE|roll mixing}} are available, where the first corresponds to the "old" behavior, and the second enables improved roll mixing.<br />
<br />
{{GUIFIELD|Use simplified PID tuning}}: <br> Toggles between the standard PID tuning, in which the P, I D values are adjusted, and a simplified mechanism, in which tuning is achieved by only two parameters, called Damping and Stability.<br />
<br />
=== In T-STorM32 Mode: ===<br />
<br />
{{PARAMNAMEDEF|Foc Gyro LPF}}: <br> Digital low pass filter applied to the raw gyro data. Can help to avoid vibrations and/or reach higher PID values. Values relate to the time constant of the filter.<br />
<br />
{{PARAMNAMEDEF|Foc Pitch P}}, {{PARAMNAMEDEF|Foc Roll P}}, {{PARAMNAMEDEF|Foc Yaw P}}: <br> Proportional term of the PID controller for the pitch, roll or yaw axis, respectively.<br />
<br />
{{PARAMNAMEDEF|Foc Pitch I}}, {{PARAMNAMEDEF|Foc Roll I}}, {{PARAMNAMEDEF|Foc Yaw I}}: <br> Integral term of the PID controller for the pitch, roll or yaw axis, respectively.<br />
<br />
{{PARAMNAMEDEF|Foc Pitch D}}, {{PARAMNAMEDEF|Foc Roll D}}, {{PARAMNAMEDEF|Foc Yaw D}}: <br> Derivative term of the PID controller for the pitch, roll or yaw axis, respectively.<br />
<br />
{{PARAMNAMEDEF|Foc Pitch K}}, {{PARAMNAMEDEF|Foc Roll K}}, {{PARAMNAMEDEF|Foc Yaw K}}: <br> Factor which multiplies the P, I, and D values.<br />
<br />
{{PARAMNAMEDEF|Foc Controller}}: <br> Enables the model-based controller. The setting {{PARAMVALUE|default}} corresponds to the "old" behavior.<br />
<br />
=== All Modes: ===<br />
<br />
{{PARAMNAMEDEF|D Source}}: <br> The settings “default” and “gyro” are available. "gyro" enables the "new" lag-free and lower-noise controller D-term calculation. This setting is enabled per default. "default" enables the "old" method of D-term calculation. This parameter may be removed in upcoming firmwares.<br />
<br />
{{GUIFIELD|Auto write PID changes}}:<br><br />
When checked, any change to the PID values (and only to the PID values) is written to the STorM32 board after ca. 1 sec.<br />
<br />
== Pan Tab ==<br />
<br />
The parameters in the {{GUI|Pan}} tab are comprehensively described in the article [[Hold_versus_Pan_Mode|Hold versus pan Mode]].<br />
<br />
{{PARAMNAMEDEF|Pan Mode Control}}: <br> Selects the input channel used for changing the pan mode. <br />
<br />
{{PARAMNAMEDEF|Pan Mode Default Setting}}, {{PARAMNAMEDEF|Pan Mode Setting #1}}, {{PARAMNAMEDEF|Pan Mode Setting #2}}, {{PARAMNAMEDEF|Pan Mode Setting #3}}: <br><br />
Selects the pan states for each axis, for each of the four possible states of the input channel.<br />
<br />
{{PARAMNAMEDEF|Pitch Pan}}, {{PARAMNAMEDEF|Roll Pan}}, {{PARAMNAMEDEF|Yaw Pan}}: <br><br />
Sets the pan speed for pitch, roll and yaw, respectively.<br />
<br />
{{PARAMNAMEDEF|Pitch Pan Deadband}}, {{PARAMNAMEDEF|Roll Pan Deadband}}, {{PARAMNAMEDEF|Yaw Pan Deadband}}:<br><br />
Sets the pan deadband for pitch, roll and yaw, respectively.<br />
<br />
{{PARAMNAMEDEF|Pitch Pan Expo}}, {{PARAMNAMEDEF|Roll Pan Expo}}, {{PARAMNAMEDEF|Yaw Pan Expo}}: <br><br />
Sets the pan expo for pitch, roll and yaw, respectively.<br />
<br />
{{PARAMNAMEDEF|Pitch Pan Method}}, {{PARAMNAMEDEF|Roll Pan Method}}: <br><br />
Sets the pan method for pitch and roll, respectively. Can be "normal" or "plane". <br />
<br />
{{PARAMNAMEDEF|Yaw Pan Deadband LPF}}: <br><br />
Sets the pan deadband low-pass filter for the yaw axis.<br />
<br />
== Rc Inputs Tab ==<br />
<br />
The parameters in the {{GUI|Rc Inputs}} tab are comprehensively described in the article [[Configure_the_RC_Input|Configure the RC Input]].<br />
<br />
{{PARAMNAMEDEF|Rc Dead Band}}: <br> Sets a deadband around zero input, to suppress noise on the input. Effective for all three axes.<br />
<br />
{{PARAMNAMEDEF|Rc Hysteresis}}: <br> Sets a hysteresis to value changes, to suppress noise on the input. Effective for all three axes.<br />
<br />
{{PARAMNAMEDEF|Rc Pitch Trim}}, {{PARAMNAMEDEF|Rc Roll Trim}}, {{PARAMNAMEDEF|Rc Yaw Trim}}: <br> Sets the mid position for teh pitch, roll and yaw axis, respectively. <br />
<br />
{{PARAMNAMEDEF|Rc Pitch}}, {{PARAMNAMEDEF|Rc Roll}}, {{PARAMNAMEDEF|Rc Yaw}}: <br> Selects the input channel used for controlling the pitch, roll, and yaw axis, respectively.<br />
<br />
{{PARAMNAMEDEF|Rc Pitch Mode}}, {{PARAMNAMEDEF|Rc Roll Mode}}, {{PARAMNAMEDEF|Rc Yaw Mode}}: <br> Sets the mode for the pitch, roll, and yaw axis, respectively.<br />
<br />
{{PARAMNAMEDEF|Rc Pitch Min}}, {{PARAMNAMEDEF|Rc Roll Min}}, {{PARAMNAMEDEF|Rc Yaw Min}}: <br> Sets the minimum angle for the pitch, roll, and yaw axis, respectively.<br />
<br />
{{PARAMNAMEDEF|Rc Pitch Max}}, {{PARAMNAMEDEF|Rc Roll Max}}, {{PARAMNAMEDEF|Rc Yaw Max}}: <br> Sets the maximum angle for the pitch, roll, and yaw axis, respectively.<br />
<br />
{{PARAMNAMEDEF|Rc Pitch Speed Limit}}, {{PARAMNAMEDEF|Rc Roll Speed Limit}}, {{PARAMNAMEDEF|Rc Yaw Speed Limit}}: <br> Sets the maximum speed for the pitch, roll, and yaw axis, respectively. A value of 0 disables the speed limiter (it is not fully deactivated, the speed limit is set to 100 deg/s).<br />
<br />
{{PARAMNAMEDEF|Rc Pitch Accel Limit}}, {{PARAMNAMEDEF|Rc Roll Accel Limit}}, {{PARAMNAMEDEF|Rc Yaw Accel Limit}}: <br> Sets the maximum acceleration for the pitch, roll, and yaw axis, respectively. A value of 0 disables the acceleration limiter (it is not fully deactivated, a small limit remains).<br />
<br />
{{PARAMNAMEDEF|Rc Pitch Expo}}, {{PARAMNAMEDEF|Rc Roll Expo}}, {{PARAMNAMEDEF|Rc Yaw Expo}}: <br> Sets the expo for the pitch, roll, and yaw axis, respectively.<br />
<br />
{{GUIFIELD|Auto Trim}}:<br> Reads the current input values and adjusts the trim values such as to make them zero.<br />
<br />
== Functions Tab ==<br />
<br />
{{PARAMNAMEDEF|Re-center Camera}}, {{PARAMNAMEDEF|Re-center Camera Axes}}, {{PARAMNAMEDEF|Re-center Camera Mode}}: <br> See [[Advanced_Functions#Re-center_Camera|Advanced Functions: Re-center Camera]].<br />
<br />
{{PARAMNAMEDEF|Retract}}: <br> Puts the gimbal in retract mode.<br />
<br />
{{PARAMNAMEDEF|Standby}}: <br> See [[Advanced_Functions#Standby|Advanced Functions: Standby]].<br />
<br />
{{PARAMNAMEDEF|Camera Control}}, {{PARAMNAMEDEF|Camera Control2}}, {{PARAMNAMEDEF|Camera Model}}, {{PARAMNAMEDEF|Camera Control Mode}}, {{PARAMNAMEDEF|Time Interval}}, {{PARAMNAMEDEF|Camera ComPort}}: <br> See [[Advanced_Functions#Camera_Remote_Control|Advanced Functions: Camera Remote Control]].<br />
<br />
{{PARAMNAMEDEF|Pwm Out Control}}, {{PARAMNAMEDEF|Pwm Out Mid}}, {{PARAMNAMEDEF|Pwm Out Min}}, {{PARAMNAMEDEF|Pwm Out Max}}, {{PARAMNAMEDEF|Pwm Out Speed Limit}}: <br> See [[Advanced_Functions#Pwm_Out|Advanced Functions: Pwm Out]].<br />
<br />
== Scripts Tab ==<br />
<br />
The parameters in the {{GUI|Scripts}} tab are comprehensively described in the article [[STorM32_Scripts|STorM32 Scripts]].<br />
<br />
== Setup Tab ==<br />
<br />
=== In Conventional Mode: ===<br />
<br />
{{PARAMNAMEDEF|Imu2 Configuration}}: <br><br />
Selects how a 2nd IMU is used. See also [[Using a 2nd IMU]].<br />
<br />
{{PARAMNAMEDEF|Startup Mode}}: <br><br />
Selects the startup algorithm. Can be set to {{PARAMVALUE|fast}} for invoking fast startup. For fast startup to be activated, additional conditions have to be met: IMU2 must be present, the motor directions and positions must have been configured, and IMU1 and IMU2 must have be calibrated. The gimbal should also have been tuned.<br />
<br />
=== All Modes: ===<br />
<br />
{{PARAMNAMEDEF|Startup Delay}}: <br><br />
Sets a startup delay time.<br />
<br />
{{PARAMNAMEDEF|Prearm Checks}}: <br><br />
Bitmask to enable various pre-arming checks, i.e., conditions which need to be fulfilled before the STroM32 goes into NORMAL mode. <br />
<br />
{{PARAMNAMEDEF|Virtual Channel Configuration}}: <br><br />
Selects the physical source for the {{PARAMVALUE|Virtual-1}}, ..., {{PARAMVALUE|Virtual-16}} input values. See [[Inputs and Functions]] for understanding the STorM32's concept of inputs, and [[Configure_the_RC_Input#Wiring_for_SUM-PPM_Signals|Configure the RC Input: Wiring for SUM-PPM Signals]] and [[Configure_the_RC_Input#Wiring_for_Digital_Signals|Configure the RC Input: Wiring for Digital Signals]] for typical use cases.<br />
<br />
{{PARAMNAMEDEF|Pwm Out Configuration}}: <br><br />
Enables the pwm out function, see [[Advanced_Functions#Pwm_Out|Advanced Functions: Pwm Out]].<br />
<br />
{{PARAMNAMEDEF|Rc Pitch Offset}}, {{PARAMNAMEDEF|Rc Roll Offset}}, {{PARAMNAMEDEF|Rc Yaw Offset}}: <br><br />
Adds a permanent offset to the camera orientation. <br />
<br />
{{PARAMNAMEDEF|UartX Configuration}}: <br> <br />
Reconfigures the RC-0, RC-1 pins to work as UART, depending on the setting. Allows to enable the OLed display support on pin RC-1 (see [[Advanced_Functions#OLED_Display|Advanced Functions: OLED Display]]) or enables the UartX serial for the [[NT_Camera|NT Camera]].<br />
<br />
{{PARAMNAMEDEF|Low Voltage Limit}}: <br> Voltage level at which the lipo-saver function is triggered, see [[Advanced_Functions#Lipo_Saver|Advanced Functions: Lipo Saver]]. <br />
<br />
{{PARAMNAMEDEF|Beep with Motors}}: <br><br />
Enables the emission of beeps by the motors, see [[Advanced_Functions#Beeps|Advanced Functions: Beeps]].<br />
<br />
{{PARAMNAMEDEF|NT Logging}}:<br><br />
Adjusts which parameters are logged, see [[NT_Data_Logging#GUI_Settings|NT Data Logging: GUI Settings]].<br />
<br />
{{PARAMNAMEDEF|Pitch Motor Usage}}, {{PARAMNAMEDEF|Roll Motor Usage}}, {{PARAMNAMEDEF|Yaw Motor Usage}}: <br><br />
Selects the operation mode of the pitch, roll, or yaw motor, respectively. When {{PARAMVALUE|disabled}} is selected, the motor does not receive any power.<br />
<br />
== Gimbal Configuration Tab ==<br />
<br />
=== In Conventional Mode: ===<br />
<br />
{{PARAMNAMEDEF|Pitch Motor Poles}}, {{PARAMNAMEDEF|Roll Motor Poles}}, {{PARAMNAMEDEF|Yaw Motor Poles}}:<br><br />
Number of magnet poles of the pitch, roll or yaw motor, respectively. Range is 8 - 42.<br />
<br />
{{PARAMNAMEDEF|Pitch Motor Direction}}, {{PARAMNAMEDEF|Roll Motor Direction}}, {{PARAMNAMEDEF|Yaw Motor Direction}}:<br><br />
Rotation direction of the pitch, roll or yaw motor, respectively. <br />
<br />
{{PARAMNAMEDEF|Pitch Startup Motor Pos}}, {{PARAMNAMEDEF|Roll Startup Motor Pos}}, {{PARAMNAMEDEF|Yaw Startup Motor Pos}}:<br><br />
Orientation of the pitch, roll or yaw motor at power up, respectively.<br />
<br />
=== In T-STorM32 Mode: ===<br />
<br />
{{PARAMNAMEDEF|Foc Pitch Motor Direction}}, {{PARAMNAMEDEF|Foc Roll Motor Direction}}, {{PARAMNAMEDEF|Foc Yaw Motor Direction}}:<br><br />
Rotation direction of the pitch, roll or yaw motor, respectively. <br />
<br />
{{PARAMNAMEDEF|Foc Pitch Zero Pos}}, {{PARAMNAMEDEF|Foc Roll Zero Pos}}, {{PARAMNAMEDEF|Foc Yaw Zero Pos}}:<br><br />
Motor position at zero Imu angle for the pitch, roll or yaw axis, respectively.<br />
<br />
=== All Modes: ===<br />
<br />
{{PARAMNAMEDEF|Imu Orientation}}, {{PARAMNAMEDEF|Imu2 Orientation}}:<br><br />
Orientation number of the IMU1 or IMU2, respectively. <br />
<br />
{{PARAMNAMEDEF|Pitch Offset}}, {{PARAMNAMEDEF|Roll Offset}}, {{PARAMNAMEDEF|Yaw Offset}}:<br><br />
Coefficients to correct for slight inaccuracies in the calibration of the IMU1 accelerometer.<br />
<br />
== Interfaces Tool Window ==<br />
<br />
{{PARAMNAMEDEF|Mavlink Gimbal}}, {{PARAMNAMEDEF|Mavlink Gimbal Stream}}, {{PARAMNAMEDEF|Mavlink ComPort}}, {{PARAMNAMEDEF|Mavlink System ID}}, {{PARAMNAMEDEF|Mavlink Camera}}:<br><br />
Parameters for handling Mavlink messages, see [[MAVLink Communication]].<br />
<br />
{{PARAMNAMEDEF|STorM32Link Configuration}}<!--, {{PARAMNAMEDEF|STorM32Link AHRS Factor}}-->:<br><br />
Parameters for handling the [[STorM32-Link|STorM32 Link]]. The setting {{PARAMNAMEDEF|STorM32Link Configuration}} = {{PARAMVALUE|yaw drift comp.}} enables the yaw drift compensation, but not horizon drift compensation. The setting {{PARAMNAMEDEF|STorM32Link Configuration}} = {{PARAMVALUE|v1}} enables both the yaw drift compensation and horizon drift compensation. For further info on the STorM32-Link see the article [[STorM32-Link]].<br />
<br />
{{PARAMNAMEDEF|Uart Baudrate}}, {{PARAMNAMEDEF|Uart2 Baudrate}}, {{PARAMNAMEDEF|Usb Baudrate}}:<br><br />
Baudrates used for the UART, USB, and UART2 ports. The default baudrates are 115200 bps.<br />
<br />
== Expert Tool Window ==<br />
<br />
=== In Conventional Mode: ===<br />
<br />
{{PARAMNAMEDEF|Motor Mapping}}:<br><br />
Allows us to change the assignment of the pitch, roll and yaw motors to the ports MOT0, MOT1, MOT2. The default assignment is pitch = MOT0, roll = MOT1, yaw = MOT2.<br />
<br />
{{PARAMNAMEDEF|Imu2 Rotation}}: <br><br />
Allows us to configure for different mounting options of the 2nd IMU. See also [[Using a 2nd IMU]].<br />
<br />
{{PARAMNAMEDEF|Flip Gimbal Control}}: <br><br />
Allows us to use an input signal to switch the configuration of the gimbal between "down-hanging" and "up-standing".<br />
<br />
=== All Modes: ===<br />
<br />
{{PARAMNAMEDEF|Imu Mapping}}: <br><br />
Allows us to swap IMU1 and IMU2 (this swaps NT IMU1 and NT IMU2, not the on-board IMU, which always will be IMU2 if used) .<br />
<br />
{{PARAMNAMEDEF|Lipo Cells}}: <br><br />
Sets the number of cells of the battery. Default is {{PARAMVALUE|auto}}, which determines the number of cells from the battery voltage at power up.<br />
<br />
{{PARAMNAMEDEF|Lipo Voltage per Cell}}: <br><br />
Full charge voltage of a battery cell. Default is 4.20 V, appropriate for a LIPO.<br />
<br />
{{PARAMNAMEDEF|ADC Calibration}}: <br><br />
Calibration constant for voltage measurement. The default value {{PARAMVALUE|1550}} is slightly below the theoretically correct value of 1581.<br />
<br />
{{PARAMNAMEDEF|Imu AHRS}}: <br><br />
Adjusts how strongly the accelerometer data are included in the data fusing for the attitude estimation. The shorter the time the stronger the accelerometer data are weighted (0 = accelerometer only, 20 = gyro only).<br />
<br />
{{PARAMNAMEDEF|Startup Gyro Calibration}}: <br><br />
Sets the gyro calibration at startup. Default is {{PARAMVALUE|normal}}.<br />
<br />
==== The following parameters should be set with care. Normally, there should be no reason to modify them. ====<br />
<br />
{{PARAMNAMEDEF|Acc LPF}}: <br> <br />
Digital low pass filter applied to the raw accelerometer data. It also affects the behavior of the AHRS.<br />
<br />
{{PARAMNAMEDEF|Rc Adc LPF}}: <br> <br />
Digital low pass filter applied to the Rc Input values. Might be helpful for very noisy RC transmitters.<br />
<br />
{{PARAMNAMEDEF|Pan Hold Transition Time}}, {{PARAMNAMEDEF|Pan Speed Limit}}, {{PARAMNAMEDEF|Pan Accel Limit}}: <br><br />
These parameters are related to the pan-to-hold and hold-to-pan transition behavior. The parameter {{PARAMNAMEDEF|Pan Hold Transition Time}} determines for how long a trajectory filter is applied to smooth the transition. The two limit parameters determine the speed and acceleration limits of the trajectory filter.<br />
<br />
{{PARAMNAMEDEF|Foc Emergency}}: <br> <br />
Sets the level of the emergency detection mechanism.<br />
<br />
{{PARAMNAMEDEF|Acc Compensation Method}}:<br><br />
Selects the algorithm which is used for fusing the accelerometer and gyro data. Can be {{PARAMVALUE|standard}} or {{PARAMVALUE|advanced}}. The parameter affects the AHRS, and should be set with understanding. These posts might be useful: [http://www.rcgroups.com/forums/showthread.php?t=2055844&page=27&pp=50#post29173129], [http://www.rcgroups.com/forums/showthread.php?t=2055844&page=27&pp=50#post29176384], [http://www.rcgroups.com/forums/showthread.php?t=2055844&page=27&pp=50#post29176832].<br />
<br />
== Gimbal Model Tool Window ==<br />
<br />
The parameters in the {{GUI|Gimbal Model}} tab are comprehensively described in the article [[Model-based_Control|Model-based Control]].<br />
<br />
=== In T-STorM32 Mode: ===<br />
<br />
{{PARAMNAMEDEF|T1 Pitch}}, {{PARAMNAMEDEF|T1 Roll}}, {{PARAMNAMEDEF|T1 Yaw}}:<br><br />
Relative moments of inertia of the camera along the pitch, roll and yaw directions.<br />
<br />
{{PARAMNAMEDEF|T2 Roll}}, {{PARAMNAMEDEF|T2 Yaw}}:<br><br />
Relative moments of inertia of the roll arm along the roll and yaw directions.<br />
<br />
== Gimbal Mechanics Tool Window ==<br />
<br />
The parameters in the {{GUI|Gimbal Mechanics}} tab allow to set mechanical gimbal limits. They are experimental.<br />
<br />
=== All Modes: ===<br />
<br />
{{PARAMNAMEDEF|Yaw Motor Limit}}:<br> Limit for yaw axis.<br />
<br />
{{PARAMNAMEDEF|Setpoint Speed Limit}}, {{PARAMNAMEDEF|Setpoint Accel Limit}}:<br> Speed and acceleration limits for changes of the setpoint.<br />
<br />
=== In T-STorM32 Mode: ===<br />
<br />
{{PARAMNAMEDEF|Pitch Motor Limit Min}}, {{PARAMNAMEDEF|Pitch Motor Limit Max}}, {{PARAMNAMEDEF|Roll Motor Limit}}:<br> Limits for pitch and roll axes.<br />
<br />
== Servo Tool Window ==<br />
<br />
=== In T-STorM32 Mode: ===<br />
<br />
{{PARAMNAMEDEF|Servo Pitch P}}, {{PARAMNAMEDEF|Servo Pitch I}}, {{PARAMNAMEDEF|Servo Pitch D}}, {{PARAMNAMEDEF|Servo Pitch DLPF}}:<br><br />
Parameters for the position PID controller in servo mode for the pitch axis.<br />
<br />
{{PARAMNAMEDEF|Servo Roll P}}, {{PARAMNAMEDEF|Servo Roll I}}, {{PARAMNAMEDEF|Servo Roll D}}, {{PARAMNAMEDEF|Servo Roll DLPF}}:<br><br />
Parameters for the position PID controller in servo mode for the roll axis.<br />
<br />
{{PARAMNAMEDEF|Servo Yaw P}}, {{PARAMNAMEDEF|Servo Yaw I}}, {{PARAMNAMEDEF|Servo Yaw D}}, {{PARAMNAMEDEF|Servo Yaw DLPF}}:<br><br />
Parameters for the position PID controller in servo mode for the yaw axis.<br />
<!--<br />
{{PARAMNAMEDEF|Imu Acc Threshold}}:<br><br />
Maximal residual acceleration up to which the accelerometer data are taken into account in the attitude estimation. This parameter is effective only when {{PARAMNAME|Acc Compensation Method}} is set to {{PARAMVALUE|standard}}.<br />
<br />
{{PARAMNAMEDEF|Acc Noise Level}}:<br><br />
Residual acceleration up to which the accelerometer data are taken into account with maximal weight in the attitude estimation. Effective only when {{PARAMNAME|Acc Compensation Method}} = {{PARAMVALUE|advanced}}.<br />
<br />
{{PARAMNAMEDEF|Acc Threshold}}:<br><br />
Maximal residual acceleration up to which the accelerometer data are taken into account in the attitude estimation with non-zero weight. Effective only when {{PARAMNAME|Acc Compensation Method}} = {{PARAMVALUE|advanced}}.<br />
<br />
{{PARAMNAMEDEF|Acc Vertical Weight}}:<br><br />
Weight of the vertical residual acceleration in determining the weight of the accelerometer data in the attitude estimation. Effective only when {{PARAMNAME|Acc Compensation Method}} = {{PARAMVALUE|advanced}}.<br />
<br />
{{PARAMNAMEDEF|Acc Zentrifugal Correction}}:<br><br />
Weight of the centrifugal acceleration in determining the weight of the accelerometer data in the attitude estimation. Effective only when {{PARAMNAME|Acc Compensation Method}} = {{PARAMVALUE|advanced}}.<br />
<br />
{{PARAMNAMEDEF|Acc Recover Time}}:<br><br />
Fall time for recovering from a reduced weight of the accelerometer data in the attitude estimation. The rise time is determined implicitly by the {{PARAMNAME|Acc LPF}} parameter value. Effective only when {{PARAMNAME|Acc Compensation Method}} = {{PARAMVALUE|advanced}}.<br />
--></div>OlliWhttp://www.olliw.eu/storm32bgc-v2-wiki/index.php?title=STorM32_Parameters&diff=11914STorM32 Parameters2025-11-30T10:40:02Z<p>OlliW: /* In Conventional Mode: */</p>
<hr />
<div><span style="font-size:88%">''The information on this page refers to firmware v2.72e.''</span><br />
<br />
List of all STorM32 parameters, and some GUI features, with brief explanations and/or links to more comprehensive articles.<br />
<br />
{{COMMENT|The parameters are displayed and enabled in the GUI depending on whether the STorM32 gimbal is in "'''Conventional Mode'''" or "'''T-STorM32 Mode'''". The active mode can be inferred from the GUI's title, and is updated to the correct current mode upon a connection to a STorM32 controller.}}<br />
<br />
<div class="toclimit-2">__TOC__</div><br />
<br />
== Dashboard Tab ==<br />
<br />
{{GUIFIELD|Change Name}}:<br><br />
Opens a dialog, which allows you to change the name of the board.<br />
<br />
{{GUIFIELD|Share Settings}}:<br><br />
Opens a dialog, which presents all parameters comprehensively. Taking a screen shot by pressing one of the "Save Screenshot" buttons provides a useful method for sharing parameter settings.<br />
<br />
{{GUIFIELD|Check for Updates}}:<br><br />
Opens a dialog, which connects to the STorM32 github repository to check if a new firmware is available.<br />
<br />
== PID Tab ==<br />
<br />
=== In Conventional Mode: ===<br />
<br />
{{PARAMNAMEDEF|Gyro LPF}}: <br> Digital low pass filter applied to the raw gyro data. Can help to avoid vibrations and/or reach higher PID values. Values relate to the time constant of the filter.<br />
<br />
{{PARAMNAMEDEF|Imu2 FeedForward LPF}}: <br> Digital low pass filter applied to the attitude data of the 2nd IMU before it enters the feedforward channel in the PID controller. Effective only when the 2nd IMU is enabled, i.e., when {{PARAMNAME|Imu2 Configuration}} is not {{PARAMVALUE|off}}. Values relate to the time constant of the filter.<br />
<br />
{{PARAMNAMEDEF|Pitch P}}, {{PARAMNAMEDEF|Roll P}}, {{PARAMNAMEDEF|Yaw P}}: <br> Proportional term of the PID controller for the pitch, roll or yaw axis, respectively. See also [[Tuning_Recipe#Tuning_Procedure|Tuning Recipe: Tuning Procedure]].<br />
<br />
{{PARAMNAMEDEF|Pitch I}}, {{PARAMNAMEDEF|Roll I}}, {{PARAMNAMEDEF|Yaw I}}: <br> Integral term of the PID controller for the pitch, roll or yaw axis, respectively. See also [[Tuning_Recipe#Tuning_Procedure|Tuning Recipe: Tuning Procedure]].<br />
<br />
{{PARAMNAMEDEF|Pitch D}}, {{PARAMNAMEDEF|Roll D}}, {{PARAMNAMEDEF|Yaw D}}: <br> Derivative term of the PID controller for the pitch, roll or yaw axis, respectively. See also [[Tuning_Recipe#Tuning_Procedure|Tuning Recipe: Tuning Procedure]].<br />
<br />
{{PARAMNAMEDEF|Pitch Motor Vmax}}, {{PARAMNAMEDEF|Roll Motor Vmax}}, {{PARAMNAMEDEF|Yaw Motor Vmax}}: <br> Maximal average voltage for the pitch, roll or yaw motor, respectively. Range is 0 - 255. See also [[Tuning_Recipe#Setting_Motor_Vmax|Tuning Recipe: Setting Motor Vmax]].<br />
<br />
{{PARAMNAMEDEF|Voltage Correction}}: <br> Attempts to compensate the effects of a (slowly) varying battery voltage on the PID controller tuning, see [[Advanced_Functions#Voltage_Correction|Advanced Functions: Voltage Correction]].<br />
<br />
{{PARAMNAMEDEF|Controller}}: <br> Enables the model-based controller. The settings {{PARAMVALUE|default}} and {{PARAMVALUE|roll mixing}} are available, where the first corresponds to the "old" behavior, and the second enables improved roll mixing.<br />
<br />
{{PARAMNAMEDEF|D Source}}: <br> Appears to not make a difference.<br />
<br />
{{GUIFIELD|Use simplified PID tuning}}: <br> Toggles between the standard PID tuning, in which the P, I D values are adjusted, and a simplified mechanism, in which tuning is achieved by only two parameters, called Damping and Stability.<br />
<br />
=== In T-STorM32 Mode: ===<br />
<br />
{{PARAMNAMEDEF|Foc Gyro LPF}}: <br> Digital low pass filter applied to the raw gyro data. Can help to avoid vibrations and/or reach higher PID values. Values relate to the time constant of the filter.<br />
<br />
{{PARAMNAMEDEF|Foc Pitch P}}, {{PARAMNAMEDEF|Foc Roll P}}, {{PARAMNAMEDEF|Foc Yaw P}}: <br> Proportional term of the PID controller for the pitch, roll or yaw axis, respectively.<br />
<br />
{{PARAMNAMEDEF|Foc Pitch I}}, {{PARAMNAMEDEF|Foc Roll I}}, {{PARAMNAMEDEF|Foc Yaw I}}: <br> Integral term of the PID controller for the pitch, roll or yaw axis, respectively.<br />
<br />
{{PARAMNAMEDEF|Foc Pitch D}}, {{PARAMNAMEDEF|Foc Roll D}}, {{PARAMNAMEDEF|Foc Yaw D}}: <br> Derivative term of the PID controller for the pitch, roll or yaw axis, respectively.<br />
<br />
{{PARAMNAMEDEF|Foc Pitch K}}, {{PARAMNAMEDEF|Foc Roll K}}, {{PARAMNAMEDEF|Foc Yaw K}}: <br> Factor which multiplies the P, I, and D values.<br />
<br />
{{PARAMNAMEDEF|Foc Controller}}: <br> Enables the model-based controller. The setting {{PARAMVALUE|default}} corresponds to the "old" behavior.<br />
<br />
=== All Modes: ===<br />
<br />
{{PARAMNAMEDEF|D Source}}: <br> The settings “default” and “gyro” are available. "gyro" enables the "new" lag-free and lower-noise controller D-term calculation. This setting is enabled per default. "default" enables the "old" method of D-term calculation. This parameter may be removed in upcoming firmwares.<br />
<br />
{{GUIFIELD|Auto write PID changes}}:<br><br />
When checked, any change to the PID values (and only to the PID values) is written to the STorM32 board after ca. 1 sec.<br />
<br />
== Pan Tab ==<br />
<br />
The parameters in the {{GUI|Pan}} tab are comprehensively described in the article [[Hold_versus_Pan_Mode|Hold versus pan Mode]].<br />
<br />
{{PARAMNAMEDEF|Pan Mode Control}}: <br> Selects the input channel used for changing the pan mode. <br />
<br />
{{PARAMNAMEDEF|Pan Mode Default Setting}}, {{PARAMNAMEDEF|Pan Mode Setting #1}}, {{PARAMNAMEDEF|Pan Mode Setting #2}}, {{PARAMNAMEDEF|Pan Mode Setting #3}}: <br><br />
Selects the pan states for each axis, for each of the four possible states of the input channel.<br />
<br />
{{PARAMNAMEDEF|Pitch Pan}}, {{PARAMNAMEDEF|Roll Pan}}, {{PARAMNAMEDEF|Yaw Pan}}: <br><br />
Sets the pan speed for pitch, roll and yaw, respectively.<br />
<br />
{{PARAMNAMEDEF|Pitch Pan Deadband}}, {{PARAMNAMEDEF|Roll Pan Deadband}}, {{PARAMNAMEDEF|Yaw Pan Deadband}}:<br><br />
Sets the pan deadband for pitch, roll and yaw, respectively.<br />
<br />
{{PARAMNAMEDEF|Pitch Pan Expo}}, {{PARAMNAMEDEF|Roll Pan Expo}}, {{PARAMNAMEDEF|Yaw Pan Expo}}: <br><br />
Sets the pan expo for pitch, roll and yaw, respectively.<br />
<br />
{{PARAMNAMEDEF|Pitch Pan Method}}, {{PARAMNAMEDEF|Roll Pan Method}}: <br><br />
Sets the pan method for pitch and roll, respectively. Can be "normal" or "plane". <br />
<br />
{{PARAMNAMEDEF|Yaw Pan Deadband LPF}}: <br><br />
Sets the pan deadband low-pass filter for the yaw axis.<br />
<br />
== Rc Inputs Tab ==<br />
<br />
The parameters in the {{GUI|Rc Inputs}} tab are comprehensively described in the article [[Configure_the_RC_Input|Configure the RC Input]].<br />
<br />
{{PARAMNAMEDEF|Rc Dead Band}}: <br> Sets a deadband around zero input, to suppress noise on the input. Effective for all three axes.<br />
<br />
{{PARAMNAMEDEF|Rc Hysteresis}}: <br> Sets a hysteresis to value changes, to suppress noise on the input. Effective for all three axes.<br />
<br />
{{PARAMNAMEDEF|Rc Pitch Trim}}, {{PARAMNAMEDEF|Rc Roll Trim}}, {{PARAMNAMEDEF|Rc Yaw Trim}}: <br> Sets the mid position for teh pitch, roll and yaw axis, respectively. <br />
<br />
{{PARAMNAMEDEF|Rc Pitch}}, {{PARAMNAMEDEF|Rc Roll}}, {{PARAMNAMEDEF|Rc Yaw}}: <br> Selects the input channel used for controlling the pitch, roll, and yaw axis, respectively.<br />
<br />
{{PARAMNAMEDEF|Rc Pitch Mode}}, {{PARAMNAMEDEF|Rc Roll Mode}}, {{PARAMNAMEDEF|Rc Yaw Mode}}: <br> Sets the mode for the pitch, roll, and yaw axis, respectively.<br />
<br />
{{PARAMNAMEDEF|Rc Pitch Min}}, {{PARAMNAMEDEF|Rc Roll Min}}, {{PARAMNAMEDEF|Rc Yaw Min}}: <br> Sets the minimum angle for the pitch, roll, and yaw axis, respectively.<br />
<br />
{{PARAMNAMEDEF|Rc Pitch Max}}, {{PARAMNAMEDEF|Rc Roll Max}}, {{PARAMNAMEDEF|Rc Yaw Max}}: <br> Sets the maximum angle for the pitch, roll, and yaw axis, respectively.<br />
<br />
{{PARAMNAMEDEF|Rc Pitch Speed Limit}}, {{PARAMNAMEDEF|Rc Roll Speed Limit}}, {{PARAMNAMEDEF|Rc Yaw Speed Limit}}: <br> Sets the maximum speed for the pitch, roll, and yaw axis, respectively. A value of 0 disables the speed limiter (it is not fully deactivated, the speed limit is set to 100 deg/s).<br />
<br />
{{PARAMNAMEDEF|Rc Pitch Accel Limit}}, {{PARAMNAMEDEF|Rc Roll Accel Limit}}, {{PARAMNAMEDEF|Rc Yaw Accel Limit}}: <br> Sets the maximum acceleration for the pitch, roll, and yaw axis, respectively. A value of 0 disables the acceleration limiter (it is not fully deactivated, a small limit remains).<br />
<br />
{{PARAMNAMEDEF|Rc Pitch Expo}}, {{PARAMNAMEDEF|Rc Roll Expo}}, {{PARAMNAMEDEF|Rc Yaw Expo}}: <br> Sets the expo for the pitch, roll, and yaw axis, respectively.<br />
<br />
{{GUIFIELD|Auto Trim}}:<br> Reads the current input values and adjusts the trim values such as to make them zero.<br />
<br />
== Functions Tab ==<br />
<br />
{{PARAMNAMEDEF|Re-center Camera}}, {{PARAMNAMEDEF|Re-center Camera Axes}}, {{PARAMNAMEDEF|Re-center Camera Mode}}: <br> See [[Advanced_Functions#Re-center_Camera|Advanced Functions: Re-center Camera]].<br />
<br />
{{PARAMNAMEDEF|Retract}}: <br> Puts the gimbal in retract mode.<br />
<br />
{{PARAMNAMEDEF|Standby}}: <br> See [[Advanced_Functions#Standby|Advanced Functions: Standby]].<br />
<br />
{{PARAMNAMEDEF|Camera Control}}, {{PARAMNAMEDEF|Camera Control2}}, {{PARAMNAMEDEF|Camera Model}}, {{PARAMNAMEDEF|Camera Control Mode}}, {{PARAMNAMEDEF|Time Interval}}, {{PARAMNAMEDEF|Camera ComPort}}: <br> See [[Advanced_Functions#Camera_Remote_Control|Advanced Functions: Camera Remote Control]].<br />
<br />
{{PARAMNAMEDEF|Pwm Out Control}}, {{PARAMNAMEDEF|Pwm Out Mid}}, {{PARAMNAMEDEF|Pwm Out Min}}, {{PARAMNAMEDEF|Pwm Out Max}}, {{PARAMNAMEDEF|Pwm Out Speed Limit}}: <br> See [[Advanced_Functions#Pwm_Out|Advanced Functions: Pwm Out]].<br />
<br />
== Scripts Tab ==<br />
<br />
The parameters in the {{GUI|Scripts}} tab are comprehensively described in the article [[STorM32_Scripts|STorM32 Scripts]].<br />
<br />
== Setup Tab ==<br />
<br />
=== In Conventional Mode: ===<br />
<br />
{{PARAMNAMEDEF|Imu2 Configuration}}: <br><br />
Selects how a 2nd IMU is used. See also [[Using a 2nd IMU]].<br />
<br />
{{PARAMNAMEDEF|Startup Mode}}: <br><br />
Selects the startup algorithm. Can be set to {{PARAMVALUE|fast}} for invoking fast startup. For fast startup to be activated, additional conditions have to be met: IMU2 must be present, the motor directions and positions must have been configured, and IMU1 and IMU2 must have be calibrated. The gimbal should also have been tuned.<br />
<br />
=== All Modes: ===<br />
<br />
{{PARAMNAMEDEF|Startup Delay}}: <br><br />
Sets a startup delay time.<br />
<br />
{{PARAMNAMEDEF|Prearm Checks}}: <br><br />
Bitmask to enable various pre-arming checks, i.e., conditions which need to be fulfilled before the STroM32 goes into NORMAL mode. <br />
<br />
{{PARAMNAMEDEF|Virtual Channel Configuration}}: <br><br />
Selects the physical source for the {{PARAMVALUE|Virtual-1}}, ..., {{PARAMVALUE|Virtual-16}} input values. See [[Inputs and Functions]] for understanding the STorM32's concept of inputs, and [[Configure_the_RC_Input#Wiring_for_SUM-PPM_Signals|Configure the RC Input: Wiring for SUM-PPM Signals]] and [[Configure_the_RC_Input#Wiring_for_Digital_Signals|Configure the RC Input: Wiring for Digital Signals]] for typical use cases.<br />
<br />
{{PARAMNAMEDEF|Pwm Out Configuration}}: <br><br />
Enables the pwm out function, see [[Advanced_Functions#Pwm_Out|Advanced Functions: Pwm Out]].<br />
<br />
{{PARAMNAMEDEF|Rc Pitch Offset}}, {{PARAMNAMEDEF|Rc Roll Offset}}, {{PARAMNAMEDEF|Rc Yaw Offset}}: <br><br />
Adds a permanent offset to the camera orientation. <br />
<br />
{{PARAMNAMEDEF|UartX Configuration}}: <br> <br />
Reconfigures the RC-0, RC-1 pins to work as UART, depending on the setting. Allows to enable the OLed display support on pin RC-1 (see [[Advanced_Functions#OLED_Display|Advanced Functions: OLED Display]]) or enables the UartX serial for the [[NT_Camera|NT Camera]].<br />
<br />
{{PARAMNAMEDEF|Low Voltage Limit}}: <br> Voltage level at which the lipo-saver function is triggered, see [[Advanced_Functions#Lipo_Saver|Advanced Functions: Lipo Saver]]. <br />
<br />
{{PARAMNAMEDEF|Beep with Motors}}: <br><br />
Enables the emission of beeps by the motors, see [[Advanced_Functions#Beeps|Advanced Functions: Beeps]].<br />
<br />
{{PARAMNAMEDEF|NT Logging}}:<br><br />
Adjusts which parameters are logged, see [[NT_Data_Logging#GUI_Settings|NT Data Logging: GUI Settings]].<br />
<br />
{{PARAMNAMEDEF|Pitch Motor Usage}}, {{PARAMNAMEDEF|Roll Motor Usage}}, {{PARAMNAMEDEF|Yaw Motor Usage}}: <br><br />
Selects the operation mode of the pitch, roll, or yaw motor, respectively. When {{PARAMVALUE|disabled}} is selected, the motor does not receive any power.<br />
<br />
== Gimbal Configuration Tab ==<br />
<br />
=== In Conventional Mode: ===<br />
<br />
{{PARAMNAMEDEF|Pitch Motor Poles}}, {{PARAMNAMEDEF|Roll Motor Poles}}, {{PARAMNAMEDEF|Yaw Motor Poles}}:<br><br />
Number of magnet poles of the pitch, roll or yaw motor, respectively. Range is 8 - 42.<br />
<br />
{{PARAMNAMEDEF|Pitch Motor Direction}}, {{PARAMNAMEDEF|Roll Motor Direction}}, {{PARAMNAMEDEF|Yaw Motor Direction}}:<br><br />
Rotation direction of the pitch, roll or yaw motor, respectively. <br />
<br />
{{PARAMNAMEDEF|Pitch Startup Motor Pos}}, {{PARAMNAMEDEF|Roll Startup Motor Pos}}, {{PARAMNAMEDEF|Yaw Startup Motor Pos}}:<br><br />
Orientation of the pitch, roll or yaw motor at power up, respectively.<br />
<br />
=== In T-STorM32 Mode: ===<br />
<br />
{{PARAMNAMEDEF|Foc Pitch Motor Direction}}, {{PARAMNAMEDEF|Foc Roll Motor Direction}}, {{PARAMNAMEDEF|Foc Yaw Motor Direction}}:<br><br />
Rotation direction of the pitch, roll or yaw motor, respectively. <br />
<br />
{{PARAMNAMEDEF|Foc Pitch Zero Pos}}, {{PARAMNAMEDEF|Foc Roll Zero Pos}}, {{PARAMNAMEDEF|Foc Yaw Zero Pos}}:<br><br />
Motor position at zero Imu angle for the pitch, roll or yaw axis, respectively.<br />
<br />
=== All Modes: ===<br />
<br />
{{PARAMNAMEDEF|Imu Orientation}}, {{PARAMNAMEDEF|Imu2 Orientation}}:<br><br />
Orientation number of the IMU1 or IMU2, respectively. <br />
<br />
{{PARAMNAMEDEF|Pitch Offset}}, {{PARAMNAMEDEF|Roll Offset}}, {{PARAMNAMEDEF|Yaw Offset}}:<br><br />
Coefficients to correct for slight inaccuracies in the calibration of the IMU1 accelerometer.<br />
<br />
== Interfaces Tool Window ==<br />
<br />
{{PARAMNAMEDEF|Mavlink Gimbal}}, {{PARAMNAMEDEF|Mavlink Gimbal Stream}}, {{PARAMNAMEDEF|Mavlink ComPort}}, {{PARAMNAMEDEF|Mavlink System ID}}, {{PARAMNAMEDEF|Mavlink Camera}}:<br><br />
Parameters for handling Mavlink messages, see [[MAVLink Communication]].<br />
<br />
{{PARAMNAMEDEF|STorM32Link Configuration}}<!--, {{PARAMNAMEDEF|STorM32Link AHRS Factor}}-->:<br><br />
Parameters for handling the [[STorM32-Link|STorM32 Link]]. The setting {{PARAMNAMEDEF|STorM32Link Configuration}} = {{PARAMVALUE|yaw drift comp.}} enables the yaw drift compensation, but not horizon drift compensation. The setting {{PARAMNAMEDEF|STorM32Link Configuration}} = {{PARAMVALUE|v1}} enables both the yaw drift compensation and horizon drift compensation. For further info on the STorM32-Link see the article [[STorM32-Link]].<br />
<br />
{{PARAMNAMEDEF|Uart Baudrate}}, {{PARAMNAMEDEF|Uart2 Baudrate}}, {{PARAMNAMEDEF|Usb Baudrate}}:<br><br />
Baudrates used for the UART, USB, and UART2 ports. The default baudrates are 115200 bps.<br />
<br />
== Expert Tool Window ==<br />
<br />
=== In Conventional Mode: ===<br />
<br />
{{PARAMNAMEDEF|Motor Mapping}}:<br><br />
Allows us to change the assignment of the pitch, roll and yaw motors to the ports MOT0, MOT1, MOT2. The default assignment is pitch = MOT0, roll = MOT1, yaw = MOT2.<br />
<br />
{{PARAMNAMEDEF|Imu2 Rotation}}: <br><br />
Allows us to configure for different mounting options of the 2nd IMU. See also [[Using a 2nd IMU]].<br />
<br />
{{PARAMNAMEDEF|Flip Gimbal Control}}: <br><br />
Allows us to use an input signal to switch the configuration of the gimbal between "down-hanging" and "up-standing".<br />
<br />
=== All Modes: ===<br />
<br />
{{PARAMNAMEDEF|Imu Mapping}}: <br><br />
Allows us to swap IMU1 and IMU2 (this swaps NT IMU1 and NT IMU2, not the on-board IMU, which always will be IMU2 if used) .<br />
<br />
{{PARAMNAMEDEF|Lipo Cells}}: <br><br />
Sets the number of cells of the battery. Default is {{PARAMVALUE|auto}}, which determines the number of cells from the battery voltage at power up.<br />
<br />
{{PARAMNAMEDEF|Lipo Voltage per Cell}}: <br><br />
Full charge voltage of a battery cell. Default is 4.20 V, appropriate for a LIPO.<br />
<br />
{{PARAMNAMEDEF|ADC Calibration}}: <br><br />
Calibration constant for voltage measurement. The default value {{PARAMVALUE|1550}} is slightly below the theoretically correct value of 1581.<br />
<br />
{{PARAMNAMEDEF|Imu AHRS}}: <br><br />
Adjusts how strongly the accelerometer data are included in the data fusing for the attitude estimation. The shorter the time the stronger the accelerometer data are weighted (0 = accelerometer only, 20 = gyro only).<br />
<br />
{{PARAMNAMEDEF|Startup Gyro Calibration}}: <br><br />
Sets the gyro calibration at startup. Default is {{PARAMVALUE|normal}}.<br />
<br />
==== The following parameters should be set with care. Normally, there should be no reason to modify them. ====<br />
<br />
{{PARAMNAMEDEF|Acc LPF}}: <br> <br />
Digital low pass filter applied to the raw accelerometer data. It also affects the behavior of the AHRS.<br />
<br />
{{PARAMNAMEDEF|Rc Adc LPF}}: <br> <br />
Digital low pass filter applied to the Rc Input values. Might be helpful for very noisy RC transmitters.<br />
<br />
{{PARAMNAMEDEF|Pan Hold Transition Time}}, {{PARAMNAMEDEF|Pan Speed Limit}}, {{PARAMNAMEDEF|Pan Accel Limit}}: <br><br />
These parameters are related to the pan-to-hold and hold-to-pan transition behavior. The parameter {{PARAMNAMEDEF|Pan Hold Transition Time}} determines for how long a trajectory filter is applied to smooth the transition. The two limit parameters determine the speed and acceleration limits of the trajectory filter.<br />
<br />
{{PARAMNAMEDEF|Foc Emergency}}: <br> <br />
Sets the level of the emergency detection mechanism.<br />
<br />
{{PARAMNAMEDEF|Acc Compensation Method}}:<br><br />
Selects the algorithm which is used for fusing the accelerometer and gyro data. Can be {{PARAMVALUE|standard}} or {{PARAMVALUE|advanced}}. The parameter affects the AHRS, and should be set with understanding. These posts might be useful: [http://www.rcgroups.com/forums/showthread.php?t=2055844&page=27&pp=50#post29173129], [http://www.rcgroups.com/forums/showthread.php?t=2055844&page=27&pp=50#post29176384], [http://www.rcgroups.com/forums/showthread.php?t=2055844&page=27&pp=50#post29176832].<br />
<br />
== Gimbal Model Tool Window ==<br />
<br />
The parameters in the {{GUI|Gimbal Model}} tab are comprehensively described in the article [[Model-based_Control|Model-based Control]].<br />
<br />
=== In T-STorM32 Mode: ===<br />
<br />
{{PARAMNAMEDEF|T1 Pitch}}, {{PARAMNAMEDEF|T1 Roll}}, {{PARAMNAMEDEF|T1 Yaw}}:<br><br />
Relative moments of inertia of the camera along the pitch, roll and yaw directions.<br />
<br />
{{PARAMNAMEDEF|T2 Roll}}, {{PARAMNAMEDEF|T2 Yaw}}:<br><br />
Relative moments of inertia of the roll arm along the roll and yaw directions.<br />
<br />
== Gimbal Mechanics Tool Window ==<br />
<br />
The parameters in the {{GUI|Gimbal Mechanics}} tab allow to set mechanical gimbal limits. They are experimental.<br />
<br />
=== All Modes: ===<br />
<br />
{{PARAMNAMEDEF|Yaw Motor Limit}}:<br> Limit for yaw axis.<br />
<br />
{{PARAMNAMEDEF|Setpoint Speed Limit}}, {{PARAMNAMEDEF|Setpoint Accel Limit}}:<br> Speed and acceleration limits for changes of the setpoint.<br />
<br />
=== In T-STorM32 Mode: ===<br />
<br />
{{PARAMNAMEDEF|Pitch Motor Limit Min}}, {{PARAMNAMEDEF|Pitch Motor Limit Max}}, {{PARAMNAMEDEF|Roll Motor Limit}}:<br> Limits for pitch and roll axes.<br />
<br />
== Servo Tool Window ==<br />
<br />
=== In T-STorM32 Mode: ===<br />
<br />
{{PARAMNAMEDEF|Servo Pitch P}}, {{PARAMNAMEDEF|Servo Pitch I}}, {{PARAMNAMEDEF|Servo Pitch D}}, {{PARAMNAMEDEF|Servo Pitch DLPF}}:<br><br />
Parameters for the position PID controller in servo mode for the pitch axis.<br />
<br />
{{PARAMNAMEDEF|Servo Roll P}}, {{PARAMNAMEDEF|Servo Roll I}}, {{PARAMNAMEDEF|Servo Roll D}}, {{PARAMNAMEDEF|Servo Roll DLPF}}:<br><br />
Parameters for the position PID controller in servo mode for the roll axis.<br />
<br />
{{PARAMNAMEDEF|Servo Yaw P}}, {{PARAMNAMEDEF|Servo Yaw I}}, {{PARAMNAMEDEF|Servo Yaw D}}, {{PARAMNAMEDEF|Servo Yaw DLPF}}:<br><br />
Parameters for the position PID controller in servo mode for the yaw axis.<br />
<!--<br />
{{PARAMNAMEDEF|Imu Acc Threshold}}:<br><br />
Maximal residual acceleration up to which the accelerometer data are taken into account in the attitude estimation. This parameter is effective only when {{PARAMNAME|Acc Compensation Method}} is set to {{PARAMVALUE|standard}}.<br />
<br />
{{PARAMNAMEDEF|Acc Noise Level}}:<br><br />
Residual acceleration up to which the accelerometer data are taken into account with maximal weight in the attitude estimation. Effective only when {{PARAMNAME|Acc Compensation Method}} = {{PARAMVALUE|advanced}}.<br />
<br />
{{PARAMNAMEDEF|Acc Threshold}}:<br><br />
Maximal residual acceleration up to which the accelerometer data are taken into account in the attitude estimation with non-zero weight. Effective only when {{PARAMNAME|Acc Compensation Method}} = {{PARAMVALUE|advanced}}.<br />
<br />
{{PARAMNAMEDEF|Acc Vertical Weight}}:<br><br />
Weight of the vertical residual acceleration in determining the weight of the accelerometer data in the attitude estimation. Effective only when {{PARAMNAME|Acc Compensation Method}} = {{PARAMVALUE|advanced}}.<br />
<br />
{{PARAMNAMEDEF|Acc Zentrifugal Correction}}:<br><br />
Weight of the centrifugal acceleration in determining the weight of the accelerometer data in the attitude estimation. Effective only when {{PARAMNAME|Acc Compensation Method}} = {{PARAMVALUE|advanced}}.<br />
<br />
{{PARAMNAMEDEF|Acc Recover Time}}:<br><br />
Fall time for recovering from a reduced weight of the accelerometer data in the attitude estimation. The rise time is determined implicitly by the {{PARAMNAME|Acc LPF}} parameter value. Effective only when {{PARAMNAME|Acc Compensation Method}} = {{PARAMVALUE|advanced}}.<br />
--></div>OlliWhttp://www.olliw.eu/storm32bgc-v2-wiki/index.php?title=Manuals_and_Tutorials&diff=11913Manuals and Tutorials2025-11-30T10:36:59Z<p>OlliW: </p>
<hr />
<div>{|<br />
|- valign="top"<br />
|width=300px|<br />
'''Flyers'''<br />
* [[What is STorM32 NT about?]]<br />
* [[What is T-STorM32 about?]]<br />
* [[STorM32-Link]]<br />
* [[Terms of Use]]<br />
<br />
<br />
'''Tutorial'''<br />
* [[Getting Started]]<br />
* [[Tuning Recipe]]<br />
* [[Configure the RC Input]]<br />
* [[Hold versus Pan Mode]]<br />
* [[Advanced Functions]]<br />
* [[Video Tutorials]]<br />
<br />
<br />
'''Boards, Modules, and Vendors'''<br />
* [[STorM32 Boards]]<br />
* [[Where to buy STorM32 components]]<br />
<!--* [[Where to buy plug&play STorM32 gimbals]]<br />
* [[Where to buy STorM32 boards]]<br />
* [[Where to get NT Modules]]<br />
* [[Where to buy T-STorM32 stuff]]<br />
* [[How to choose a gimbal motor]]--><br />
<br />
<br />
|width=300px|<br />
'''Manuals'''<br />
* [[Dos and Don'ts]]<br />
* [[How to flash firmware]]<br />
* [[How to flash NT Modules]]<br />
* [[Calibration]]<br />
* [[Inputs and Functions]]<br />
* [[Using a 2nd IMU]]<br />
* [[Using the DataDisplay]]<br />
* [[STorM32 Scripts]]<br />
* [[Prearm Checks]]<br />
* [[NT Camera]]<br />
* [[Filters]]<br />
<br />
<br />
'''T-STorM32 Manuals'''<br />
* [[Getting Started with T-STorM32]]<br />
* [[How to build a T-STorM32 gimbal]]<br />
* [[Model-based Control]]<br />
* [[NT Module CLI]]<br />
<br />
|width=300px|<br />
'''Reference Manuals'''<br />
* [[Leds]]<br />
* [[Pins and Connectors]]<br />
* [[Pins and Connectors of NT Modules]]<br />
* [[Ports and Pins by Function]]<br />
* [[STorM32 Parameters|Complete List of Parameters]]<br />
* [[Serial Communication]]<br />
* [[MAVLink Communication]]<br />
* [[NT Data Logging]]<br />
* [[Serial Ports]]<br />
* [[Calibration Model]]<br />
* [[NT Bus Protocol]]<br />
* [[Yaw]]<br />
<br />
<br />
'''Application Notes'''<br />
* [[Using STorM32 with BetaPilot]]<br />
* [[Using STorM32 with ArduPilot]]<br />
* [[Evaluating Vibrations and Optimizing Damper Systems]]<br />
* [[Code Examples]]<br />
<br />
|}<br />
{|<br />
|- valign="top"<br />
|width=300px|<br />
'''Bits and Bobs'''<br />
* [[How to use 2 axis and 1 axis gimbals]]<br />
* [[Determine number of motor poles]]<br />
* [[Ensys NT Modules]]<br />
|width=300px|<br />
<br />
<br />
* [[3.3 V Fix Mod for STorM32 v1.31 Boards]]<br />
* [[How to build a DIY NT Logger]]<br />
* [[RS485, LVDS, and Alike]]<br />
|width=300px|<br />
<br />
<br />
* [[How to install and use a joystick]]<br />
* [[Gimbals with Integrated Landing Skids]]<br />
* [[Using STorM32 with Raspberry Pi]]<br />
|}<br />
<br />
<br />
-----<br />
{|<br />
|- valign="top"<br />
|width=300px|<br />
<br />
'''White Papers'''<br />
* [[Manually Setting the IMU Orientation]]<br />
|width=300px|<br />
'''DIY'''<br />
* [[How to order the electronic parts]]<br />
* [[How to order print boards (PCBs)]]<br />
* [[Electronic Parts for NT Modules]]<br />
|<br />
<br />
<br />
* [[Miscellaneous Projects]]<br />
|}<br />
{|<br />
|- valign="top"<br />
|width=300px|<br />
'''Legacy'''<br />
* [[CAN Bus Communication]]<br />
* [[Bluetooth Module HC06]]<br />
* [[Filters]]<br />
|width=300px|<br />
<br />
<br />
* [[Using STorM32 with DJI]]<br />
|width=300px|<br />
<br />
<br />
* [[Using a OLED Display]]<br />
* [[Using a ESP8266 Wifi Module]]<br />
|}<br />
{|<br />
|- valign="top"<br />
|width=300px|<br />
'''Recycle Bin'''<br />
* [[Tuning Guide]]<br />
* [[QuickStart Guide - old, v0.56]]<br />
* [[Getting Started - old, v0.56]]<br />
* [[Where to buy accessories and supplies]]<br />
|width=300px|<br />
<br />
<br />
* [[I2C Error Compendium]]<br />
* [[Serial Communication - old, v0.77e]]<br />
* [[6-Point Calibration - old]]<br />
|width=300px|<br />
<br />
<br />
* [[Quick Start Guide|Quick Start Guide - old, v0.57e]]<br />
* [[Serial Communication old]]<br />
* [[Using STorM32 with ArduPilot - old]]<br />
* [[Using STorM32 with ArduPilot - old II]]<br />
|}<br />
<br />
[[Q Mode]]</div>OlliWhttp://www.olliw.eu/storm32bgc-v2-wiki/index.php?title=Pins_and_Connectors&diff=11912Pins and Connectors2025-11-30T10:36:02Z<p>OlliW: /* STorM32 v6.2 Board */</p>
<hr />
<div>This page provides diagrams of the many connections on the STorM32 boards.<br />
<br />
The STorM32 connections are grouped into '''''ports'''''. A port consists typically of one or more '''''pins''''', a Gnd pin and possibly a 3.3 V or 5 V pin. The pins of a port are labeled by the port name plus a number (e.g. AUX-0 refers to the pin 0 on the {{BOX|AUX}} port) or by its commonly known function (such as Gnd, 3.3 V, Tx, Rx, SCL, SDA etc.). Some pins can serve multiple purposes, e.g., pin RC-0 can serve also as Futaba S-Bus input, as CRSF input or as UARTX-Rx.<br />
<br />
For a general description of the ports and pins see [[Ports and Pins by Function]]. For the details of their function and usage please consult the other wiki pages.<br />
<br />
Except of the ports {{BOX|POT}}, {{BOX|BUT}} and {{BOX|UART2/ESP}} all ports are 5 V tolerant, which means that you can apply signals with voltages of up to 5 V to their pins without damaging the board. The ports {{BOX|POT}}, {{BOX|BUT}} and {{BOX|UART2/ESP}} are however '''''not''''' 5 V tolerant. '''''{{WARNING|The voltage on the {{BOX|POT}}, {{BOX|BUT}} and {{BOX|UART2/ESP}} pins must not exceed 3.3 V}}'''''. <br />
<br />
The 3.3 V and 5 V pins must only be used as supply. '''''{{WARNING|Never apply any voltage to a 3.3 V or 5 V pin}}''''' (unless you're an expert and know what you do).<br />
<br />
<div class="toclimit-2">__TOC__</div><br />
<br />
== STorM32 v6.3 Board ==<br />
<br />
The STorM32 v6.3 main board has the same connections as the v4.1 board. <br />
<br />
'''Specs''': [[STorM32_Boards#STorM32-BGC_v6.3|STorM32 Boards: STorM32-BGC v6.3]]<br />
<br />
== STorM32 v6.2 Board ==<br />
<br />
The STorM32 v6.2 main board has the same connections as the v3.3 board (except of the CAN bus pins, which are obsolete and not available on v6.2). <br />
<br />
'''Specs''': [[STorM32_Boards#STorM32-BGC_v6.2|STorM32 Boards: STorM32-BGC v6.2]]<br />
<br />
== STorM32 v4.1 Board ==<br />
<br />
The STorM32 v4.1 main board provides two types of NT bus ports, the {{BOX|NT}} and {{BOX|NT-X}} ports. They both are '''''different''''' from the NT bus connectors found on the NT modules in as much as they have swapped Rx, Tx pins. <br />
<br />
{{COMMENT|The Rx, Tx pins of the {{BOX|NT}} and {{BOX|NT-X}} ports on the STorM32 board must be connected to the Tx, Rx pins on the NT modules.}}<br />
<br />
On the bottom side of the board is located the JP1 solder bridge (not visible in the picture below). When closed: The motor drivers are connected to VBat and are powered, and can be used. The voltage shall then not exceed 12 V or 3S. When open: The motor drivers are disabled and non-functional, and the voltage can be up to 27 V or 6S. <br />
<br />
'''Specs''': [[STorM32_Boards#STorM32-BGC_v4.1|STorM32 Boards: STorM32-BGC v4.1]]<br />
<br />
:[[File:Storm32-bgc-nt-v41-ports-and-connections.jpg|720px]]<br />
<br />
{{COMMENT|The board shown in the picture is a pre-release version (doesn't show the JP1 solder bridge on the bottom side).}}<br />
<br />
== STorM32 v3.3 Board ==<br />
<br />
The STorM32 v3.3 main board provides two types of NT bus ports, the {{BOX|NT}} and {{BOX|NT-X}} ports. They both are '''''different''''' from the NT bus connectors found on the NT modules in as much as they have swapped Rx, Tx pins. <br />
<br />
{{COMMENT|The Rx, Tx pins of the {{BOX|NT}} and {{BOX|NT-X}} ports on the STorM32 board must be connected to the Tx, Rx pins on the NT modules.}}<br />
<br />
{{COMMENT|The v3.3 STorM32 boards have '''no''' motor drivers on-board, i.e., NT motor modules are needed in addition.}}<br />
<br />
{{COMMENT|The {{BOX|CAN}} port is obsolete, and not supported anymore since firmware v2.57e.}}<br />
<br />
'''Specs''': [[STorM32_Boards#STorM32-BGC_v3.3m,_v3.3i|STorM32 Boards: STorM32-BGC v3.3m/i]]<br />
<br />
:[[File:Storm32-bgc-nt-v33-ports-and-connections.jpg|720px]]<br />
<br />
== Micro STorM32 v3.3 Board ==<br />
<br />
The v3.3i Micro STorM32 board provides the same connections as the v3.3 Board (with the exception of the {{BOX|USB}} port), but exposes them as solder pads.<br />
<br />
The Micro STorM32 board is designed to be stackable with other extension boards, such as USB, power, motor, logger boards, see e.g. the rcgroups post [https://www.rcgroups.com/forums/showpost.php?p=43237597&postcount=11716 here].<br />
<br />
{{COMMENT|The v3.3 Micro STorM32 board has '''no''' motor drivers on-board, i.e., NT motor modules are needed in addition.}}<br />
<br />
:[[File:Storm32-bgc-micro-v33-ports-and-connections.jpg|720px]]<br />
<br />
== STorM32 RaspberryPi Hat v3.3 ==<br />
<br />
The v3.3i STorM32 RaspberryPi Hat provides the same connections as the Micro STorM32 v3.3 board, but in RaspberryPi micro-Hat form factor. The hat is designed to be compatible with the extension boards of the Micro STorM32 series. In addition it provides an EEPROM as required by the RaspberryPi Hat specification (not populated in the picture). Furthermore it provides a dual UART expansion module, and some more connections with the RaspberryPi GPIOs.<br />
<br />
:[[File:Storm32-rpihat-v33i-ports-and-connections.jpg|720px]]<br />
<br />
== STorM32 v1.x Boards ==<br />
<br />
On STorM32 v1.3x main boards, the I2C plug is used as NT bus connector, with the pin assignment as shown below. <br />
<br />
The scheme below refers to a v1.3 board. The pins of the v1.31 board are identical to that of the v1.3 board. <br />
<br />
{{COMMENT|The Rx and Tx pins on the STorM32 board must be connected to the Tx and Rx pins on the NT modules. This needs a "crossing" of the Rx, Tx lines for the v1.x boards, see also the diagram in [[What_is_STorM32_NT_about%3F|What is STorM32 NT about?]]}}<br />
<br />
{{COMMENT|If starting from a "classic" (non-NT) STorM32 gimbal kit with an I2C IMU module, it is usually necessary to rewire existing cables to match the pinout of the NT bus.}}<br />
<br />
{{COMMENT|v1.1 and v1.2 boards are deprecated and not supported anymore. The v1.2 board run the firmware for the v1.3x board, with only few caveats.}} <br />
<br />
:[[File:Storm32-bgc-v13-ports-and-connections.jpg|540px]]<br />
<!--:[[File:NT_Pinout.jpg|480px]]--><br />
<!--<br />
== Ensys STorM32 v3.3 Board ==<br />
<br />
This board, although obviously derived from the v3.3 design, is a propietary design by [https://www.ensys.lt/product-category/electronics/ Ensys] with many smaller and larger modifications. <br />
<br />
Please inspect their page for documentation: [https://www.ensys.lt/product/ensys-storm32-v3-3-board-beta/ here].<br />
<br />
== CC3D Atom STorM32 Board ==<br />
<br />
Since firmware version v2.27 it is possible to use a Atom CC3D as STorM32 main board. The Flexi Port plug is used as NT bus connector, with the pin assignments as shown below. Further information on the CC3D Atom can be found [http://opwiki.readthedocs.io/en/latest/user_manual/cc3d/cc3d.html here].<br />
<br />
{{COMMENT|The CC3D cannot be used anymore with the latest firmwares. This is obviously so because the feature set has grown enormously taking up too much flash space. The v3.3 board should be an excellent alternative.}} <br />
<br />
:[[File:Storm32-bgc-nt-cc3d-pinout.jpg|680px]]--></div>OlliWhttp://www.olliw.eu/storm32bgc-v2-wiki/index.php?title=Filters&diff=11911Filters2025-11-30T10:35:06Z<p>OlliW: </p>
<hr />
<div>''The information on this page refers to firmware v2.74 and higher.''<br />
<br />
The STorM32 provides a filter section to filter the gyro and accelerometer, using notch/band-cut filters.<br />
<br />
<div class="toclimit-2">__TOC__</div><br />
<br />
== Concept and Overview ==<br />
<br />
The filters are organized into three identical filter banks, which are processed in series. That is, the data are feed into filter bank #1, the output of this bank is then feed into filter bank #2, and finally the output of bank #2 is feed into filter bank #3. This allows for a very flexible choice of filter arrangements.<br />
<br />
The parameters of the filter banks are exemplarily described for filter bank #1. They are:<br />
<br />
* {{PARAMNAME|Filter1 Source}}: Selects the filter source. <br />
* {{PARAMNAME|Filter1 Center Frequency}}: Selects the center or cut-off frequency of the filter.<br />
* {{PARAMNAME|Filter1 Bandwidth}}: Selects the bandwidth for notch or band-cut filters.<br />
* {{PARAMNAME|Filter1 Attenuation}}: Selects the attenuation of the band-cut filters. {{PARAMVALUE|inf}} results in a notch filter.<br />
<br />
== Filter Sources ==<br />
<br />
Currently, the following data sources are available:<br />
<br />
{| class="wikitable" !filter source!effect<br />
|-<br />
| {{PARAMVALUE|off}} || The filter bank is inactive.<br />
|-<br />
| {{PARAMVALUE|gyro1 all}} || The raw data of gyro1 are filtered.<br />
|-<br />
| {{PARAMVALUE|imu1 all}} || <br />
|}</div>OlliWhttp://www.olliw.eu/storm32bgc-v2-wiki/index.php?title=Manuals_and_Tutorials&diff=11910Manuals and Tutorials2025-11-30T10:33:14Z<p>OlliW: </p>
<hr />
<div>{|<br />
|- valign="top"<br />
|width=300px|<br />
'''Flyers'''<br />
* [[What is STorM32 NT about?]]<br />
* [[What is T-STorM32 about?]]<br />
* [[STorM32-Link]]<br />
* [[Terms of Use]]<br />
<br />
<br />
'''Tutorial'''<br />
* [[Getting Started]]<br />
* [[Tuning Recipe]]<br />
* [[Configure the RC Input]]<br />
* [[Hold versus Pan Mode]]<br />
* [[Advanced Functions]]<br />
* [[Video Tutorials]]<br />
<br />
<br />
'''Boards, Modules, and Vendors'''<br />
* [[STorM32 Boards]]<br />
* [[Where to buy STorM32 components]]<br />
<!--* [[Where to buy plug&play STorM32 gimbals]]<br />
* [[Where to buy STorM32 boards]]<br />
* [[Where to get NT Modules]]<br />
* [[Where to buy T-STorM32 stuff]]<br />
* [[How to choose a gimbal motor]]--><br />
<br />
<br />
<br />
<br />
|width=300px|<br />
'''Manuals'''<br />
* [[Dos and Don'ts]]<br />
* [[How to flash firmware]]<br />
* [[How to flash NT Modules]]<br />
* [[Calibration]]<br />
* [[Inputs and Functions]]<br />
* [[Using a 2nd IMU]]<br />
* [[Using the DataDisplay]]<br />
* [[STorM32 Scripts]]<br />
* [[Prearm Checks]]<br />
* [[NT Camera]]<br />
* [[Filters]]<br />
<br />
<br />
<br />
'''T-STorM32 Manuals'''<br />
* [[Getting Started with T-STorM32]]<br />
* [[How to build a T-STorM32 gimbal]]<br />
* [[Model-based Control]]<br />
* [[NT Module CLI]]<br />
<br />
|width=300px|<br />
'''Reference Manuals'''<br />
* [[Leds]]<br />
* [[Pins and Connectors]]<br />
* [[Pins and Connectors of NT Modules]]<br />
* [[Ports and Pins by Function]]<br />
* [[STorM32 Parameters|Complete List of Parameters]]<br />
* [[Serial Communication]]<br />
* [[MAVLink Communication]]<br />
* [[NT Data Logging]]<br />
* [[Serial Ports]]<br />
* [[Calibration Model]]<br />
* [[NT Bus Protocol]]<br />
* [[Yaw]]<br />
<br />
<br />
'''Application Notes'''<br />
* [[Using STorM32 with BetaPilot]]<br />
* [[Using STorM32 with ArduPilot]]<br />
* [[Evaluating Vibrations and Optimizing Damper Systems]]<br />
* [[Code Examples]]<br />
<br />
|}<br />
{|<br />
|- valign="top"<br />
|width=300px|<br />
'''Bits and Bobs'''<br />
* [[How to use 2 axis and 1 axis gimbals]]<br />
* [[Determine number of motor poles]]<br />
* [[Ensys NT Modules]]<br />
|width=300px|<br />
<br />
<br />
* [[3.3 V Fix Mod for STorM32 v1.31 Boards]]<br />
* [[How to build a DIY NT Logger]]<br />
* [[RS485, LVDS, and Alike]]<br />
|width=300px|<br />
<br />
<br />
* [[How to install and use a joystick]]<br />
* [[Gimbals with Integrated Landing Skids]]<br />
* [[Using STorM32 with Raspberry Pi]]<br />
|}<br />
<br />
<br />
-----<br />
{|<br />
|- valign="top"<br />
|width=300px|<br />
<br />
'''White Papers'''<br />
* [[Manually Setting the IMU Orientation]]<br />
|width=300px|<br />
'''DIY'''<br />
* [[How to order the electronic parts]]<br />
* [[How to order print boards (PCBs)]]<br />
* [[Electronic Parts for NT Modules]]<br />
|<br />
<br />
<br />
* [[Miscellaneous Projects]]<br />
|}<br />
{|<br />
|- valign="top"<br />
|width=300px|<br />
'''Legacy'''<br />
* [[CAN Bus Communication]]<br />
* [[Bluetooth Module HC06]]<br />
* [[Filters]]<br />
|width=300px|<br />
<br />
<br />
* [[Using STorM32 with DJI]]<br />
|width=300px|<br />
<br />
<br />
* [[Using a OLED Display]]<br />
* [[Using a ESP8266 Wifi Module]]<br />
|}<br />
{|<br />
|- valign="top"<br />
|width=300px|<br />
'''Recycle Bin'''<br />
* [[Tuning Guide]]<br />
* [[QuickStart Guide - old, v0.56]]<br />
* [[Getting Started - old, v0.56]]<br />
* [[Where to buy accessories and supplies]]<br />
|width=300px|<br />
<br />
<br />
* [[I2C Error Compendium]]<br />
* [[Serial Communication - old, v0.77e]]<br />
* [[6-Point Calibration - old]]<br />
|width=300px|<br />
<br />
<br />
* [[Quick Start Guide|Quick Start Guide - old, v0.57e]]<br />
* [[Serial Communication old]]<br />
* [[Using STorM32 with ArduPilot - old]]<br />
* [[Using STorM32 with ArduPilot - old II]]<br />
|}<br />
<br />
[[Q Mode]]</div>OlliWhttp://www.olliw.eu/storm32bgc-v2-wiki/index.php?title=Manuals_and_Tutorials&diff=11909Manuals and Tutorials2025-11-30T10:33:02Z<p>OlliW: </p>
<hr />
<div>{|<br />
|- valign="top"<br />
|width=300px|<br />
'''Flyers'''<br />
* [[What is STorM32 NT about?]]<br />
* [[What is T-STorM32 about?]]<br />
* [[STorM32-Link]]<br />
* [[Terms of Use]]<br />
<br />
<br />
'''Tutorial'''<br />
* [[Getting Started]]<br />
* [[Tuning Recipe]]<br />
* [[Configure the RC Input]]<br />
* [[Hold versus Pan Mode]]<br />
* [[Advanced Functions]]<br />
* [[Video Tutorials]]<br />
<br />
<br />
'''Boards, Modules, and Vendors'''<br />
* [[STorM32 Boards]]<br />
* [[Where to buy STorM32 components]]<br />
<!--* [[Where to buy plug&play STorM32 gimbals]]<br />
* [[Where to buy STorM32 boards]]<br />
* [[Where to get NT Modules]]<br />
* [[Where to buy T-STorM32 stuff]]<br />
* [[How to choose a gimbal motor]]--><br />
<br />
<br />
<br />
<br />
|width=300px|<br />
'''Manuals'''<br />
* [[Dos and Don'ts]]<br />
* [[How to flash firmware]]<br />
* [[How to flash NT Modules]]<br />
* [[Calibration]]<br />
* [[Inputs and Functions]]<br />
* [[Using a 2nd IMU]]<br />
* [[Using the DataDisplay]]<br />
* [[STorM32 Scripts]]<br />
* [[Prearm Checks]]<br />
* [[NT Camera]]<br />
* [[Filters]]<br />
<br />
<br />
'''T-STorM32 Manuals'''<br />
* [[Getting Started with T-STorM32]]<br />
* [[How to build a T-STorM32 gimbal]]<br />
* [[Model-based Control]]<br />
* [[NT Module CLI]]<br />
<br />
|width=300px|<br />
'''Reference Manuals'''<br />
* [[Leds]]<br />
* [[Pins and Connectors]]<br />
* [[Pins and Connectors of NT Modules]]<br />
* [[Ports and Pins by Function]]<br />
* [[STorM32 Parameters|Complete List of Parameters]]<br />
* [[Serial Communication]]<br />
* [[MAVLink Communication]]<br />
* [[NT Data Logging]]<br />
* [[Serial Ports]]<br />
* [[Calibration Model]]<br />
* [[NT Bus Protocol]]<br />
* [[Yaw]]<br />
<br />
<br />
'''Application Notes'''<br />
* [[Using STorM32 with BetaPilot]]<br />
* [[Using STorM32 with ArduPilot]]<br />
* [[Evaluating Vibrations and Optimizing Damper Systems]]<br />
* [[Code Examples]]<br />
<br />
|}<br />
{|<br />
|- valign="top"<br />
|width=300px|<br />
'''Bits and Bobs'''<br />
* [[How to use 2 axis and 1 axis gimbals]]<br />
* [[Determine number of motor poles]]<br />
* [[Ensys NT Modules]]<br />
|width=300px|<br />
<br />
<br />
* [[3.3 V Fix Mod for STorM32 v1.31 Boards]]<br />
* [[How to build a DIY NT Logger]]<br />
* [[RS485, LVDS, and Alike]]<br />
|width=300px|<br />
<br />
<br />
* [[How to install and use a joystick]]<br />
* [[Gimbals with Integrated Landing Skids]]<br />
* [[Using STorM32 with Raspberry Pi]]<br />
|}<br />
<br />
<br />
-----<br />
{|<br />
|- valign="top"<br />
|width=300px|<br />
<br />
'''White Papers'''<br />
* [[Manually Setting the IMU Orientation]]<br />
|width=300px|<br />
'''DIY'''<br />
* [[How to order the electronic parts]]<br />
* [[How to order print boards (PCBs)]]<br />
* [[Electronic Parts for NT Modules]]<br />
|<br />
<br />
<br />
* [[Miscellaneous Projects]]<br />
|}<br />
{|<br />
|- valign="top"<br />
|width=300px|<br />
'''Legacy'''<br />
* [[CAN Bus Communication]]<br />
* [[Bluetooth Module HC06]]<br />
* [[Filters]]<br />
|width=300px|<br />
<br />
<br />
* [[Using STorM32 with DJI]]<br />
|width=300px|<br />
<br />
<br />
* [[Using a OLED Display]]<br />
* [[Using a ESP8266 Wifi Module]]<br />
|}<br />
{|<br />
|- valign="top"<br />
|width=300px|<br />
'''Recycle Bin'''<br />
* [[Tuning Guide]]<br />
* [[QuickStart Guide - old, v0.56]]<br />
* [[Getting Started - old, v0.56]]<br />
* [[Where to buy accessories and supplies]]<br />
|width=300px|<br />
<br />
<br />
* [[I2C Error Compendium]]<br />
* [[Serial Communication - old, v0.77e]]<br />
* [[6-Point Calibration - old]]<br />
|width=300px|<br />
<br />
<br />
* [[Quick Start Guide|Quick Start Guide - old, v0.57e]]<br />
* [[Serial Communication old]]<br />
* [[Using STorM32 with ArduPilot - old]]<br />
* [[Using STorM32 with ArduPilot - old II]]<br />
|}<br />
<br />
[[Q Mode]]</div>OlliWhttp://www.olliw.eu/storm32bgc-v2-wiki/index.php?title=Downloads&diff=11908Downloads2025-11-30T09:14:25Z<p>OlliW: </p>
<hr />
<div>{{ALERT| '''PLEASE READ THIS FIRST''' <br />
There are 2 types of IMU modules which STorM32 v1.3x controllers can use, NT IMUs and I2C IMUs, and there are 2 firmwares which correspond to each type. It is important to choose the correct firmware, otherwise your controller and gimbal will not work. Read this page to understand the difference between the two types of IMUs [[//www.olliw.eu/storm32bgc-v2-wiki/What_is_STorM32_NT_about%3F]], and this post to identify your IMU [[//www.rcgroups.com/forums/showpost.php?p=38258334&postcount=10256]]. <br />
<br />
The STorM32 v3.x, v4.x, v6.x controllers can only use NT IMUs, not I2C IMUs.<br />
<br />
Only firmwares with version v0.96 or less work with I2C IMUs. Firmwares with version numbers v2.xx are not usable for setups with I2C IMU. If you do not know what a NT IMU is, then you likely have a I2C IMU and need firmware v0.96.}}<br />
<br/><br />
{{ALERT| '''ANNOUNCEMENTS'''<br />
- The v2.xx firmware series will phase out, i.e., currently it is planned that firmware 2.74 is the last release in this series. <br/><br />
- Development will shift to [//www.olliw.eu/storm32bgc-wiki STorM32 v3]. STorM32 v3 will not support the old and tried v1.3x boards, as well as not the v3.3 and v4.1 boards. Reason is that the STM32F103 microcontroller used on these boards has simply become too limited.<br />
<!--- Support of the v1.3x STorM32 boards will phase out. That is, the next official release (whenever this will be), will be the last release which supports these old and tried main boards. Reason is that since few years I have migrated to the STM32 HAL&LL libraries, but the v1.3x code is still on the legacy SPL library since it's I2C is ca 50-100 us faster than the HAL I2C lib. So I maintain two codes, which is obviously not sustainable.<br />
- Support for quite a number of presumably "old" cameras will phase out. Some of them are so old that it's hard to imagine they are still in use. Examples are Git2, Mapir Survey, Firefly Split 4K, Runcam, GoPro Hero5&7.-->}}<br />
<br />
== v2.xx Firmware for NT IMUs ==<br />
<br />
Firmware for STorM32 setups using a NT camera IMU. <br />
<br />
<br />
Direct link to v2.74 firmware download:<br> <br />
<br />
:[//github.com/olliw42/storm32bgc/raw/main/firmware%20binaries%20%26%20gui/o323bgc-release-v274-v20251130.zip o323bgc-release-v274-v20251130] [.zip] (14.9 MB)<br />
:[https://www.rcgroups.com/forums/showpost.php?p=54399911&postcount=16253 Release Notes]<br />
<br />
<!--<br />
Latest beta release v2.73e:<br><br />
:[//github.com/olliw42/storm32bgc/raw/main/firmware%20binaries%20%26%20gui/o323bgc-release-v273e-v20250711.zip o323bgc-release-v273e-v20250711] [.zip] (15.9 MB)<br />
:[https://www.rcgroups.com/forums/showpost.php?p=53978973&postcount=15988 Release Notes]<br />
--><br />
<br />
NTLoggerTool release v0.50:<br><br />
:[//www.olliw.eu/downloads/storm32/ntloggertool/ntloggertool-release-v050-v20231003.zip ntloggertool-release-v050-v20231003] [.zip] (295 MB)<br />
<br />
<br />
BetaCopter/BetaPlane 4.7-dev:<br><br />
:For downloading the firmwares and all further info please visit the article [[Using STorM32 with BetaPilot]].<br />
<br />
== v0.96 Firmware for I2C IMUs ==<br />
<br />
Firmware for STorM32 setups using a I2C camera IMU. Examples are the HakRC gimbal and other gimbals from Aliexpress.<br />
<br />
Latest firmware v0.96 for I2C IMUs:<br> <br />
:[//github.com/olliw42/storm32bgc/raw/master/firmware%20binaries%20%26%20gui/o323bgc-release-v096-v20160319.zip o323bgc-release-v096-v20160319] [.zip] (9.4MB)<br />
<br />
Note: This wiki here is not appropriate for v0.96 I2C setups, you should go to [//www.olliw.eu/storm32bgc-v1-wiki/Main_Page STorM32 v0.xx Wiki].<br />
<br />
{{COMMENT|The v0.96 release also includes firmwares for NT IMUs, identifiable by a label "nt" in the file names. Don't use them, use the v0.96 firmware (without a "nt" in the file name).}}<br />
<br />
== Repository ==<br />
<br />
Various files related to the STorM32-BGC project can be downloaded from several places:<br />
* [//github.com/olliw42/storm32bgc Github repository]<br />
* 1st page of the [//www.rcgroups.com/forums/showthread.php?t=2055844 rcgroups discussion thread]</div>OlliWhttp://www.olliw.eu/storm32bgc-v2-wiki/index.php?title=Downloads&diff=11907Downloads2025-11-30T08:41:08Z<p>OlliW: /* v2.xx Firmware for NT IMUs */</p>
<hr />
<div>{{ALERT| '''PLEASE READ THIS FIRST''' <br />
There are 2 types of IMU modules which STorM32 v1.3x controllers can use, NT IMUs and I2C IMUs, and there are 2 firmwares which correspond to each type. It is important to choose the correct firmware, otherwise your controller and gimbal will not work. Read this page to understand the difference between the two types of IMUs [[//www.olliw.eu/storm32bgc-v2-wiki/What_is_STorM32_NT_about%3F]], and this post to identify your IMU [[//www.rcgroups.com/forums/showpost.php?p=38258334&postcount=10256]]. <br />
<br />
The STorM32 v3.x, v4.x, v6.x controllers can only use NT IMUs, not I2C IMUs.<br />
<br />
Only firmwares with version v0.96 or less work with I2C IMUs. Firmwares with version numbers v2.xx are not usable for setups with I2C IMU. If you do not know what a NT IMU is, then you likely have a I2C IMU and need firmware v0.96.}}<br />
<br/><br />
{{ALERT| '''ANNOUNCEMENTS'''<br />
- The v2.xx firmware series will phase out, i.e., currently it is planned that firmware 2.74 is the last release in this series. <br/><br />
- Development will shift to [//www.olliw.eu/storm32bgc-wiki STorM32 v3]. STorM32 v3 will not support the old and tried v1.3x boards, as well as not the v3.3 and v4.1 boards. Reason is that the STM32F103 microcontroller used on these boards has simply become too limited.<br />
<!--- Support of the v1.3x STorM32 boards will phase out. That is, the next official release (whenever this will be), will be the last release which supports these old and tried main boards. Reason is that since few years I have migrated to the STM32 HAL&LL libraries, but the v1.3x code is still on the legacy SPL library since it's I2C is ca 50-100 us faster than the HAL I2C lib. So I maintain two codes, which is obviously not sustainable.<br />
- Support for quite a number of presumably "old" cameras will phase out. Some of them are so old that it's hard to imagine they are still in use. Examples are Git2, Mapir Survey, Firefly Split 4K, Runcam, GoPro Hero5&7.-->}}<br />
<br />
== v2.xx Firmware for NT IMUs ==<br />
<br />
Firmware for STorM32 setups using a NT camera IMU. <br />
<br />
<br />
Direct link to v2.74 firmware download:<br> <br />
<br />
:[//github.com/olliw42/storm32bgc/raw/main/firmware%20binaries%20%26%20gui/o323bgc-release-v274-v20251130.zip o323bgc-release-v274-v20251130] [.zip] (14.9 MB)<br />
:[//www.rcgroups.com/forums/showpost.php?p=44539519&postcount=12349 Release Notes]<br />
<br />
<!--<br />
Latest beta release v2.73e:<br><br />
:[//github.com/olliw42/storm32bgc/raw/main/firmware%20binaries%20%26%20gui/o323bgc-release-v273e-v20250711.zip o323bgc-release-v273e-v20250711] [.zip] (15.9 MB)<br />
:[https://www.rcgroups.com/forums/showpost.php?p=53978973&postcount=15988 Release Notes]<br />
--><br />
<br />
NTLoggerTool release v0.50:<br><br />
:[//www.olliw.eu/downloads/storm32/ntloggertool/ntloggertool-release-v050-v20231003.zip ntloggertool-release-v050-v20231003] [.zip] (295 MB)<br />
<br />
<br />
BetaCopter/BetaPlane 4.7-dev:<br><br />
:For downloading the firmwares and all further info please visit the article [[Using STorM32 with BetaPilot]].<br />
<br />
== v0.96 Firmware for I2C IMUs ==<br />
<br />
Firmware for STorM32 setups using a I2C camera IMU. Examples are the HakRC gimbal and other gimbals from Aliexpress.<br />
<br />
Latest firmware v0.96 for I2C IMUs:<br> <br />
:[//github.com/olliw42/storm32bgc/raw/master/firmware%20binaries%20%26%20gui/o323bgc-release-v096-v20160319.zip o323bgc-release-v096-v20160319] [.zip] (9.4MB)<br />
<br />
Note: This wiki here is not appropriate for v0.96 I2C setups, you should go to [//www.olliw.eu/storm32bgc-v1-wiki/Main_Page STorM32 v0.xx Wiki].<br />
<br />
{{COMMENT|The v0.96 release also includes firmwares for NT IMUs, identifiable by a label "nt" in the file names. Don't use them, use the v0.96 firmware (without a "nt" in the file name).}}<br />
<br />
== Repository ==<br />
<br />
Various files related to the STorM32-BGC project can be downloaded from several places:<br />
* [//github.com/olliw42/storm32bgc Github repository]<br />
* 1st page of the [//www.rcgroups.com/forums/showthread.php?t=2055844 rcgroups discussion thread]</div>OlliWhttp://www.olliw.eu/storm32bgc-v2-wiki/index.php?title=Downloads&diff=11906Downloads2025-11-30T08:40:46Z<p>OlliW: </p>
<hr />
<div>{{ALERT| '''PLEASE READ THIS FIRST''' <br />
There are 2 types of IMU modules which STorM32 v1.3x controllers can use, NT IMUs and I2C IMUs, and there are 2 firmwares which correspond to each type. It is important to choose the correct firmware, otherwise your controller and gimbal will not work. Read this page to understand the difference between the two types of IMUs [[//www.olliw.eu/storm32bgc-v2-wiki/What_is_STorM32_NT_about%3F]], and this post to identify your IMU [[//www.rcgroups.com/forums/showpost.php?p=38258334&postcount=10256]]. <br />
<br />
The STorM32 v3.x, v4.x, v6.x controllers can only use NT IMUs, not I2C IMUs.<br />
<br />
Only firmwares with version v0.96 or less work with I2C IMUs. Firmwares with version numbers v2.xx are not usable for setups with I2C IMU. If you do not know what a NT IMU is, then you likely have a I2C IMU and need firmware v0.96.}}<br />
<br/><br />
{{ALERT| '''ANNOUNCEMENTS'''<br />
- The v2.xx firmware series will phase out, i.e., currently it is planned that firmware 2.74 is the last release in this series. <br/><br />
- Development will shift to [//www.olliw.eu/storm32bgc-wiki STorM32 v3]. STorM32 v3 will not support the old and tried v1.3x boards, as well as not the v3.3 and v4.1 boards. Reason is that the STM32F103 microcontroller used on these boards has simply become too limited.<br />
<!--- Support of the v1.3x STorM32 boards will phase out. That is, the next official release (whenever this will be), will be the last release which supports these old and tried main boards. Reason is that since few years I have migrated to the STM32 HAL&LL libraries, but the v1.3x code is still on the legacy SPL library since it's I2C is ca 50-100 us faster than the HAL I2C lib. So I maintain two codes, which is obviously not sustainable.<br />
- Support for quite a number of presumably "old" cameras will phase out. Some of them are so old that it's hard to imagine they are still in use. Examples are Git2, Mapir Survey, Firefly Split 4K, Runcam, GoPro Hero5&7.-->}}<br />
<br />
== v2.xx Firmware for NT IMUs ==<br />
<br />
Firmware for STorM32 setups using a NT camera IMU. <br />
<br />
<br />
Direct link to v2.74 firmware download:<br> <br />
<br />
:[//github.com/olliw42/storm32bgc/raw/main/firmware%20binaries%20%26%20gui/o323bgc-release-v274-v20251130.zip o323bgc-release-v274-v20251130] [.zip] (12.2 MB)<br />
:[//www.rcgroups.com/forums/showpost.php?p=44539519&postcount=12349 Release Notes]<br />
<br />
<!--<br />
Latest beta release v2.73e:<br><br />
:[//github.com/olliw42/storm32bgc/raw/main/firmware%20binaries%20%26%20gui/o323bgc-release-v273e-v20250711.zip o323bgc-release-v273e-v20250711] [.zip] (15.9 MB)<br />
:[https://www.rcgroups.com/forums/showpost.php?p=53978973&postcount=15988 Release Notes]<br />
--><br />
<br />
NTLoggerTool release v0.50:<br><br />
:[//www.olliw.eu/downloads/storm32/ntloggertool/ntloggertool-release-v050-v20231003.zip ntloggertool-release-v050-v20231003] [.zip] (295 MB)<br />
<br />
<br />
BetaCopter/BetaPlane 4.7-dev:<br><br />
:For downloading the firmwares and all further info please visit the article [[Using STorM32 with BetaPilot]].<br />
<br />
== v0.96 Firmware for I2C IMUs ==<br />
<br />
Firmware for STorM32 setups using a I2C camera IMU. Examples are the HakRC gimbal and other gimbals from Aliexpress.<br />
<br />
Latest firmware v0.96 for I2C IMUs:<br> <br />
:[//github.com/olliw42/storm32bgc/raw/master/firmware%20binaries%20%26%20gui/o323bgc-release-v096-v20160319.zip o323bgc-release-v096-v20160319] [.zip] (9.4MB)<br />
<br />
Note: This wiki here is not appropriate for v0.96 I2C setups, you should go to [//www.olliw.eu/storm32bgc-v1-wiki/Main_Page STorM32 v0.xx Wiki].<br />
<br />
{{COMMENT|The v0.96 release also includes firmwares for NT IMUs, identifiable by a label "nt" in the file names. Don't use them, use the v0.96 firmware (without a "nt" in the file name).}}<br />
<br />
== Repository ==<br />
<br />
Various files related to the STorM32-BGC project can be downloaded from several places:<br />
* [//github.com/olliw42/storm32bgc Github repository]<br />
* 1st page of the [//www.rcgroups.com/forums/showthread.php?t=2055844 rcgroups discussion thread]</div>OlliWhttp://www.olliw.eu/storm32bgc-v2-wiki/index.php?title=Downloads&diff=11905Downloads2025-11-30T08:40:28Z<p>OlliW: /* v2.xx Firmware for NT IMUs */</p>
<hr />
<div>{{ALERT| '''PLEASE READ THIS FIRST''' <br />
There are 2 types of IMU modules which STorM32 v1.3x controllers can use, NT IMUs and I2C IMUs, and there are 2 firmwares which correspond to each type. It is important to choose the correct firmware, otherwise your controller and gimbal will not work. Read this page to understand the difference between the two types of IMUs [[//www.olliw.eu/storm32bgc-v2-wiki/What_is_STorM32_NT_about%3F]], and this post to identify your IMU [[//www.rcgroups.com/forums/showpost.php?p=38258334&postcount=10256]]. <br />
<br />
The STorM32 v3.x, v4.x, v6.x controllers can only use NT IMUs, not I2C IMUs.<br />
<br />
Only firmwares with version v0.96 or less work with I2C IMUs. Firmwares with version numbers v2.xx are not usable for setups with I2C IMU. If you do not know what a NT IMU is, then you likely have a I2C IMU and need firmware v0.96.}}<br />
<br/><br />
{{ALERT| '''ANNOUNCEMENTS'''<br />
- The v2.xx firmware series will phase out, i.e., currently it is planned that firmware 2.74 is the last release in this series. <br/><br />
- Development will shift to [//www.olliw.eu/storm32bgc-wiki STorM32 v3]. STorM32 v3 will not support the old and tried v1.3x boards, as well as not the v3.3 and v4.1 boards. Reason is that the STM32F103 microcontroller used on these boards has simply become too limited.<br />
<!--- Support of the v1.3x STorM32 boards will phase out. That is, the next official release (whenever this will be), will be the last release which supports these old and tried main boards. Reason is that since few years I have migrated to the STM32 HAL&LL libraries, but the v1.3x code is still on the legacy SPL library since it's I2C is ca 50-100 us faster than the HAL I2C lib. So I maintain two codes, which is obviously not sustainable.<br />
- Support for quite a number of presumably "old" cameras will phase out. Some of them are so old that it's hard to imagine they are still in use. Examples are Git2, Mapir Survey, Firefly Split 4K, Runcam, GoPro Hero5&7.-->}}<br />
<br />
== v2.xx Firmware for NT IMUs ==<br />
<br />
Firmware for STorM32 setups using a NT camera IMU. <br />
<br />
<br />
Direct link to v2.74 firmware download:<br> <br />
<br />
:[//github.com/olliw42/storm32bgc/raw/main/firmware%20binaries%20%26%20gui/o323bgc-release-v274-v20251130.zip o323bgc-release-v274-v20251130] [.zip] (12.2 MB)<br />
:[//www.rcgroups.com/forums/showpost.php?p=44539519&postcount=12349 Release Notes]<br />
<br />
<!--<br />
Latest beta release v2.73e:<br><br />
:[//github.com/olliw42/storm32bgc/raw/main/firmware%20binaries%20%26%20gui/o323bgc-release-v273e-v20250711.zip o323bgc-release-v273e-v20250711] [.zip] (15.9 MB)<br />
:[https://www.rcgroups.com/forums/showpost.php?p=53978973&postcount=15988 Release Notes]<br />
-_><br />
<br />
NTLoggerTool release v0.50:<br><br />
:[//www.olliw.eu/downloads/storm32/ntloggertool/ntloggertool-release-v050-v20231003.zip ntloggertool-release-v050-v20231003] [.zip] (295 MB)<br />
<br />
<br />
BetaCopter/BetaPlane 4.7-dev:<br><br />
:For downloading the firmwares and all further info please visit the article [[Using STorM32 with BetaPilot]].<br />
<br />
== v0.96 Firmware for I2C IMUs ==<br />
<br />
Firmware for STorM32 setups using a I2C camera IMU. Examples are the HakRC gimbal and other gimbals from Aliexpress.<br />
<br />
Latest firmware v0.96 for I2C IMUs:<br> <br />
:[//github.com/olliw42/storm32bgc/raw/master/firmware%20binaries%20%26%20gui/o323bgc-release-v096-v20160319.zip o323bgc-release-v096-v20160319] [.zip] (9.4MB)<br />
<br />
Note: This wiki here is not appropriate for v0.96 I2C setups, you should go to [//www.olliw.eu/storm32bgc-v1-wiki/Main_Page STorM32 v0.xx Wiki].<br />
<br />
{{COMMENT|The v0.96 release also includes firmwares for NT IMUs, identifiable by a label "nt" in the file names. Don't use them, use the v0.96 firmware (without a "nt" in the file name).}}<br />
<br />
== Repository ==<br />
<br />
Various files related to the STorM32-BGC project can be downloaded from several places:<br />
* [//github.com/olliw42/storm32bgc Github repository]<br />
* 1st page of the [//www.rcgroups.com/forums/showthread.php?t=2055844 rcgroups discussion thread]</div>OlliWhttp://www.olliw.eu/storm32bgc-v2-wiki/index.php?title=Serial_Ports&diff=11904Serial Ports2025-11-21T18:34:42Z<p>OlliW: /* Availability */</p>
<hr />
<div>This article aims at providing some clarification concerning the STorM32's serial ports.<br />
<br />
<div class="toclimit-2">__TOC__</div><br />
<br />
== Ports ==<br />
<br />
The naming of the STorM32 serial ports may appear confusing at first. However, it is in fact pretty consistent, across all boards - with one (unfortunate) exception: UART1. <br />
<br />
Generally, the STorM32 port naming follows this scheme: The name of a port is simply the type of the port, plus a number (or symbol) for the 2nd port of that type, and so on. Example: {{BOX|RC}} and {{BOX|RC2}}. The STorM32 serial ports are named {{BOX|USB}}, {{BOX|UART}}, {{BOX|UART2}}, and {{BOX|UARTX}}, and are accessible in the GUI as {{PARAMVALUE|usb}}, {{PARAMVALUE|uart}}, {{PARAMVALUE|uart2}}, and {{PARAMVALUE|uartx}}. The pins corresponding to, e.g., the ports {{BOX|UART}} and {{BOX|UART2}} are labelled accordingly as Rx/Tx and Rx2/Tx2.<br />
<br />
UART1 is different. It is not a port like {{BOX|UART}} or {{BOX|UART2}}, and you won't find any parameter with the option {{PARAMVALUE|uart1}} in the GUI, yet the name "UART1" appears in various places, e.g. as Rx1/Tx1 labels on boards, or in pin descriptions, or in documentary.<br />
<br />
=== MCU Peripherals and Special Role of UART1 on v1.x, v3.3 Boards ===<br />
<br />
The microcontroller (MCU) which is used in the STorM32 controllers (STM32F103 or STM323H7A3) offers a number of hardware peripherals, among them the serial peripherals. These are generally called UARTx or USARTx, where x goes from 1 to 5 for e.g. the STM32F103RC chip (we will not distinguish between UARTx or USARTx but just call them UARTx). Note: This naming convention is a choice of the chip manufacturer, not ours. <br />
<br />
The names for the serial hardware peripherals must not be confused with the names of the serial ports of the STorM32 controller!<br />
<br />
For instance, on the v1.3x boards the serial port {{BOX|UART}} is the hardware peripheral UART3, while on the v3.3 and v4.1 boards it is the hardware peripheral UART5. From a user perspective this is however irrelevant, since all the user needs to know is that there is a serial port {{BOX|UART}} which can be selected in the GUI as {{PARAMVALUE|uart}}.<br />
<br />
The hardware peripheral UART1 is special, since it allows us to flash the firmware into the microcontroller of the v1.x and v3.3 boards, and it is used by STorM32 for exactly this purpose. Therefore, this peripheral is exposed on these STorM32 boards so we can flash the firmware using it, which is the reason for why one finds a UART1 port (or Rx1/Tx1 labels) on the v1.x and v3.3 boards.<br />
<br />
Unfortunately, the number of serial ports provided by v1.3x STorM32 boards is not sufficient for some applications. Therefore, on v1.3x boards one can use also the peripheral UART1 to fullfill the user's needs. In the STorM32 software, this is made possible, for some features, as {{BOX|UARTX}} port.<br />
<br />
=== Availability ===<br />
<br />
Concerning the availability of the serial ports (for STorM32 boards documented in this wik) one can note:<br />
<br />
* All STorM32 boards provide a {{BOX|UART}} port.<br />
<br />
* All "full-size" STorM32 boards provide a {{BOX|USB}} port (exception are some special designs such as micro boards). On the v1.3x and v6.x1 boards the USB connector is tied to the MCU's USB peripheral, whereas for the v3.3 and v4.1 boards it is connected via a on-board USB-TTL adapter to the UART1 peripheral.<br />
<br />
* The v3.3/v4.1/v6.x STorM32 boards provide a {{BOX|UART2}} serial on the {{BOX|UART2}} port or {{BOX|ESP}} port. The v1.x boards do not offer this serial (here the GUI setting {{PARAMVALUE|uart2}} has no effect).<br />
<br />
* All STorM32 boards provide the {{BOX|UARTX}} serial. It is found on the {{BOX|RC}} port, pins RC-0 and RC-1, and is accessible in the GUI as {{PARAMVALUE|uartx}}. In pictures of the v1.x board it is however labelled as UART1 and not UARTX.<br />
<br />
* On the v3.3 STorM32 board, the UART1 hardware peripheral is available as extra UART1 (Rx1/Tx1) port. On the v1.3x boards this peripheral is on the {{BOX|RC}} port, pins RC-0 and RC-1.<br />
<br />
{| class="wikitable"<br />
! Gui<br />
! v1.3x <br />
! v3.3/v4.1<br />
! v6.2/v6.3<br />
|-<br />
| {{PARAMVALUE|uart}} || {{BOX|UART}} port || {{BOX|UART}} port || {{BOX|UART}} port<br />
|-<br />
| {{PARAMVALUE|uart2}} || has no effect, {{BOX|UART2}} port not available || {{BOX|UART2}} port or on {{BOX|ESP}} port || {{BOX|UART2}} port<br />
|-<br />
| {{PARAMVALUE|usb}} || USB connector || USB connector or UART1 port<br>is equal to UART1 || USB connector<br />
|-<br />
| {{PARAMVALUE|uartx}} || RC-0,RC-1 pins on {{BOX|RC}} port<br>labeled UART1, is equal to UART1 || RC-0,RC-1 pins on {{BOX|RC}} port<br>labeled UARTX || RC-0,RC-1 pins on {{BOX|RC}} port<br>labeled UARTX<br />
|}<br />
<!--<br />
<br />
The naming of the STorM32's serial ports can be confusing. This article aims at providing some clarification.<br />
<br />
== Ports ==<br />
<br />
Generally one has to distinguish between the hardware peripherals provided by the STM32 micro-controller and their names, and the available serial ports and their naming. <br />
<br />
Unfortunately, there is some overlap in the naming, which certainly contributes to the confusion. Furthermore, some STorM32 serials may not be found on ports which are named accordingly, but on "other" ports. This mess is certainly unfortunate, but reflects the efforts to continually increase the STorM32's capabilities and satisfy user demands while keeping some backwards compatibility.<br />
<br />
The hardware peripherals are generally called UARTx or USARTx, where x goes from 1 to 5 for e.g. STM32F103 chips. We will not distinguish between UART or USART but just call them UARTx.<br />
<br />
Concerning the STorM32's serials, the general rule is that they are named {{BOX|USB}}, {{BOX|UART}}, {{BOX|UART2}}, and {{BOX|UARTX}}, and that these are accessible in the GUI as {{PARAMVALUE|usb}}, {{PARAMVALUE|uart}}, {{PARAMVALUE|uart2}}, and {{PARAMVALUE|uartx}}. These must not be confused with the STM32's peripherals UART1, UART2, UART3, and so on.<br />
<br />
Concerning the availability of the serials, one can note:<br />
<br />
* All STorM32 boards provide the {{BOX|UART}} port.<br />
<br />
* The STorM32 v3.x boards do provide a port labeled UART1, which is indeed the STM32 UART1 peripheral, and can be used for flashing firmware, but to the STorM32 firmware it is the {{BOX|USB}} port (accessible in the GUI as {{PARAMVALUE|usb}}). Some STorM32 v3.x boards provide in addition a physical USB connector, which is however just also UART1 (i.e. connected to UART1 with a USB-TTL adapter), with said function. On the STorM32 v1.x boards the {{BOX|USB}} port is indeed the physical USB connector, while the STM32's UART1 peripheral used for flashing firmware is available on the STorM32 {{BOX|RC}} port, pins RC-0 and RC-1.<br />
<br />
* On the STorM32 v3.x boards the {{BOX|UART2}} serial is either available as an explicit {{BOX|UART2}} port or via the {{BOX|ESP}} port. The v1.x boards do not offer this serial at all (for these boards the GUI setting {{PARAMVALUE|uart2}} has no effect).<br />
<br />
* On all STorM32 boards the {{BOX|UARTX}} serial is available on the {{BOX|RC}} port, pins RC-0 and RC-1 (accessible in the GUI as {{PARAMVALUE|uartx}}). In pictures of the v1.x board it is however indicated as UART1 and not UARTX (on these boards UARTX is in fact the STM32 UART1 peripheral).<br />
--><br />
<br />
== Baudrate ==<br />
<br />
The default baudrate is generally 115200 bps for all serial ports (including {{BOX|USB}} on the v3.3 and v4.1 boards).<br />
<br />
They can be adjusted for the {{BOX|USB}}, {{BOX|UART}}, {{BOX|UART2}} serial ports in the GUI. There is no possibility to adjust the baudrate of the {{BOX|UARTX}} serial port.<br />
<br />
{{COMMENT|The GUI per default also communicates with a baudrate of 115200 bps. It can be changed in the GUI.}}<br />
<br />
{{COMMENT|Changing the baudrate of a serial port can imply that one cannot connect to this port with the GUI anymore.}}</div>OlliWhttp://www.olliw.eu/storm32bgc-v2-wiki/index.php?title=Serial_Ports&diff=11903Serial Ports2025-11-21T18:33:43Z<p>OlliW: /* Availability */</p>
<hr />
<div>This article aims at providing some clarification concerning the STorM32's serial ports.<br />
<br />
<div class="toclimit-2">__TOC__</div><br />
<br />
== Ports ==<br />
<br />
The naming of the STorM32 serial ports may appear confusing at first. However, it is in fact pretty consistent, across all boards - with one (unfortunate) exception: UART1. <br />
<br />
Generally, the STorM32 port naming follows this scheme: The name of a port is simply the type of the port, plus a number (or symbol) for the 2nd port of that type, and so on. Example: {{BOX|RC}} and {{BOX|RC2}}. The STorM32 serial ports are named {{BOX|USB}}, {{BOX|UART}}, {{BOX|UART2}}, and {{BOX|UARTX}}, and are accessible in the GUI as {{PARAMVALUE|usb}}, {{PARAMVALUE|uart}}, {{PARAMVALUE|uart2}}, and {{PARAMVALUE|uartx}}. The pins corresponding to, e.g., the ports {{BOX|UART}} and {{BOX|UART2}} are labelled accordingly as Rx/Tx and Rx2/Tx2.<br />
<br />
UART1 is different. It is not a port like {{BOX|UART}} or {{BOX|UART2}}, and you won't find any parameter with the option {{PARAMVALUE|uart1}} in the GUI, yet the name "UART1" appears in various places, e.g. as Rx1/Tx1 labels on boards, or in pin descriptions, or in documentary.<br />
<br />
=== MCU Peripherals and Special Role of UART1 on v1.x, v3.3 Boards ===<br />
<br />
The microcontroller (MCU) which is used in the STorM32 controllers (STM32F103 or STM323H7A3) offers a number of hardware peripherals, among them the serial peripherals. These are generally called UARTx or USARTx, where x goes from 1 to 5 for e.g. the STM32F103RC chip (we will not distinguish between UARTx or USARTx but just call them UARTx). Note: This naming convention is a choice of the chip manufacturer, not ours. <br />
<br />
The names for the serial hardware peripherals must not be confused with the names of the serial ports of the STorM32 controller!<br />
<br />
For instance, on the v1.3x boards the serial port {{BOX|UART}} is the hardware peripheral UART3, while on the v3.3 and v4.1 boards it is the hardware peripheral UART5. From a user perspective this is however irrelevant, since all the user needs to know is that there is a serial port {{BOX|UART}} which can be selected in the GUI as {{PARAMVALUE|uart}}.<br />
<br />
The hardware peripheral UART1 is special, since it allows us to flash the firmware into the microcontroller of the v1.x and v3.3 boards, and it is used by STorM32 for exactly this purpose. Therefore, this peripheral is exposed on these STorM32 boards so we can flash the firmware using it, which is the reason for why one finds a UART1 port (or Rx1/Tx1 labels) on the v1.x and v3.3 boards.<br />
<br />
Unfortunately, the number of serial ports provided by v1.3x STorM32 boards is not sufficient for some applications. Therefore, on v1.3x boards one can use also the peripheral UART1 to fullfill the user's needs. In the STorM32 software, this is made possible, for some features, as {{BOX|UARTX}} port.<br />
<br />
=== Availability ===<br />
<br />
Concerning the availability of the serial ports (for STorM32 boards documented in this wik) one can note:<br />
<br />
* All STorM32 boards provide a {{BOX|UART}} port.<br />
<br />
* All "full-size" STorM32 boards provide a {{BOX|USB}} port (exception are some special designs such as micro boards). On the v1.3x and v6.x1 boards the USB connector is tied to the MCU's USB peripheral, whereas for the v3.3 and v4.1 boards it is connected via a on-board USB-TTL adapter to the UART1 peripheral.<br />
<br />
* The v3.3/v4.1/v6.x STorM32 boards provide a {{BOX|UART2}} serial on the {{BOX|UART2}} port or {{BOX|ESP}} port. The v1.x boards do not offer this serial (here the GUI setting {{PARAMVALUE|uart2}} has no effect).<br />
<br />
* All STorM32 boards provide the {{BOX|UARTX}} serial. It is found on the {{BOX|RC}} port, pins RC-0 and RC-1, and is accessible in the GUI as {{PARAMVALUE|uartx}}. In pictures of the v1.x board it is however labelled as UART1 and not UARTX.<br />
<br />
* On the v3.3 STorM32 board, the UART1 hardware peripheral is available as extra UART1 (Rx1/Tx1) port. On the v1.3x boards this peripheral is on the {{BOX|RC}} port, pins RC-0 and RC-1.<br />
<br />
{| class="wikitable"<br />
! Gui<br />
! v1.3x <br />
! v3.3/v4.1<br />
! v6.2/v6.3<br />
|-<br />
| {{PARAMVALUE|uart}} || {{BOX|UART}} port || {{BOX|UART}} port || {{BOX|UART}} port<br />
|-<br />
| {{PARAMVALUE|uart2}} || has no effect, {{BOX|UART2}} port not available || {{BOX|UART2}} port or on {{BOX|ESP}} port || {{BOX|UART2}} port<br />
|-<br />
| {{PARAMVALUE|usb}} || USB connector || USB connector or UART1 port<br>is equal to UART1 || USB connector<br />
|-<br />
| {{PARAMVALUE|uartx}} || RC-0,RC-1 pins on {{BOX|RC}} port<br>is equal to UART1, labeled UART1 || RC-0,RC-1 pins on {{BOX|RC}} port<br>labeled UARTX || RC-0,RC-1 pins on {{BOX|RC}} port<br>labeled UARTX<br />
|}<br />
<!--<br />
<br />
The naming of the STorM32's serial ports can be confusing. This article aims at providing some clarification.<br />
<br />
== Ports ==<br />
<br />
Generally one has to distinguish between the hardware peripherals provided by the STM32 micro-controller and their names, and the available serial ports and their naming. <br />
<br />
Unfortunately, there is some overlap in the naming, which certainly contributes to the confusion. Furthermore, some STorM32 serials may not be found on ports which are named accordingly, but on "other" ports. This mess is certainly unfortunate, but reflects the efforts to continually increase the STorM32's capabilities and satisfy user demands while keeping some backwards compatibility.<br />
<br />
The hardware peripherals are generally called UARTx or USARTx, where x goes from 1 to 5 for e.g. STM32F103 chips. We will not distinguish between UART or USART but just call them UARTx.<br />
<br />
Concerning the STorM32's serials, the general rule is that they are named {{BOX|USB}}, {{BOX|UART}}, {{BOX|UART2}}, and {{BOX|UARTX}}, and that these are accessible in the GUI as {{PARAMVALUE|usb}}, {{PARAMVALUE|uart}}, {{PARAMVALUE|uart2}}, and {{PARAMVALUE|uartx}}. These must not be confused with the STM32's peripherals UART1, UART2, UART3, and so on.<br />
<br />
Concerning the availability of the serials, one can note:<br />
<br />
* All STorM32 boards provide the {{BOX|UART}} port.<br />
<br />
* The STorM32 v3.x boards do provide a port labeled UART1, which is indeed the STM32 UART1 peripheral, and can be used for flashing firmware, but to the STorM32 firmware it is the {{BOX|USB}} port (accessible in the GUI as {{PARAMVALUE|usb}}). Some STorM32 v3.x boards provide in addition a physical USB connector, which is however just also UART1 (i.e. connected to UART1 with a USB-TTL adapter), with said function. On the STorM32 v1.x boards the {{BOX|USB}} port is indeed the physical USB connector, while the STM32's UART1 peripheral used for flashing firmware is available on the STorM32 {{BOX|RC}} port, pins RC-0 and RC-1.<br />
<br />
* On the STorM32 v3.x boards the {{BOX|UART2}} serial is either available as an explicit {{BOX|UART2}} port or via the {{BOX|ESP}} port. The v1.x boards do not offer this serial at all (for these boards the GUI setting {{PARAMVALUE|uart2}} has no effect).<br />
<br />
* On all STorM32 boards the {{BOX|UARTX}} serial is available on the {{BOX|RC}} port, pins RC-0 and RC-1 (accessible in the GUI as {{PARAMVALUE|uartx}}). In pictures of the v1.x board it is however indicated as UART1 and not UARTX (on these boards UARTX is in fact the STM32 UART1 peripheral).<br />
--><br />
<br />
== Baudrate ==<br />
<br />
The default baudrate is generally 115200 bps for all serial ports (including {{BOX|USB}} on the v3.3 and v4.1 boards).<br />
<br />
They can be adjusted for the {{BOX|USB}}, {{BOX|UART}}, {{BOX|UART2}} serial ports in the GUI. There is no possibility to adjust the baudrate of the {{BOX|UARTX}} serial port.<br />
<br />
{{COMMENT|The GUI per default also communicates with a baudrate of 115200 bps. It can be changed in the GUI.}}<br />
<br />
{{COMMENT|Changing the baudrate of a serial port can imply that one cannot connect to this port with the GUI anymore.}}</div>OlliWhttp://www.olliw.eu/storm32bgc-v2-wiki/index.php?title=Serial_Ports&diff=11902Serial Ports2025-11-21T18:33:11Z<p>OlliW: /* Availability */</p>
<hr />
<div>This article aims at providing some clarification concerning the STorM32's serial ports.<br />
<br />
<div class="toclimit-2">__TOC__</div><br />
<br />
== Ports ==<br />
<br />
The naming of the STorM32 serial ports may appear confusing at first. However, it is in fact pretty consistent, across all boards - with one (unfortunate) exception: UART1. <br />
<br />
Generally, the STorM32 port naming follows this scheme: The name of a port is simply the type of the port, plus a number (or symbol) for the 2nd port of that type, and so on. Example: {{BOX|RC}} and {{BOX|RC2}}. The STorM32 serial ports are named {{BOX|USB}}, {{BOX|UART}}, {{BOX|UART2}}, and {{BOX|UARTX}}, and are accessible in the GUI as {{PARAMVALUE|usb}}, {{PARAMVALUE|uart}}, {{PARAMVALUE|uart2}}, and {{PARAMVALUE|uartx}}. The pins corresponding to, e.g., the ports {{BOX|UART}} and {{BOX|UART2}} are labelled accordingly as Rx/Tx and Rx2/Tx2.<br />
<br />
UART1 is different. It is not a port like {{BOX|UART}} or {{BOX|UART2}}, and you won't find any parameter with the option {{PARAMVALUE|uart1}} in the GUI, yet the name "UART1" appears in various places, e.g. as Rx1/Tx1 labels on boards, or in pin descriptions, or in documentary.<br />
<br />
=== MCU Peripherals and Special Role of UART1 on v1.x, v3.3 Boards ===<br />
<br />
The microcontroller (MCU) which is used in the STorM32 controllers (STM32F103 or STM323H7A3) offers a number of hardware peripherals, among them the serial peripherals. These are generally called UARTx or USARTx, where x goes from 1 to 5 for e.g. the STM32F103RC chip (we will not distinguish between UARTx or USARTx but just call them UARTx). Note: This naming convention is a choice of the chip manufacturer, not ours. <br />
<br />
The names for the serial hardware peripherals must not be confused with the names of the serial ports of the STorM32 controller!<br />
<br />
For instance, on the v1.3x boards the serial port {{BOX|UART}} is the hardware peripheral UART3, while on the v3.3 and v4.1 boards it is the hardware peripheral UART5. From a user perspective this is however irrelevant, since all the user needs to know is that there is a serial port {{BOX|UART}} which can be selected in the GUI as {{PARAMVALUE|uart}}.<br />
<br />
The hardware peripheral UART1 is special, since it allows us to flash the firmware into the microcontroller of the v1.x and v3.3 boards, and it is used by STorM32 for exactly this purpose. Therefore, this peripheral is exposed on these STorM32 boards so we can flash the firmware using it, which is the reason for why one finds a UART1 port (or Rx1/Tx1 labels) on the v1.x and v3.3 boards.<br />
<br />
Unfortunately, the number of serial ports provided by v1.3x STorM32 boards is not sufficient for some applications. Therefore, on v1.3x boards one can use also the peripheral UART1 to fullfill the user's needs. In the STorM32 software, this is made possible, for some features, as {{BOX|UARTX}} port.<br />
<br />
=== Availability ===<br />
<br />
Concerning the availability of the serial ports (for STorM32 boards documented in this wik) one can note:<br />
<br />
* All STorM32 boards provide a {{BOX|UART}} port.<br />
<br />
* All "full-size" STorM32 boards provide a {{BOX|USB}} port (exception are some special designs such as micro boards). On the v1.3x and v6.x1 boards the USB connector is tied to the MCU's USB peripheral, whereas for the v3.3 and v4.1 boards it is connected via a on-board USB-TTL adapter to the UART1 peripheral.<br />
<br />
* The v3.3/v4.1/v6.x STorM32 boards provide a {{BOX|UART2}} serial on the {{BOX|UART2}} port or {{BOX|ESP}} port. The v1.x boards do not offer this serial (here the GUI setting {{PARAMVALUE|uart2}} has no effect).<br />
<br />
* All STorM32 boards provide the {{BOX|UARTX}} serial. It is found on the {{BOX|RC}} port, pins RC-0 and RC-1, and is accessible in the GUI as {{PARAMVALUE|uartx}}. In pictures of the v1.x board it is however labelled as UART1 and not UARTX.<br />
<br />
* On the v3.3 STorM32 board, the UART1 hardware peripheral is available as extra UART1 (Rx1/Tx1) port. On the v1.3x boards this peripheral is on the {{BOX|RC}} port, pins RC-0 and RC-1.<br />
<br />
{| class="wikitable"<br />
! Gui<br />
! v1.3x <br />
! v3.3/v4.1<br />
! v6.2/v6.3<br />
|-<br />
| {{PARAMVALUE|uart}} || {{BOX|UART}} port || {{BOX|UART}} port || {{BOX|UART}} port<br />
|-<br />
| {{PARAMVALUE|uart2}} || has no effect, {{BOX|UART2}} port not available || {{BOX|UART2}} port or on {{BOX|ESP}} port || {{BOX|UART2}} port or on {{BOX|ESP}} port<br />
|-<br />
| {{PARAMVALUE|usb}} || USB connector || USB connector or UART1 port<br>is equal to UART1 || USB connector<br />
|-<br />
| {{PARAMVALUE|uartx}} || RC-0,RC-1 pins on {{BOX|RC}} port<br>is equal to UART1, labeled UART1 || RC-0,RC-1 pins on {{BOX|RC}} port<br>labeled UARTX || RC-0,RC-1 pins on {{BOX|RC}} port<br>labeled UARTX<br />
|}<br />
<!--<br />
<br />
The naming of the STorM32's serial ports can be confusing. This article aims at providing some clarification.<br />
<br />
== Ports ==<br />
<br />
Generally one has to distinguish between the hardware peripherals provided by the STM32 micro-controller and their names, and the available serial ports and their naming. <br />
<br />
Unfortunately, there is some overlap in the naming, which certainly contributes to the confusion. Furthermore, some STorM32 serials may not be found on ports which are named accordingly, but on "other" ports. This mess is certainly unfortunate, but reflects the efforts to continually increase the STorM32's capabilities and satisfy user demands while keeping some backwards compatibility.<br />
<br />
The hardware peripherals are generally called UARTx or USARTx, where x goes from 1 to 5 for e.g. STM32F103 chips. We will not distinguish between UART or USART but just call them UARTx.<br />
<br />
Concerning the STorM32's serials, the general rule is that they are named {{BOX|USB}}, {{BOX|UART}}, {{BOX|UART2}}, and {{BOX|UARTX}}, and that these are accessible in the GUI as {{PARAMVALUE|usb}}, {{PARAMVALUE|uart}}, {{PARAMVALUE|uart2}}, and {{PARAMVALUE|uartx}}. These must not be confused with the STM32's peripherals UART1, UART2, UART3, and so on.<br />
<br />
Concerning the availability of the serials, one can note:<br />
<br />
* All STorM32 boards provide the {{BOX|UART}} port.<br />
<br />
* The STorM32 v3.x boards do provide a port labeled UART1, which is indeed the STM32 UART1 peripheral, and can be used for flashing firmware, but to the STorM32 firmware it is the {{BOX|USB}} port (accessible in the GUI as {{PARAMVALUE|usb}}). Some STorM32 v3.x boards provide in addition a physical USB connector, which is however just also UART1 (i.e. connected to UART1 with a USB-TTL adapter), with said function. On the STorM32 v1.x boards the {{BOX|USB}} port is indeed the physical USB connector, while the STM32's UART1 peripheral used for flashing firmware is available on the STorM32 {{BOX|RC}} port, pins RC-0 and RC-1.<br />
<br />
* On the STorM32 v3.x boards the {{BOX|UART2}} serial is either available as an explicit {{BOX|UART2}} port or via the {{BOX|ESP}} port. The v1.x boards do not offer this serial at all (for these boards the GUI setting {{PARAMVALUE|uart2}} has no effect).<br />
<br />
* On all STorM32 boards the {{BOX|UARTX}} serial is available on the {{BOX|RC}} port, pins RC-0 and RC-1 (accessible in the GUI as {{PARAMVALUE|uartx}}). In pictures of the v1.x board it is however indicated as UART1 and not UARTX (on these boards UARTX is in fact the STM32 UART1 peripheral).<br />
--><br />
<br />
== Baudrate ==<br />
<br />
The default baudrate is generally 115200 bps for all serial ports (including {{BOX|USB}} on the v3.3 and v4.1 boards).<br />
<br />
They can be adjusted for the {{BOX|USB}}, {{BOX|UART}}, {{BOX|UART2}} serial ports in the GUI. There is no possibility to adjust the baudrate of the {{BOX|UARTX}} serial port.<br />
<br />
{{COMMENT|The GUI per default also communicates with a baudrate of 115200 bps. It can be changed in the GUI.}}<br />
<br />
{{COMMENT|Changing the baudrate of a serial port can imply that one cannot connect to this port with the GUI anymore.}}</div>OlliWhttp://www.olliw.eu/storm32bgc-v2-wiki/index.php?title=Serial_Ports&diff=11901Serial Ports2025-11-21T18:28:55Z<p>OlliW: /* Availability */</p>
<hr />
<div>This article aims at providing some clarification concerning the STorM32's serial ports.<br />
<br />
<div class="toclimit-2">__TOC__</div><br />
<br />
== Ports ==<br />
<br />
The naming of the STorM32 serial ports may appear confusing at first. However, it is in fact pretty consistent, across all boards - with one (unfortunate) exception: UART1. <br />
<br />
Generally, the STorM32 port naming follows this scheme: The name of a port is simply the type of the port, plus a number (or symbol) for the 2nd port of that type, and so on. Example: {{BOX|RC}} and {{BOX|RC2}}. The STorM32 serial ports are named {{BOX|USB}}, {{BOX|UART}}, {{BOX|UART2}}, and {{BOX|UARTX}}, and are accessible in the GUI as {{PARAMVALUE|usb}}, {{PARAMVALUE|uart}}, {{PARAMVALUE|uart2}}, and {{PARAMVALUE|uartx}}. The pins corresponding to, e.g., the ports {{BOX|UART}} and {{BOX|UART2}} are labelled accordingly as Rx/Tx and Rx2/Tx2.<br />
<br />
UART1 is different. It is not a port like {{BOX|UART}} or {{BOX|UART2}}, and you won't find any parameter with the option {{PARAMVALUE|uart1}} in the GUI, yet the name "UART1" appears in various places, e.g. as Rx1/Tx1 labels on boards, or in pin descriptions, or in documentary.<br />
<br />
=== MCU Peripherals and Special Role of UART1 on v1.x, v3.3 Boards ===<br />
<br />
The microcontroller (MCU) which is used in the STorM32 controllers (STM32F103 or STM323H7A3) offers a number of hardware peripherals, among them the serial peripherals. These are generally called UARTx or USARTx, where x goes from 1 to 5 for e.g. the STM32F103RC chip (we will not distinguish between UARTx or USARTx but just call them UARTx). Note: This naming convention is a choice of the chip manufacturer, not ours. <br />
<br />
The names for the serial hardware peripherals must not be confused with the names of the serial ports of the STorM32 controller!<br />
<br />
For instance, on the v1.3x boards the serial port {{BOX|UART}} is the hardware peripheral UART3, while on the v3.3 and v4.1 boards it is the hardware peripheral UART5. From a user perspective this is however irrelevant, since all the user needs to know is that there is a serial port {{BOX|UART}} which can be selected in the GUI as {{PARAMVALUE|uart}}.<br />
<br />
The hardware peripheral UART1 is special, since it allows us to flash the firmware into the microcontroller of the v1.x and v3.3 boards, and it is used by STorM32 for exactly this purpose. Therefore, this peripheral is exposed on these STorM32 boards so we can flash the firmware using it, which is the reason for why one finds a UART1 port (or Rx1/Tx1 labels) on the v1.x and v3.3 boards.<br />
<br />
Unfortunately, the number of serial ports provided by v1.3x STorM32 boards is not sufficient for some applications. Therefore, on v1.3x boards one can use also the peripheral UART1 to fullfill the user's needs. In the STorM32 software, this is made possible, for some features, as {{BOX|UARTX}} port.<br />
<br />
=== Availability ===<br />
<br />
Concerning the availability of the serial ports (for STorM32 boards documented in this wik) one can note:<br />
<br />
* All STorM32 boards provide the {{BOX|UART}} port.<br />
<br />
* All "full-size" STorM32 boards provide the {{BOX|USB}} port (exception are some special designs such as micro boards). On the v1.3x and v6.x1 boards the USB connector is tied to the MCUs USB peripheral, whereas for the v3.3 and v4.1 boards it is connected via a on-board USB-TTL adapter to the UART1 peripheral. <br />
<br />
* The v3.3/v4.1/v6.x STorM32 boards provide the {{BOX|UART2}} serial on the {{BOX|UART2}} port or {{BOX|ESP}} port. The v1.x boards do not offer this serial (here the GUI setting {{PARAMVALUE|uart2}} has no effect).<br />
<br />
* All STorM32 boards offer the {{BOX|UARTX}} serial, which is found on the {{BOX|RC}} port, pins RC-0 and RC-1, and is accessible in the GUI as {{PARAMVALUE|uartx}}. In pictures of the v1.x board it is however labelled as UART1 and not UARTX.<br />
<br />
* The v3.3 STorM32 boards provide a port labeled UART1 (Rx1/Tx1), which is indeed the UART1 hardware peripheral. Some v3.3 also provide a physical USB connector, which is however just again the UART1 peripheral (tied together via a on-board USB-TTL adapter). The UART1 port or USB connector is accessible in the GUI as {{PARAMVALUE|usb}}, i.e., this is the {{BOX|USB}} port. <br />
<br />
{| class="wikitable"<br />
! Gui<br />
! v1.3x <br />
! v3.3/v4.1<br />
! v6.2/v6.3<br />
|-<br />
| {{PARAMVALUE|uart}} || {{BOX|UART}} port || {{BOX|UART}} port || {{BOX|UART}} port<br />
|-<br />
| {{PARAMVALUE|uart2}} || has no effect, {{BOX|UART2}} port not available || {{BOX|UART2}} port or on {{BOX|ESP}} port || {{BOX|UART2}} port or on {{BOX|ESP}} port<br />
|-<br />
| {{PARAMVALUE|usb}} || USB connector || USB connector or UART1 port<br>is equal to UART1 || USB connector<br />
|-<br />
| {{PARAMVALUE|uartx}} || RC-0,RC-1 pins on {{BOX|RC}} port<br>is equal to UART1, labeled UART1 || RC-0,RC-1 pins on {{BOX|RC}} port<br>labeled UARTX || RC-0,RC-1 pins on {{BOX|RC}} port<br>labeled UARTX<br />
|}<br />
<!--<br />
<br />
The naming of the STorM32's serial ports can be confusing. This article aims at providing some clarification.<br />
<br />
== Ports ==<br />
<br />
Generally one has to distinguish between the hardware peripherals provided by the STM32 micro-controller and their names, and the available serial ports and their naming. <br />
<br />
Unfortunately, there is some overlap in the naming, which certainly contributes to the confusion. Furthermore, some STorM32 serials may not be found on ports which are named accordingly, but on "other" ports. This mess is certainly unfortunate, but reflects the efforts to continually increase the STorM32's capabilities and satisfy user demands while keeping some backwards compatibility.<br />
<br />
The hardware peripherals are generally called UARTx or USARTx, where x goes from 1 to 5 for e.g. STM32F103 chips. We will not distinguish between UART or USART but just call them UARTx.<br />
<br />
Concerning the STorM32's serials, the general rule is that they are named {{BOX|USB}}, {{BOX|UART}}, {{BOX|UART2}}, and {{BOX|UARTX}}, and that these are accessible in the GUI as {{PARAMVALUE|usb}}, {{PARAMVALUE|uart}}, {{PARAMVALUE|uart2}}, and {{PARAMVALUE|uartx}}. These must not be confused with the STM32's peripherals UART1, UART2, UART3, and so on.<br />
<br />
Concerning the availability of the serials, one can note:<br />
<br />
* All STorM32 boards provide the {{BOX|UART}} port.<br />
<br />
* The STorM32 v3.x boards do provide a port labeled UART1, which is indeed the STM32 UART1 peripheral, and can be used for flashing firmware, but to the STorM32 firmware it is the {{BOX|USB}} port (accessible in the GUI as {{PARAMVALUE|usb}}). Some STorM32 v3.x boards provide in addition a physical USB connector, which is however just also UART1 (i.e. connected to UART1 with a USB-TTL adapter), with said function. On the STorM32 v1.x boards the {{BOX|USB}} port is indeed the physical USB connector, while the STM32's UART1 peripheral used for flashing firmware is available on the STorM32 {{BOX|RC}} port, pins RC-0 and RC-1.<br />
<br />
* On the STorM32 v3.x boards the {{BOX|UART2}} serial is either available as an explicit {{BOX|UART2}} port or via the {{BOX|ESP}} port. The v1.x boards do not offer this serial at all (for these boards the GUI setting {{PARAMVALUE|uart2}} has no effect).<br />
<br />
* On all STorM32 boards the {{BOX|UARTX}} serial is available on the {{BOX|RC}} port, pins RC-0 and RC-1 (accessible in the GUI as {{PARAMVALUE|uartx}}). In pictures of the v1.x board it is however indicated as UART1 and not UARTX (on these boards UARTX is in fact the STM32 UART1 peripheral).<br />
--><br />
<br />
== Baudrate ==<br />
<br />
The default baudrate is generally 115200 bps for all serial ports (including {{BOX|USB}} on the v3.3 and v4.1 boards).<br />
<br />
They can be adjusted for the {{BOX|USB}}, {{BOX|UART}}, {{BOX|UART2}} serial ports in the GUI. There is no possibility to adjust the baudrate of the {{BOX|UARTX}} serial port.<br />
<br />
{{COMMENT|The GUI per default also communicates with a baudrate of 115200 bps. It can be changed in the GUI.}}<br />
<br />
{{COMMENT|Changing the baudrate of a serial port can imply that one cannot connect to this port with the GUI anymore.}}</div>OlliWhttp://www.olliw.eu/storm32bgc-v2-wiki/index.php?title=Serial_Ports&diff=11900Serial Ports2025-11-21T18:16:47Z<p>OlliW: /* MCU Peripherals and Special Role of UART1 */</p>
<hr />
<div>This article aims at providing some clarification concerning the STorM32's serial ports.<br />
<br />
<div class="toclimit-2">__TOC__</div><br />
<br />
== Ports ==<br />
<br />
The naming of the STorM32 serial ports may appear confusing at first. However, it is in fact pretty consistent, across all boards - with one (unfortunate) exception: UART1. <br />
<br />
Generally, the STorM32 port naming follows this scheme: The name of a port is simply the type of the port, plus a number (or symbol) for the 2nd port of that type, and so on. Example: {{BOX|RC}} and {{BOX|RC2}}. The STorM32 serial ports are named {{BOX|USB}}, {{BOX|UART}}, {{BOX|UART2}}, and {{BOX|UARTX}}, and are accessible in the GUI as {{PARAMVALUE|usb}}, {{PARAMVALUE|uart}}, {{PARAMVALUE|uart2}}, and {{PARAMVALUE|uartx}}. The pins corresponding to, e.g., the ports {{BOX|UART}} and {{BOX|UART2}} are labelled accordingly as Rx/Tx and Rx2/Tx2.<br />
<br />
UART1 is different. It is not a port like {{BOX|UART}} or {{BOX|UART2}}, and you won't find any parameter with the option {{PARAMVALUE|uart1}} in the GUI, yet the name "UART1" appears in various places, e.g. as Rx1/Tx1 labels on boards, or in pin descriptions, or in documentary.<br />
<br />
=== MCU Peripherals and Special Role of UART1 on v1.x, v3.3 Boards ===<br />
<br />
The microcontroller (MCU) which is used in the STorM32 controllers (STM32F103 or STM323H7A3) offers a number of hardware peripherals, among them the serial peripherals. These are generally called UARTx or USARTx, where x goes from 1 to 5 for e.g. the STM32F103RC chip (we will not distinguish between UARTx or USARTx but just call them UARTx). Note: This naming convention is a choice of the chip manufacturer, not ours. <br />
<br />
The names for the serial hardware peripherals must not be confused with the names of the serial ports of the STorM32 controller!<br />
<br />
For instance, on the v1.3x boards the serial port {{BOX|UART}} is the hardware peripheral UART3, while on the v3.3 and v4.1 boards it is the hardware peripheral UART5. From a user perspective this is however irrelevant, since all the user needs to know is that there is a serial port {{BOX|UART}} which can be selected in the GUI as {{PARAMVALUE|uart}}.<br />
<br />
The hardware peripheral UART1 is special, since it allows us to flash the firmware into the microcontroller of the v1.x and v3.3 boards, and it is used by STorM32 for exactly this purpose. Therefore, this peripheral is exposed on these STorM32 boards so we can flash the firmware using it, which is the reason for why one finds a UART1 port (or Rx1/Tx1 labels) on the v1.x and v3.3 boards.<br />
<br />
Unfortunately, the number of serial ports provided by v1.3x STorM32 boards is not sufficient for some applications. Therefore, on v1.3x boards one can use also the peripheral UART1 to fullfill the user's needs. In the STorM32 software, this is made possible, for some features, as {{BOX|UARTX}} port.<br />
<br />
=== Availability ===<br />
<br />
Concerning the availability of the serial ports (for STorM32 boards documented in this wik) one can note:<br />
<br />
* All STorM32 boards provide the {{BOX|UART}} port.<br />
<br />
* The v3.3/v4.1 STorM32 boards do provide a port labeled UART1 (Rx1/Tx1), which is indeed the UART1 hardware peripheral. Some v3.3 and the v4.1 boards do also provide a physical USB connector, which is however just again the UART1 peripheral (tied together via a on-board USB-TTL adapter). The UART1 port or USB connector is accessible in the GUI as {{PARAMVALUE|usb}}, i.e., this is the {{BOX|USB}} port. <br />
<br />
* On the STorM32 v1.x boards the {{BOX|USB}} serial is indeed the USB connector. The UART1 hardware peripheral, used e.g. for flashing firmware, is available on these boards on the {{BOX|RC}} port, as pins RC-0 and RC-1.<br />
<br />
* On the v3.3/v4.1 STorM32 boards the {{BOX|UART2}} serial is either available as an explicit {{BOX|UART2}} port or via the {{BOX|ESP}} port. The v1.x boards do not offer this serial at all (for these boards the GUI setting {{PARAMVALUE|uart2}} has no effect).<br />
<br />
* On all STorM32 boards the {{BOX|UARTX}} serial is available on the {{BOX|RC}} port, pins RC-0 and RC-1 (accessible in the GUI as {{PARAMVALUE|uartx}}). In pictures of the v1.x board one however finds it indicated as UART1 and not UARTX (on these boards {{BOX|UARTX}} is in fact the UART1 peripheral).<br />
<br />
{| class="wikitable"<br />
! Gui<br />
! v1.3x <br />
! v3.3/v4.1<br />
! v6.2/v6.3<br />
|-<br />
| {{PARAMVALUE|uart}} || {{BOX|UART}} port || {{BOX|UART}} port || {{BOX|UART}} port<br />
|-<br />
| {{PARAMVALUE|uart2}} || has no effect, {{BOX|UART2}} port not available || {{BOX|UART2}} port or on {{BOX|ESP}} port || {{BOX|UART2}} port or on {{BOX|ESP}} port<br />
|-<br />
| {{PARAMVALUE|usb}} || USB connector || USB connector or UART1 port<br>is equal to UART1 || USB connector<br />
|-<br />
| {{PARAMVALUE|uartx}} || RC-0,RC-1 pins on {{BOX|RC}} port<br>is equal to UART1, labeled UART1 || RC-0,RC-1 pins on {{BOX|RC}} port<br>labeled UARTX || RC-0,RC-1 pins on {{BOX|RC}} port<br>labeled UARTX<br />
|}<br />
<!--<br />
<br />
The naming of the STorM32's serial ports can be confusing. This article aims at providing some clarification.<br />
<br />
== Ports ==<br />
<br />
Generally one has to distinguish between the hardware peripherals provided by the STM32 micro-controller and their names, and the available serial ports and their naming. <br />
<br />
Unfortunately, there is some overlap in the naming, which certainly contributes to the confusion. Furthermore, some STorM32 serials may not be found on ports which are named accordingly, but on "other" ports. This mess is certainly unfortunate, but reflects the efforts to continually increase the STorM32's capabilities and satisfy user demands while keeping some backwards compatibility.<br />
<br />
The hardware peripherals are generally called UARTx or USARTx, where x goes from 1 to 5 for e.g. STM32F103 chips. We will not distinguish between UART or USART but just call them UARTx.<br />
<br />
Concerning the STorM32's serials, the general rule is that they are named {{BOX|USB}}, {{BOX|UART}}, {{BOX|UART2}}, and {{BOX|UARTX}}, and that these are accessible in the GUI as {{PARAMVALUE|usb}}, {{PARAMVALUE|uart}}, {{PARAMVALUE|uart2}}, and {{PARAMVALUE|uartx}}. These must not be confused with the STM32's peripherals UART1, UART2, UART3, and so on.<br />
<br />
Concerning the availability of the serials, one can note:<br />
<br />
* All STorM32 boards provide the {{BOX|UART}} port.<br />
<br />
* The STorM32 v3.x boards do provide a port labeled UART1, which is indeed the STM32 UART1 peripheral, and can be used for flashing firmware, but to the STorM32 firmware it is the {{BOX|USB}} port (accessible in the GUI as {{PARAMVALUE|usb}}). Some STorM32 v3.x boards provide in addition a physical USB connector, which is however just also UART1 (i.e. connected to UART1 with a USB-TTL adapter), with said function. On the STorM32 v1.x boards the {{BOX|USB}} port is indeed the physical USB connector, while the STM32's UART1 peripheral used for flashing firmware is available on the STorM32 {{BOX|RC}} port, pins RC-0 and RC-1.<br />
<br />
* On the STorM32 v3.x boards the {{BOX|UART2}} serial is either available as an explicit {{BOX|UART2}} port or via the {{BOX|ESP}} port. The v1.x boards do not offer this serial at all (for these boards the GUI setting {{PARAMVALUE|uart2}} has no effect).<br />
<br />
* On all STorM32 boards the {{BOX|UARTX}} serial is available on the {{BOX|RC}} port, pins RC-0 and RC-1 (accessible in the GUI as {{PARAMVALUE|uartx}}). In pictures of the v1.x board it is however indicated as UART1 and not UARTX (on these boards UARTX is in fact the STM32 UART1 peripheral).<br />
--><br />
<br />
== Baudrate ==<br />
<br />
The default baudrate is generally 115200 bps for all serial ports (including {{BOX|USB}} on the v3.3 and v4.1 boards).<br />
<br />
They can be adjusted for the {{BOX|USB}}, {{BOX|UART}}, {{BOX|UART2}} serial ports in the GUI. There is no possibility to adjust the baudrate of the {{BOX|UARTX}} serial port.<br />
<br />
{{COMMENT|The GUI per default also communicates with a baudrate of 115200 bps. It can be changed in the GUI.}}<br />
<br />
{{COMMENT|Changing the baudrate of a serial port can imply that one cannot connect to this port with the GUI anymore.}}</div>OlliWhttp://www.olliw.eu/storm32bgc-v2-wiki/index.php?title=Downloads&diff=11899Downloads2025-11-20T07:02:48Z<p>OlliW: </p>
<hr />
<div>{{ALERT| '''PLEASE READ THIS FIRST''' <br />
There are 2 types of IMU modules which STorM32 v1.3x controllers can use, NT IMUs and I2C IMUs, and there are 2 firmwares which correspond to each type. It is important to choose the correct firmware, otherwise your controller and gimbal will not work. Read this page to understand the difference between the two types of IMUs [[//www.olliw.eu/storm32bgc-v2-wiki/What_is_STorM32_NT_about%3F]], and this post to identify your IMU [[//www.rcgroups.com/forums/showpost.php?p=38258334&postcount=10256]]. <br />
<br />
The STorM32 v3.x, v4.x, v6.x controllers can only use NT IMUs, not I2C IMUs.<br />
<br />
Only firmwares with version v0.96 or less work with I2C IMUs. Firmwares with version numbers v2.xx are not usable for setups with I2C IMU. If you do not know what a NT IMU is, then you likely have a I2C IMU and need firmware v0.96.}}<br />
<br/><br />
{{ALERT| '''ANNOUNCEMENTS'''<br />
- The v2.xx firmware series will phase out, i.e., currently it is planned that firmware 2.74 is the last release in this series. <br/><br />
- Development will shift to [//www.olliw.eu/storm32bgc-wiki STorM32 v3]. STorM32 v3 will not support the old and tried v1.3x boards, as well as not the v3.3 and v4.1 boards. Reason is that the STM32F103 microcontroller used on these boards has simply become too limited.<br />
<!--- Support of the v1.3x STorM32 boards will phase out. That is, the next official release (whenever this will be), will be the last release which supports these old and tried main boards. Reason is that since few years I have migrated to the STM32 HAL&LL libraries, but the v1.3x code is still on the legacy SPL library since it's I2C is ca 50-100 us faster than the HAL I2C lib. So I maintain two codes, which is obviously not sustainable.<br />
- Support for quite a number of presumably "old" cameras will phase out. Some of them are so old that it's hard to imagine they are still in use. Examples are Git2, Mapir Survey, Firefly Split 4K, Runcam, GoPro Hero5&7.-->}}<br />
<br />
== v2.xx Firmware for NT IMUs ==<br />
<br />
Firmware for STorM32 setups using a NT camera IMU. <br />
<br />
<br />
Direct link to v2.53 firmware download (this firmware is pretty old, it is highly recommended to use v2.67e):<br> <br />
<br />
:[//github.com/olliw42/storm32bgc/raw/main/firmware%20binaries%20%26%20gui/o323bgc-release-v253-v20200517.zip o323bgc-release-v253-v20200517] [.zip] (12.2 MB)<br />
:[//www.rcgroups.com/forums/showpost.php?p=44539519&postcount=12349 Release Notes]<br />
<br />
<br />
Latest beta release v2.73e:<br><br />
:[//github.com/olliw42/storm32bgc/raw/main/firmware%20binaries%20%26%20gui/o323bgc-release-v273e-v20250711.zip o323bgc-release-v273e-v20250711] [.zip] (15.9 MB)<br />
:[https://www.rcgroups.com/forums/showpost.php?p=53978973&postcount=15988 Release Notes]<br />
<br />
<br />
NTLoggerTool release v0.50:<br><br />
:[//www.olliw.eu/downloads/storm32/ntloggertool/ntloggertool-release-v050-v20231003.zip ntloggertool-release-v050-v20231003] [.zip] (295 MB)<br />
<br />
<br />
BetaCopter/BetaPlane 4.7-dev:<br><br />
:For downloading the firmwares and all further info please visit the article [[Using STorM32 with BetaPilot]].<br />
<br />
== v0.96 Firmware for I2C IMUs ==<br />
<br />
Firmware for STorM32 setups using a I2C camera IMU. Examples are the HakRC gimbal and other gimbals from Aliexpress.<br />
<br />
Latest firmware v0.96 for I2C IMUs:<br> <br />
:[//github.com/olliw42/storm32bgc/raw/master/firmware%20binaries%20%26%20gui/o323bgc-release-v096-v20160319.zip o323bgc-release-v096-v20160319] [.zip] (9.4MB)<br />
<br />
Note: This wiki here is not appropriate for v0.96 I2C setups, you should go to [//www.olliw.eu/storm32bgc-v1-wiki/Main_Page STorM32 v0.xx Wiki].<br />
<br />
{{COMMENT|The v0.96 release also includes firmwares for NT IMUs, identifiable by a label "nt" in the file names. Don't use them, use the v0.96 firmware (without a "nt" in the file name).}}<br />
<br />
== Repository ==<br />
<br />
Various files related to the STorM32-BGC project can be downloaded from several places:<br />
* [//github.com/olliw42/storm32bgc Github repository]<br />
* 1st page of the [//www.rcgroups.com/forums/showthread.php?t=2055844 rcgroups discussion thread]</div>OlliWhttp://www.olliw.eu/storm32bgc-v2-wiki/index.php?title=Downloads&diff=11898Downloads2025-11-20T07:02:37Z<p>OlliW: </p>
<hr />
<div>{{ALERT| '''PLEASE READ THIS FIRST''' <br />
There are 2 types of IMU modules which STorM32 v1.3x controllers can use, NT IMUs and I2C IMUs, and there are 2 firmwares which correspond to each type. It is important to choose the correct firmware, otherwise your controller and gimbal will not work. Read this page to understand the difference between the two types of IMUs [[//www.olliw.eu/storm32bgc-v2-wiki/What_is_STorM32_NT_about%3F]], and this post to identify your IMU [[//www.rcgroups.com/forums/showpost.php?p=38258334&postcount=10256]]. <br />
<br />
The STorM32 v3.x, v4.x, v6.x controllers can only use NT IMUs, not I2C IMUs.<br />
<br />
Only firmwares with version v0.96 or less work with I2C IMUs. Firmwares with version numbers v2.xx are not usable for setups with I2C IMU. If you do not know what a NT IMU is, then you likely have a I2C IMU and need firmware v0.96.}}<br/>{{ALERT| '''ANNOUNCEMENTS'''<br />
- The v2.xx firmware series will phase out, i.e., currently it is planned that firmware 2.74 is the last release in this series. <br/><br />
- Development will shift to [//www.olliw.eu/storm32bgc-wiki STorM32 v3]. STorM32 v3 will not support the old and tried v1.3x boards, as well as not the v3.3 and v4.1 boards. Reason is that the STM32F103 microcontroller used on these boards has simply become too limited.<br />
<!--- Support of the v1.3x STorM32 boards will phase out. That is, the next official release (whenever this will be), will be the last release which supports these old and tried main boards. Reason is that since few years I have migrated to the STM32 HAL&LL libraries, but the v1.3x code is still on the legacy SPL library since it's I2C is ca 50-100 us faster than the HAL I2C lib. So I maintain two codes, which is obviously not sustainable.<br />
- Support for quite a number of presumably "old" cameras will phase out. Some of them are so old that it's hard to imagine they are still in use. Examples are Git2, Mapir Survey, Firefly Split 4K, Runcam, GoPro Hero5&7.-->}}<br />
<br />
== v2.xx Firmware for NT IMUs ==<br />
<br />
Firmware for STorM32 setups using a NT camera IMU. <br />
<br />
<br />
Direct link to v2.53 firmware download (this firmware is pretty old, it is highly recommended to use v2.67e):<br> <br />
<br />
:[//github.com/olliw42/storm32bgc/raw/main/firmware%20binaries%20%26%20gui/o323bgc-release-v253-v20200517.zip o323bgc-release-v253-v20200517] [.zip] (12.2 MB)<br />
:[//www.rcgroups.com/forums/showpost.php?p=44539519&postcount=12349 Release Notes]<br />
<br />
<br />
Latest beta release v2.73e:<br><br />
:[//github.com/olliw42/storm32bgc/raw/main/firmware%20binaries%20%26%20gui/o323bgc-release-v273e-v20250711.zip o323bgc-release-v273e-v20250711] [.zip] (15.9 MB)<br />
:[https://www.rcgroups.com/forums/showpost.php?p=53978973&postcount=15988 Release Notes]<br />
<br />
<br />
NTLoggerTool release v0.50:<br><br />
:[//www.olliw.eu/downloads/storm32/ntloggertool/ntloggertool-release-v050-v20231003.zip ntloggertool-release-v050-v20231003] [.zip] (295 MB)<br />
<br />
<br />
BetaCopter/BetaPlane 4.7-dev:<br><br />
:For downloading the firmwares and all further info please visit the article [[Using STorM32 with BetaPilot]].<br />
<br />
== v0.96 Firmware for I2C IMUs ==<br />
<br />
Firmware for STorM32 setups using a I2C camera IMU. Examples are the HakRC gimbal and other gimbals from Aliexpress.<br />
<br />
Latest firmware v0.96 for I2C IMUs:<br> <br />
:[//github.com/olliw42/storm32bgc/raw/master/firmware%20binaries%20%26%20gui/o323bgc-release-v096-v20160319.zip o323bgc-release-v096-v20160319] [.zip] (9.4MB)<br />
<br />
Note: This wiki here is not appropriate for v0.96 I2C setups, you should go to [//www.olliw.eu/storm32bgc-v1-wiki/Main_Page STorM32 v0.xx Wiki].<br />
<br />
{{COMMENT|The v0.96 release also includes firmwares for NT IMUs, identifiable by a label "nt" in the file names. Don't use them, use the v0.96 firmware (without a "nt" in the file name).}}<br />
<br />
== Repository ==<br />
<br />
Various files related to the STorM32-BGC project can be downloaded from several places:<br />
* [//github.com/olliw42/storm32bgc Github repository]<br />
* 1st page of the [//www.rcgroups.com/forums/showthread.php?t=2055844 rcgroups discussion thread]</div>OlliWhttp://www.olliw.eu/storm32bgc-v2-wiki/index.php?title=Downloads&diff=11897Downloads2025-11-20T07:02:25Z<p>OlliW: </p>
<hr />
<div>{{ALERT| '''PLEASE READ THIS FIRST''' <br />
There are 2 types of IMU modules which STorM32 v1.3x controllers can use, NT IMUs and I2C IMUs, and there are 2 firmwares which correspond to each type. It is important to choose the correct firmware, otherwise your controller and gimbal will not work. Read this page to understand the difference between the two types of IMUs [[//www.olliw.eu/storm32bgc-v2-wiki/What_is_STorM32_NT_about%3F]], and this post to identify your IMU [[//www.rcgroups.com/forums/showpost.php?p=38258334&postcount=10256]]. <br />
<br />
The STorM32 v3.x, v4.x, v6.x controllers can only use NT IMUs, not I2C IMUs.<br />
<br />
Only firmwares with version v0.96 or less work with I2C IMUs. Firmwares with version numbers v2.xx are not usable for setups with I2C IMU. If you do not know what a NT IMU is, then you likely have a I2C IMU and need firmware v0.96.}}<br/><br />
{{ALERT| '''ANNOUNCEMENTS'''<br />
- The v2.xx firmware series will phase out, i.e., currently it is planned that firmware 2.74 is the last release in this series. <br/><br />
- Development will shift to [//www.olliw.eu/storm32bgc-wiki STorM32 v3]. STorM32 v3 will not support the old and tried v1.3x boards, as well as not the v3.3 and v4.1 boards. Reason is that the STM32F103 microcontroller used on these boards has simply become too limited.<br />
<!--- Support of the v1.3x STorM32 boards will phase out. That is, the next official release (whenever this will be), will be the last release which supports these old and tried main boards. Reason is that since few years I have migrated to the STM32 HAL&LL libraries, but the v1.3x code is still on the legacy SPL library since it's I2C is ca 50-100 us faster than the HAL I2C lib. So I maintain two codes, which is obviously not sustainable.<br />
- Support for quite a number of presumably "old" cameras will phase out. Some of them are so old that it's hard to imagine they are still in use. Examples are Git2, Mapir Survey, Firefly Split 4K, Runcam, GoPro Hero5&7.-->}}<br />
<br />
== v2.xx Firmware for NT IMUs ==<br />
<br />
Firmware for STorM32 setups using a NT camera IMU. <br />
<br />
<br />
Direct link to v2.53 firmware download (this firmware is pretty old, it is highly recommended to use v2.67e):<br> <br />
<br />
:[//github.com/olliw42/storm32bgc/raw/main/firmware%20binaries%20%26%20gui/o323bgc-release-v253-v20200517.zip o323bgc-release-v253-v20200517] [.zip] (12.2 MB)<br />
:[//www.rcgroups.com/forums/showpost.php?p=44539519&postcount=12349 Release Notes]<br />
<br />
<br />
Latest beta release v2.73e:<br><br />
:[//github.com/olliw42/storm32bgc/raw/main/firmware%20binaries%20%26%20gui/o323bgc-release-v273e-v20250711.zip o323bgc-release-v273e-v20250711] [.zip] (15.9 MB)<br />
:[https://www.rcgroups.com/forums/showpost.php?p=53978973&postcount=15988 Release Notes]<br />
<br />
<br />
NTLoggerTool release v0.50:<br><br />
:[//www.olliw.eu/downloads/storm32/ntloggertool/ntloggertool-release-v050-v20231003.zip ntloggertool-release-v050-v20231003] [.zip] (295 MB)<br />
<br />
<br />
BetaCopter/BetaPlane 4.7-dev:<br><br />
:For downloading the firmwares and all further info please visit the article [[Using STorM32 with BetaPilot]].<br />
<br />
== v0.96 Firmware for I2C IMUs ==<br />
<br />
Firmware for STorM32 setups using a I2C camera IMU. Examples are the HakRC gimbal and other gimbals from Aliexpress.<br />
<br />
Latest firmware v0.96 for I2C IMUs:<br> <br />
:[//github.com/olliw42/storm32bgc/raw/master/firmware%20binaries%20%26%20gui/o323bgc-release-v096-v20160319.zip o323bgc-release-v096-v20160319] [.zip] (9.4MB)<br />
<br />
Note: This wiki here is not appropriate for v0.96 I2C setups, you should go to [//www.olliw.eu/storm32bgc-v1-wiki/Main_Page STorM32 v0.xx Wiki].<br />
<br />
{{COMMENT|The v0.96 release also includes firmwares for NT IMUs, identifiable by a label "nt" in the file names. Don't use them, use the v0.96 firmware (without a "nt" in the file name).}}<br />
<br />
== Repository ==<br />
<br />
Various files related to the STorM32-BGC project can be downloaded from several places:<br />
* [//github.com/olliw42/storm32bgc Github repository]<br />
* 1st page of the [//www.rcgroups.com/forums/showthread.php?t=2055844 rcgroups discussion thread]</div>OlliWhttp://www.olliw.eu/storm32bgc-v2-wiki/index.php?title=STorM32_Scripts&diff=11896STorM32 Scripts2025-11-20T02:29:47Z<p>OlliW: /* Scripting Language */</p>
<hr />
<div><span style="font-size:88%">''The information on this page refers to firmware v2.69a and higher.''</span><br />
<br />
With firmware version v0.51 the possibility of uploading scripts to the STorM32 controller, which are then executed on-board, without connection to a PC, has been introduced. It allows you to programmatically affect the behavior of the controller in order to achieve user specific needs and tasks with unprecedented flexibility. The STorM32 controller was the first of its kind to offer this innovative feature, which was when later adopted by others. <br />
<br />
The on-board scripts bring great possibilities, but need some understanding to avoid doing nonsense. This article gives some background, and presents the concepts by means of examples.<br />
<br />
== Overview of Script Types ==<br />
<!--<br />
The STorM32 on-board scripts should not be confused with other types of scripts, thus a short overview:<br />
<br />
* '''''On-board Scripts''''': These scripts are uploaded and stored into the controller, and are executed permanently by the controller. They are programmed by the user via the GUI's {{GUI|Scripts}} tab.<br />
<br />
* '''''Motion Control Scripts''''': In older firmware versions, the GUI did incorporate a dedicated Motion Control processor. These scripts were executed on the PC, sending commands to the STorM32 controller via e.g. USB, Bluetooth, or any other serial connection between the PC and the controller.<br />
<br />
* '''''Mission Planner Scripts''''': ArduPilot's [http://planner.ardupilot.com/ Mission Planner] allows to run Python scripts, which, similar to Motion Control scripts, are executed on the PC, sending messages to the autopilot.<br />
<br />
For all these scripts, the source code is stored in plain ASCII text files (and could hence be edited by any text editor), but the script type can be determined from the default file extension:<br />
<br />
.scr = STorM32 on-board script<br />
.mcs = Motion Control script<br />
.py = Mission Planner Python script<br />
<br />
When using the respective tools for handling the scripts, only the correct scripts, i.e. files with the correct file extension, should be accessible with the tools, avoiding confusion.<br />
<br />
This article focuses exclusively on the STorM32 on-board scripts.<br />
--><br />
The STorM32 on-board scripts should not be confused with other types of scripts. <br />
<br />
These on-board scripts are uploaded and stored into the controller, and are executed permanently by the controller. They are programmed by the user via the GUI's {{GUI|Scripts}} tab. The source code is stored in plain ASCII text files (and could hence be edited by any text editor), with default file extension:<br />
<br />
.scr = STorM32 on-board script<br />
<br />
== Technical Background ==<br />
<br />
Since the code space on the STorM32 controller is very limited (currently only 128 bytes in total are available for the on-board scripts), and especially because of performance reasons the scripts are stored in the controller as binary pseudo code. <br />
<br />
The workflow is thus as follows: The scripts written in the '''''STorM32 on-board scripting language''''' <br />
are translated into pseudo code with a home-brewed compiler, which is integrated into the GUI. The pseudo code is then stored into the STorM32 controller board with a {{GUIFIELD|Write}}. The pseudo code is permanently executed online by the STorM32 controller using an internal pseudo-code processor.<br />
<br />
For understanding the internal working one should realize that the STorM32 controller code is essentially an endless loop, which is triggered and repeated every 1.5 ms. This is called a cycle. Two situations can hence occur in the execution of the pseudo code, namely - first - the next pseudo command should be executed in the same cycle as the previous one, or - second - the next pseudo command should be postponed and executed in the next cycle. Generally, the function commands are of the first kind, while for the control flow commands it depends.<br />
<br />
== Usage ==<br />
<br />
In total four scripts, named Script1 to Script4, can be run concurrently and independently. For each script, two fields are available in the {{GUI|Scripts}} tab, e.g. for Script1 these are:<br />
<br />
* {{PARAMNAME|Script1 Control}}<br />
* {{PARAMNAME|Script1}}<br />
<br />
The first parameter field allows us to select the input channel, to which the script should "listen", i.e., which input value is used in the script for e.g. triggering one of the up to five cases (see below). <br />
<br />
The second parameter field holds the code. It can be edited via the {{GUIFIELD|Edit Script1}} button. It opens the script editor window, which allows you to write, load and save code. Its syntactic correctness may be checked by doing a {{GUIFIELD|Compile}}. For accepting the code use {{GUIFIELD|Accept and Exit}}.<br />
<br />
Script1 is the master script in the sense that it allows us to modify the {{PARAMNAME|Script2 Control}}, {{PARAMNAME|Script3 Control}}, and {{PARAMNAME|Script4 Control}} parameters and hence to affect the behavior of the other scripts, while the other three scripts cannot modify any of script control parameters.<br />
<br />
{{COMMENT|The four scripts are actually not run concurrently, but sequentially, and are thus not totally independent on each other. In each cycle, the scripts are processed in the order script1, script2, script3, script4. Therefore, a later script can undo changes made by an earlier script, and an earlier script can make changes which are seen by the later scripts.}}<br />
<br />
== Scripting Language ==<br />
<br />
The on-board scripting language has a relatively rich set of commands, which allows us to modify the controller behavior in reaction to inputs, as well as to control the camera for motion control.<br />
<br />
'''''Control flow commands:'''''<br />
CASE#DEFAULT<br />
CASE#1<br />
CASE#2<br />
CASE#3<br />
CASE#4<br />
STOP<br />
REPEAT<br />
WAIT time(int, in 0.1secs)<br />
RESTART<br />
<br />
The cases are determined by the value of the input selected with the {{PARAMNAME|Scriptx Control}} parameter (where x stands for 1,2,3,4). The value ranges for the CASE statements are (see also [[Inputs_and_Functions#Overview_Diagram|Inputs and Functions: Overview Diagram]]):<br />
<br />
* CASE#DEFAULT: -166 ... +166<br />
* CASE#1: +333 ... +500<br />
* CASE#2: -500 ... -333<br />
* CASE#3: +216 ... +277<br />
* CASE#4: -277 ... -216<br />
<br />
Note that the ranges for CASE#1 and CASE#2 start at +333 and -333, respectively, which corresponds to ca 1833 us and 1167 us (roughly, this is very transmitter dependent). Default transmitter settings may not reach these values. Note also that the ranges for CASE#3 and CASE#4 are relatively narrow, and thus can easily be missed.<br />
<br />
'''''Parameter value commands:'''''<br />
SETP parametername(string) option(int, float or string)<br />
SETPMINMAX parametername(string) option(int, float or string) option(int, float or string)<br />
RESTORE<br />
RESTOREALL<br />
SET parametername(string) value(int)<br />
SETMINMAX parametername(string) minvalue(int) maxvalue(int)<br />
<br />
The commands {{BOX|SETP}} and {{BOX|SET}} are identical function-wise, namely set a parameter to a value, but differ in the second argument: In {{BOX|SETP}} the set-to value of the parameter is specified as it is displayed in the GUI (except of the unit in value fields), while in {{BOX|SET}} the new value is specified by its internal integer representation. For instance, if the parameter {{PARAMNAME|Camera Model}} should be set to {{PARAMVALUE|GoPro Hero5}}, then the {{BOX|SETP}} command would be {{BOX|SETP "Camera Model" "GoPro Hero5"}}, and the {{BOX|SET}} command would be {{BOX|SET "Camera Model" 10}} (since the option "GoPro Hero5" is internally represented by the integer 10) (you can check this with {{GUI|Share Settings}}).<br />
<br />
Similar holds for the second and third parameters in the {{BOX|SETPMINMAX}} and {{BOX|SETMINMAX}} commands.<br />
<br />
The {{BOX|SET}} and {{BOX|SETMINMAX}} commands are still existing for compatibility, but should not be used in new scripts (in fact, the script compiler replaced them with the newer {{BOX|SETP}} and {{BOX|SETPMINMAX}} commands).<br />
<br />
{{COMMENT|For some paramneters, a change of their setting initiates further actions, such as a restart of the controller. Changing their values in a script can lead to undetermined behavior, and should thus not be handled in scripts. Parameters of this kind are, e.g., {{PARAMNAME|Pitch Motor Usage}}, {{PARAMNAME|Roll Motor Usage}}, {{PARAMNAME|Yaw Motor Usage}}, {{PARAMNAME|Motor Mapping}}, and {{PARAMNAME|Imu Mapping}}.}}<br />
<br />
'''''Function commands:'''''<br />
SETANGLEPITCH angle(float, in degree°)<br />
SETANGLEROLL angle(float, in degree°)<br />
SETANGLEYAW angle(float, in degree°)<br />
SETANGLE pitchangle(float, in degree°) rollangle(float, in degree°) yawangle(float, in degree°)<br />
SETANGLEPITCH_W angle(float, in degree°) time(int, in 0.1secs)<br />
SETANGLEROLL_W angle(float, in degree°) time(int, in 0.1secs)<br />
SETANGLEYAW_W angle(float, in degree°) time(int, in 0.1secs)<br />
SETSTANDBY 0/1<br />
SETRETRACT 0/1<br />
DOCAMERA 0/1/2/3/4<br />
DORECENTER<br />
DORECENTERPITCH<br />
DORECENTERROLL<br />
DORECENTERYAW<br />
DORECENTER_W time(int, in 0.1secs)<br />
DORECENTERPITCH_W time(int, in 0.1secs)<br />
DORECENTERROLL_W time(int, in 0.1secs)<br />
DORECENTERYAW_W time(int, in 0.1secs)<br />
SETPWM pwmvalue(int)<br />
SETPANOWAITS pitchtime(int, in 0.1secs) yawtime(int, in 0.1secs) shottime(int, in 0.1secs)<br />
SETPANORANGE yawangle(int, in degree°)<br />
SETPANOALLOWEXIT<br />
DOPANO pitchangle(int, in degree°) steps(int)<br />
BEEP<br />
<br />
Most function commands mirror serial RC commands (both in fact call the same internal functions). For further info thus please see [[Serial_Communication#Serial_Communication_-_RC_Commands|Serial Communication - RC Commands]].<br />
<br />
'''''Additional commands:'''''<br />
REMOTEENABLE<br />
REMOTEDISABLE<br />
<br />
The script function commands modify the very same set of internal variables which are also modified by the serial RC commands and MAVLink messages. This can lead to conflicts when the latter are used in combination with scripts, which can be resolved with the {{BOX|REMOTEDISABLE}}/{{BOX|REMOTEENABLE}} script commands. With {{BOX|REMOTEDISABLE}} the scripts are given priority over the serial RC and MAVLink commands. With {{BOX|REMOTEENABLE}} the default behavior is restored.<br />
<br />
SENDMAVTEXT text(string)<br />
SENDCAMTEXT text(string)<br />
<br />
The {{BOX|SENDMAVTEXT}} command triggers the emission of a MAVLink [https://mavlink.io/en/messages/common.html#STATUSTEXT STATUSTEXT] message. The text is the specified string, prepended by a label "STorM32:". The text string can be 24 characters long, and contain the characters '0'-'9', 'a'-'z', 'A'-'Z', ' '.<br />
<br />
The {{BOX|SENDCAMTEXT}} command sends the specified string, appended by a '\n' char, on the {{PARAMNAME|Camera ComPort}}. The text string can be 24 characters long, and contain the characters '0'-'9', 'a'-'z', 'A'-'Z', ' '. Only for {{PARAMNAME|Camera Model}} = {{PARAMVALUE|Serial Api}}.<br />
<br />
Prefer short text strings, in order to not exhaust the limited code space for scripts.<br />
<br />
== Examples ==<br />
<br />
=== Changing a Parameter via the Transmitter ===<br />
<br />
Adjusting the value of a parameter during operation by e.g. tuning a knob on a transmitter is probably the most basic use-case of the scripts.<br />
<br />
Let's consider GekoCH's application as an example (see [http://www.rcgroups.com/forums/showpost.php?p=29667070&postcount=19 here]): He's using a gimbal on a copter, and asked for the possibility to change the speed by which the camera turns upon a rc signal via another rc signal. He used a poti on the transmitter and the absolute mode to adjust the pitch orientation of the camera. It's obviously not possible to simultaneously fly the copter and to move the poti that precisely that a smooth camera motion is obtained, hence the {{PARAMNAME|Speed Limit}} feature was used. That is, the poti is quickly moved to the target orientation, and thanks to the speed limiter a smooth turn of the camera results. However, only one speed was possible before. Three solutions shall be discussed:<br />
<br />
'''''Method A'''''<br />
<br />
CASE#DEFAULT<br />
SETP "Rc Pitch Speed Limit" 40.0<br />
STOP<br />
CASE#1<br />
SETP "Rc Pitch Speed Limit" 5.0<br />
STOP<br />
<br />
When the input specified in the {{PARAMNAME|Script Control}} parameter field yields a "default" value, then the pitch speed limit is set to 40.0 °/s, respectively, while when the input value is such to trigger {{BOX|CASE#1}}, then the speed limit is set to 5.0 °/s. Every CASE statement needs to be finished with either a {{BOX|STOP}} or {{BOX|REPEAT}}. Here the {{BOX|STOP}} command is used, which means that the preceding {{BOX|SETP}} command is executed only once when the input value changes, and not every cycle again.<br />
<br />
At this point one may ask, which input values triggers which case? The full answer isn't trivial and needs a familiarity with the STorM32 controller. In the given example, the default case is selected then the poti is below ca. 33% (< 1633 us), and case #1 is triggered then the switch is above ca. 83% (> 1830 us).<br />
<br />
'''''Method B'''''<br />
<br />
SETPMINMAX "Rc Pitch Speed Limit" 5.0 40.0<br />
REPEAT<br />
<br />
The {{BOX|SETPMINMAX}} command linearly interpolates between the minimum value (5.0 °/s) and maximum value (40.0 °/s), depending on the input value. For instance, for an input value of 200 the pitch speed limit is set to 200 * (40.0-5.0)/1000 + (40.0+5.0)/2 = 29.5°/s. Hence, method B allows us to adjust the speed limit continuously in the range of 5.0 °/s to 40.0 °/s. The {{BOX|REPEAT}} command at the end ensures, that the {{BOX|SETPMINMAX}} command is executed at every cycle anew, and not just once, so that any change in the input value is quickly tracked.<br />
<br />
A video by GekoCH using this feature is [http://www.rcgroups.com/forums/showpost.php?p=30246328&postcount=2723 here].<br />
<br />
'''''Method C'''''<br />
<br />
CASE#DEFAULT<br />
RESTORE "Rc Pitch Speed Limit"<br />
STOP<br />
CASE#1<br />
SETP "Rc Pitch Speed Limit" 5.0<br />
STOP<br />
<br />
This example is essentially method A, but overcomes a minor yet potentially annoying issue. In method A, the parameter value specified in the {{PARAMVALUE|Rc Pitch Speed Limit}} field of the GUI is overwritten immediately by the script, and hence becomes obsolete. In most cases one would however prefer that the default value is determined by the entry in the GUI, and not by that in the script. This issue is resolved by the {{BOX|RESTORE}} command, which sets the {{PARAMVALUE|Rc Pitch Speed Limit}} parameter to the value stored in the EEPROM.<br />
<br />
A similar {{BOX|RESTOREALL}} command exists, which sets all parameters to their values stored in the EEPROM. However, for efficiency reasons it should not be used, except then it is really absolutely needed. Using several {{BOX|RESTORE}} commands is much preferred over using {{BOX|RESTOREALL}}. In short, avoid {{BOX|RESTOREALL}} if you can.<br />
<br />
'''''Concluding Remarks'''''<br />
<br />
Of course, one is not limited to only the {{PARAMNAME|Rc Pitch Speed Limit}} parameter. ANY other available parameter (except of the {{PARAMNAME|Script Control}} parameters as discussed before), can be used in the {{BOX|SET}} and {{BOX|SETPMINMAX}} commands and hence be modified by the scripts. Furthermore, any case statement can of course be followed by more than one command, such that complex situations can be tackled (it is though not possible to have another case statement within a case statement).<br />
<br />
Up to four cases can be distinguished, via the {{BOX|CASE#DEFAULT}}, {{BOX|CASE#1}}, {{BOX|CASE#2}}, and {{BOX|CASE#3}} statements. A case is chosen dependent on the value of the input selected by the {{PARAMNAME|Script Control}} parameter, in close analogy to all the other available functions such as the Rc Inputs, Pan Control or IR Camera Control, see also [[Inputs and Functions]].<br />
<br />
=== Running a Motion Control Sequence ===<br />
<br />
CASE#DEFAULT<br />
STOP<br />
CASE#1<br />
SETANGLE -22.5 0 31.5<br />
WAIT 20<br />
DOCAMERA 1<br />
SETANGLEYAW 0<br />
WAIT 20<br />
DOCAMERA 1<br />
SETANGLEYAW -31.5<br />
WAIT 20<br />
DOCAMERA 1<br />
SETANGLE 22.5 0 -31.5<br />
WAIT 20<br />
DOCAMERA 1<br />
SETANGLEYAW 0<br />
WAIT 20<br />
DOCAMERA 1<br />
SETANGLEYAW 31.5<br />
WAIT 20<br />
DOCAMERA 1<br />
DORECENTER<br />
STOP<br />
<br />
This short sequence consumes already 62 of the 128 bytes, which shows that only relatively short motion control sequences are possible with the on-board scripts.<br />
<br />
=== Running a Pano Sequence ===<br />
<br />
The previous motion control sequence allows to record a pano, which however is severely limited by the maximal possible script code size. Thus, more powerful commands were introduced, which allow quite extensive pano shots.<br />
<br />
CASE#DEFAULT<br />
DORECENTER<br />
STOP<br />
CASE#1<br />
SETANGLEYAW_W 45 30<br />
SETPANOWAITS 30 30 10<br />
SETPANORANGE 90<br />
DOPANO 30 -8<br />
DOPANO 0 8<br />
DOPANO -30 -8<br />
STOP<br />
<br />
The {{BOX|SETANGLEYAW_W}} command sets the yaw angle to 45°, and waits 3.0 secs in addition to the predicted time for the turn. <br />
<br />
The {{BOX|SETPANOWAITS}} and {{BOX|SETPANORANGE}} commands set some "global" parameters of the pano, namely the time to wait after each pitch movement, the time to wait after each yaw step, the time to wait before each shot, and the total yaw angle range which shall be covered. <br />
<br />
The {{BOX|DOPANO}} commands finally run the pano sequence. The first {{BOX|DOPANO}} command, e.g., sets the pitch angle to 30°, and then does 8 yaw steps in counterclockwise direction. In each step the yaw axis is progressed by 90°/8 = 11.25°. Similarly for the next two {{BOX|DOPANAO}} commands.<br />
<br />
In the above example, the pano cannot be terminated during execution. That is, the script is executed command by command until it reaches the {{BOX|STOP}} command, and only then it is tested if the input has changed and whether it should jump to CASE#DEFAULT. Often this is the desired behavior, e.g. when the pano is triggered with a momentary push button. Often it is however desired that the pano runs for as long as the input is set but is terminated then it is cleared. A typical use case would be when the pano is triggered with a transmitter switch, there one might want it to run when the switch is flipped but be stopped when the switch is cleared, even if the pano is not yet completed. This can be accomplished with the {{BOX|SETPANOALLOWEXIT}} command. An example script would be<br />
<br />
CASE#DEFAULT<br />
STOP<br />
CASE#1<br />
SETANGLEYAW_W 45 30<br />
SETPANOWAITS 30 30 10<br />
SETPANORANGE 90<br />
SETPANOALLOWEXIT<br />
DOPANO 30 -8<br />
WAIT 10<br />
DOPANO -30 8<br />
DORECENTER<br />
STOP<br />
<br />
Note that here only the {{BOX|DOPANO}} commands are cut short if the input becomes different from CASE#1, but that the other commands are still executed until the {{BOX|STOP}} command is reached. That is, in the example, if the input changes while the first {{BOX|DOPANO}} command is executed, the {{BOX|WAIT}} and {{BOX|DORECENTER}} commands would be still executed.<br />
<br />
=== Running a Script in Combination with Serial and MAVLink Commands ===<br />
<br />
The serial RC commands and the MAVLink messages all set the very same internal variables which are also set by the scripts, and conflicts can accordingly occur.<br />
<br />
Such a situation occurs, e.g., when the STorM32 controller is connected to an ArduPilot flight controller via MAVLink, and a continuous stream of DO_MOUNT_CONTROL (or similar) MAVLink commands is sent to the STorM32 controller. In this case a pano script for instance would appear to not work since the commands for setting the angle of the gimbal emitted by the script would be nearly instantaneously overwritten by the DO_MOUNT_CONTROL (or similar) MAVLink commands received from the flight controller. <br />
<br />
Such situations can be resolved by using the {{BOX|REMOTEDISABLE}} and {{BOX|REMOTEENABLE}} script commands. {{BOX|REMOTEDISABLE}} gives the script priority, and essentially disables the serial and MAVLink commands. With {{BOX|REMOTEENABLE}} the default behavior is restored.<br />
<br />
A script using this mechanism would typically look like <br />
<br />
CASE#DEFAULT<br />
STOP<br />
CASE#1<br />
REMOTEDISABLE<br />
...<br />
REMOTEENABLE<br />
STOP<br />
<br />
or<br />
<br />
CASE#DEFAULT<br />
REMOTEDISABLE<br />
STOP<br />
CASE#1<br />
REMOTEENABLE<br />
...<br />
STOP<br />
<br />
The two script do not exactly work the same and which one to use depends on the actual script. The behavior of the second example could also be achieved as<br />
<br />
REMOTEENABLE<br />
CASE#DEFAULT<br />
REMOTEDISABLE<br />
STOP<br />
CASE#1<br />
...<br />
STOP<br />
<br />
which might be easier to write.<br />
<br />
== User Examples ==<br />
<br />
=== Switching Between Two Alternate Functions of a Continuous RC Channel Using a "Shift Key" ===<br />
<br />
''by Hb121280, see also [https://www.rcgroups.com/forums/showthread.php?2262624-STorM32-BGC-Scripts-Discussion-and-Development-Thread/page2&perpage=50#post39876923]''<br />
<br />
Imagine you want to control gimbal pitch and gimbal yaw using an analog dial on the remote control, but only one analog dial is available. This example uses a button channel to switch between alternate functions of one continuous channel.<br />
<br />
CASE#DEFAULT<br />
SETP "Rc Pitch" "Virtual-8"<br />
SETP "Rc Yaw" "off"<br />
STOP<br />
CASE#1<br />
SETP "Rc Pitch" "Virtual-8"<br />
SETP "Rc Yaw" "off"<br />
STOP<br />
CASE#2<br />
SETP "Rc Pitch" "Virtual-8"<br />
SETP "Rc Yaw" "off"<br />
STOP<br />
CASE#3<br />
SETP "Rc Pitch" "off"<br />
SETP "Rc Yaw" "Virtual-8"<br />
STOP<br />
<br />
The {{PARAMNAME|Script Control}} variable is set to the button channel, e.g. {{PARAMVALUE|Virtual-8}}. In the present case the button channel delivers a value 0 in case it is not pressed and 254 if it is pressed. According to [[Inputs_and_Functions#Overview_Diagram|Inputs and Functions: Overview Diagram]], the value ranges for the CASE statements are:<br />
<br />
* CASE#DEFAULT: -166 ... +166<br />
* CASE#1: +333 ... +500<br />
* CASE#2: -500 ... -333<br />
* CASE#3: +216 ... +277<br />
<br />
Thus, the cases CASE#DEFAULT and CASE#3 have to be used, because the button values 0 (not pressed) and 254 (pressed) fall into their value ranges. The script language does not allow 'missing' case statements, and CASE#1 and CASE#2 need also to be specified (they can be filled with any commands, since they never would be triggered).<br />
<br />
In the above script, the standard behavior (button not pressed) uses the analog channel, or input {{PARAMVALUE|Virtual-8}}, for {{PARAMNAME|Rc Pitch}}. {{PARAMNAME|Rc Yaw}} is accordingly set to {{PARAMVALUE|off}}. Pressing the button reverses the assignments: The analog channel on input {{PARAMVALUE|Virtual-8}} is now used for {{PARAMNAME|Rc Yaw}}, and the control of pitch is deactivated.</div>OlliWhttp://www.olliw.eu/storm32bgc-v2-wiki/index.php?title=STorM32_Scripts&diff=11895STorM32 Scripts2025-11-20T02:28:51Z<p>OlliW: /* Scripting Language */</p>
<hr />
<div><span style="font-size:88%">''The information on this page refers to firmware v2.69a and higher.''</span><br />
<br />
With firmware version v0.51 the possibility of uploading scripts to the STorM32 controller, which are then executed on-board, without connection to a PC, has been introduced. It allows you to programmatically affect the behavior of the controller in order to achieve user specific needs and tasks with unprecedented flexibility. The STorM32 controller was the first of its kind to offer this innovative feature, which was when later adopted by others. <br />
<br />
The on-board scripts bring great possibilities, but need some understanding to avoid doing nonsense. This article gives some background, and presents the concepts by means of examples.<br />
<br />
== Overview of Script Types ==<br />
<!--<br />
The STorM32 on-board scripts should not be confused with other types of scripts, thus a short overview:<br />
<br />
* '''''On-board Scripts''''': These scripts are uploaded and stored into the controller, and are executed permanently by the controller. They are programmed by the user via the GUI's {{GUI|Scripts}} tab.<br />
<br />
* '''''Motion Control Scripts''''': In older firmware versions, the GUI did incorporate a dedicated Motion Control processor. These scripts were executed on the PC, sending commands to the STorM32 controller via e.g. USB, Bluetooth, or any other serial connection between the PC and the controller.<br />
<br />
* '''''Mission Planner Scripts''''': ArduPilot's [http://planner.ardupilot.com/ Mission Planner] allows to run Python scripts, which, similar to Motion Control scripts, are executed on the PC, sending messages to the autopilot.<br />
<br />
For all these scripts, the source code is stored in plain ASCII text files (and could hence be edited by any text editor), but the script type can be determined from the default file extension:<br />
<br />
.scr = STorM32 on-board script<br />
.mcs = Motion Control script<br />
.py = Mission Planner Python script<br />
<br />
When using the respective tools for handling the scripts, only the correct scripts, i.e. files with the correct file extension, should be accessible with the tools, avoiding confusion.<br />
<br />
This article focuses exclusively on the STorM32 on-board scripts.<br />
--><br />
The STorM32 on-board scripts should not be confused with other types of scripts. <br />
<br />
These on-board scripts are uploaded and stored into the controller, and are executed permanently by the controller. They are programmed by the user via the GUI's {{GUI|Scripts}} tab. The source code is stored in plain ASCII text files (and could hence be edited by any text editor), with default file extension:<br />
<br />
.scr = STorM32 on-board script<br />
<br />
== Technical Background ==<br />
<br />
Since the code space on the STorM32 controller is very limited (currently only 128 bytes in total are available for the on-board scripts), and especially because of performance reasons the scripts are stored in the controller as binary pseudo code. <br />
<br />
The workflow is thus as follows: The scripts written in the '''''STorM32 on-board scripting language''''' <br />
are translated into pseudo code with a home-brewed compiler, which is integrated into the GUI. The pseudo code is then stored into the STorM32 controller board with a {{GUIFIELD|Write}}. The pseudo code is permanently executed online by the STorM32 controller using an internal pseudo-code processor.<br />
<br />
For understanding the internal working one should realize that the STorM32 controller code is essentially an endless loop, which is triggered and repeated every 1.5 ms. This is called a cycle. Two situations can hence occur in the execution of the pseudo code, namely - first - the next pseudo command should be executed in the same cycle as the previous one, or - second - the next pseudo command should be postponed and executed in the next cycle. Generally, the function commands are of the first kind, while for the control flow commands it depends.<br />
<br />
== Usage ==<br />
<br />
In total four scripts, named Script1 to Script4, can be run concurrently and independently. For each script, two fields are available in the {{GUI|Scripts}} tab, e.g. for Script1 these are:<br />
<br />
* {{PARAMNAME|Script1 Control}}<br />
* {{PARAMNAME|Script1}}<br />
<br />
The first parameter field allows us to select the input channel, to which the script should "listen", i.e., which input value is used in the script for e.g. triggering one of the up to five cases (see below). <br />
<br />
The second parameter field holds the code. It can be edited via the {{GUIFIELD|Edit Script1}} button. It opens the script editor window, which allows you to write, load and save code. Its syntactic correctness may be checked by doing a {{GUIFIELD|Compile}}. For accepting the code use {{GUIFIELD|Accept and Exit}}.<br />
<br />
Script1 is the master script in the sense that it allows us to modify the {{PARAMNAME|Script2 Control}}, {{PARAMNAME|Script3 Control}}, and {{PARAMNAME|Script4 Control}} parameters and hence to affect the behavior of the other scripts, while the other three scripts cannot modify any of script control parameters.<br />
<br />
{{COMMENT|The four scripts are actually not run concurrently, but sequentially, and are thus not totally independent on each other. In each cycle, the scripts are processed in the order script1, script2, script3, script4. Therefore, a later script can undo changes made by an earlier script, and an earlier script can make changes which are seen by the later scripts.}}<br />
<br />
== Scripting Language ==<br />
<br />
The on-board scripting language has a relatively rich set of commands, which allows us to modify the controller behavior in reaction to inputs, as well as to control the camera for motion control.<br />
<br />
'''''Control flow commands:'''''<br />
CASE#DEFAULT<br />
CASE#1<br />
CASE#2<br />
CASE#3<br />
CASE#4<br />
STOP<br />
REPEAT<br />
WAIT time(int, in 0.1secs)<br />
RESTART<br />
<br />
The cases are determined by the value of the input selected with the {{PARAMNAME|Scriptx Control}} parameter (where x stands for 1,2,3,4). The value ranges for the CASE statements are (see also [[Inputs_and_Functions#Overview_Diagram|Inputs and Functions: Overview Diagram]]):<br />
<br />
* CASE#DEFAULT: -166 ... +166<br />
* CASE#1: +333 ... +500<br />
* CASE#2: -500 ... -333<br />
* CASE#3: +216 ... +277<br />
* CASE#4: -277 ... -216<br />
<br />
Note that the ranges for CASE#1 and CASE#2 start at +333 and -333, respectively, which corresponds to ca 1833 us and 1167 us (roughly, this is very transmitter dependent). Default transmitter settings may not reach these values. Note also that the ranges for CASE#3 and CASE#4 are relatively narrow, and thus can easily be missed.<br />
<br />
'''''Parameter value commands:'''''<br />
SETP parametername(string) option(int, float or string)<br />
SETPMINMAX parametername(string) option(int, float or string) option(int, float or string)<br />
RESTORE<br />
RESTOREALL<br />
SET parametername(string) value(int)<br />
SETMINMAX parametername(string) minvalue(int) maxvalue(int)<br />
<br />
The commands {{BOX|SETP}} and {{BOX|SET}} are identical function-wise, namely set a parameter to a value, but differ in the second argument: In {{BOX|SETP}} the set-to value of the parameter is specified as it is displayed in the GUI (except of the unit in value fields), while in {{BOX|SET}} the new value is specified by its internal integer representation. For instance, if the parameter {{PARAMNAME|Camera Model}} should be set to {{PARAMVALUE|GoPro Hero5}}, then the {{BOX|SETP}} command would be {{BOX|SETP "Camera Model" "GoPro Hero5"}}, and the {{BOX|SET}} command would be {{BOX|SET "Camera Model" 10}} (since the option "GoPro Hero5" is internally represented by the integer 10) (you can check this with {{GUI|Share Settings}}).<br />
<br />
Similar holds for the second and third parameters in the {{BOX|SETPMINMAX}} and {{BOX|SETMINMAX}} commands.<br />
<br />
The {{BOX|SET}} and {{BOX|SETMINMAX}} commands are still existing for compatibility, but should not be used in new scripts (in fact, the script compiler replaced them with the newer {{BOX|SETP}} and {{BOX|SETPMINMAX}} commands).<br />
<br />
{{COMMENT|For some paramneters, a change of their setting initiates further actions, such as a restart of the controller. Changing their values in a script can lead to undetermined behavior, and shoucl thu snot be handled in scripts. Parameters of this kind are, e.g., {{PARAMNAME|Pitch Motor Usage}}, {{PARAMNAME|Roll Motor Usage}}, {{PARAMNAME|Yaw Motor Usage}}, {{PARAMNAME|Motor Mapping}}, and {{PARAMNAME|Imu Mapping}}.}}<br />
<br />
'''''Function commands:'''''<br />
SETANGLEPITCH angle(float, in degree°)<br />
SETANGLEROLL angle(float, in degree°)<br />
SETANGLEYAW angle(float, in degree°)<br />
SETANGLE pitchangle(float, in degree°) rollangle(float, in degree°) yawangle(float, in degree°)<br />
SETANGLEPITCH_W angle(float, in degree°) time(int, in 0.1secs)<br />
SETANGLEROLL_W angle(float, in degree°) time(int, in 0.1secs)<br />
SETANGLEYAW_W angle(float, in degree°) time(int, in 0.1secs)<br />
SETSTANDBY 0/1<br />
SETRETRACT 0/1<br />
DOCAMERA 0/1/2/3/4<br />
DORECENTER<br />
DORECENTERPITCH<br />
DORECENTERROLL<br />
DORECENTERYAW<br />
DORECENTER_W time(int, in 0.1secs)<br />
DORECENTERPITCH_W time(int, in 0.1secs)<br />
DORECENTERROLL_W time(int, in 0.1secs)<br />
DORECENTERYAW_W time(int, in 0.1secs)<br />
SETPWM pwmvalue(int)<br />
SETPANOWAITS pitchtime(int, in 0.1secs) yawtime(int, in 0.1secs) shottime(int, in 0.1secs)<br />
SETPANORANGE yawangle(int, in degree°)<br />
SETPANOALLOWEXIT<br />
DOPANO pitchangle(int, in degree°) steps(int)<br />
BEEP<br />
<br />
Most function commands mirror serial RC commands (both in fact call the same internal functions). For further info thus please see [[Serial_Communication#Serial_Communication_-_RC_Commands|Serial Communication - RC Commands]].<br />
<br />
'''''Additional commands:'''''<br />
REMOTEENABLE<br />
REMOTEDISABLE<br />
<br />
The script function commands modify the very same set of internal variables which are also modified by the serial RC commands and MAVLink messages. This can lead to conflicts when the latter are used in combination with scripts, which can be resolved with the {{BOX|REMOTEDISABLE}}/{{BOX|REMOTEENABLE}} script commands. With {{BOX|REMOTEDISABLE}} the scripts are given priority over the serial RC and MAVLink commands. With {{BOX|REMOTEENABLE}} the default behavior is restored.<br />
<br />
SENDMAVTEXT text(string)<br />
SENDCAMTEXT text(string)<br />
<br />
The {{BOX|SENDMAVTEXT}} command triggers the emission of a MAVLink [https://mavlink.io/en/messages/common.html#STATUSTEXT STATUSTEXT] message. The text is the specified string, prepended by a label "STorM32:". The text string can be 24 characters long, and contain the characters '0'-'9', 'a'-'z', 'A'-'Z', ' '.<br />
<br />
The {{BOX|SENDCAMTEXT}} command sends the specified string, appended by a '\n' char, on the {{PARAMNAME|Camera ComPort}}. The text string can be 24 characters long, and contain the characters '0'-'9', 'a'-'z', 'A'-'Z', ' '. Only for {{PARAMNAME|Camera Model}} = {{PARAMVALUE|Serial Api}}.<br />
<br />
Prefer short text strings, in order to not exhaust the limited code space for scripts.<br />
<br />
== Examples ==<br />
<br />
=== Changing a Parameter via the Transmitter ===<br />
<br />
Adjusting the value of a parameter during operation by e.g. tuning a knob on a transmitter is probably the most basic use-case of the scripts.<br />
<br />
Let's consider GekoCH's application as an example (see [http://www.rcgroups.com/forums/showpost.php?p=29667070&postcount=19 here]): He's using a gimbal on a copter, and asked for the possibility to change the speed by which the camera turns upon a rc signal via another rc signal. He used a poti on the transmitter and the absolute mode to adjust the pitch orientation of the camera. It's obviously not possible to simultaneously fly the copter and to move the poti that precisely that a smooth camera motion is obtained, hence the {{PARAMNAME|Speed Limit}} feature was used. That is, the poti is quickly moved to the target orientation, and thanks to the speed limiter a smooth turn of the camera results. However, only one speed was possible before. Three solutions shall be discussed:<br />
<br />
'''''Method A'''''<br />
<br />
CASE#DEFAULT<br />
SETP "Rc Pitch Speed Limit" 40.0<br />
STOP<br />
CASE#1<br />
SETP "Rc Pitch Speed Limit" 5.0<br />
STOP<br />
<br />
When the input specified in the {{PARAMNAME|Script Control}} parameter field yields a "default" value, then the pitch speed limit is set to 40.0 °/s, respectively, while when the input value is such to trigger {{BOX|CASE#1}}, then the speed limit is set to 5.0 °/s. Every CASE statement needs to be finished with either a {{BOX|STOP}} or {{BOX|REPEAT}}. Here the {{BOX|STOP}} command is used, which means that the preceding {{BOX|SETP}} command is executed only once when the input value changes, and not every cycle again.<br />
<br />
At this point one may ask, which input values triggers which case? The full answer isn't trivial and needs a familiarity with the STorM32 controller. In the given example, the default case is selected then the poti is below ca. 33% (< 1633 us), and case #1 is triggered then the switch is above ca. 83% (> 1830 us).<br />
<br />
'''''Method B'''''<br />
<br />
SETPMINMAX "Rc Pitch Speed Limit" 5.0 40.0<br />
REPEAT<br />
<br />
The {{BOX|SETPMINMAX}} command linearly interpolates between the minimum value (5.0 °/s) and maximum value (40.0 °/s), depending on the input value. For instance, for an input value of 200 the pitch speed limit is set to 200 * (40.0-5.0)/1000 + (40.0+5.0)/2 = 29.5°/s. Hence, method B allows us to adjust the speed limit continuously in the range of 5.0 °/s to 40.0 °/s. The {{BOX|REPEAT}} command at the end ensures, that the {{BOX|SETPMINMAX}} command is executed at every cycle anew, and not just once, so that any change in the input value is quickly tracked.<br />
<br />
A video by GekoCH using this feature is [http://www.rcgroups.com/forums/showpost.php?p=30246328&postcount=2723 here].<br />
<br />
'''''Method C'''''<br />
<br />
CASE#DEFAULT<br />
RESTORE "Rc Pitch Speed Limit"<br />
STOP<br />
CASE#1<br />
SETP "Rc Pitch Speed Limit" 5.0<br />
STOP<br />
<br />
This example is essentially method A, but overcomes a minor yet potentially annoying issue. In method A, the parameter value specified in the {{PARAMVALUE|Rc Pitch Speed Limit}} field of the GUI is overwritten immediately by the script, and hence becomes obsolete. In most cases one would however prefer that the default value is determined by the entry in the GUI, and not by that in the script. This issue is resolved by the {{BOX|RESTORE}} command, which sets the {{PARAMVALUE|Rc Pitch Speed Limit}} parameter to the value stored in the EEPROM.<br />
<br />
A similar {{BOX|RESTOREALL}} command exists, which sets all parameters to their values stored in the EEPROM. However, for efficiency reasons it should not be used, except then it is really absolutely needed. Using several {{BOX|RESTORE}} commands is much preferred over using {{BOX|RESTOREALL}}. In short, avoid {{BOX|RESTOREALL}} if you can.<br />
<br />
'''''Concluding Remarks'''''<br />
<br />
Of course, one is not limited to only the {{PARAMNAME|Rc Pitch Speed Limit}} parameter. ANY other available parameter (except of the {{PARAMNAME|Script Control}} parameters as discussed before), can be used in the {{BOX|SET}} and {{BOX|SETPMINMAX}} commands and hence be modified by the scripts. Furthermore, any case statement can of course be followed by more than one command, such that complex situations can be tackled (it is though not possible to have another case statement within a case statement).<br />
<br />
Up to four cases can be distinguished, via the {{BOX|CASE#DEFAULT}}, {{BOX|CASE#1}}, {{BOX|CASE#2}}, and {{BOX|CASE#3}} statements. A case is chosen dependent on the value of the input selected by the {{PARAMNAME|Script Control}} parameter, in close analogy to all the other available functions such as the Rc Inputs, Pan Control or IR Camera Control, see also [[Inputs and Functions]].<br />
<br />
=== Running a Motion Control Sequence ===<br />
<br />
CASE#DEFAULT<br />
STOP<br />
CASE#1<br />
SETANGLE -22.5 0 31.5<br />
WAIT 20<br />
DOCAMERA 1<br />
SETANGLEYAW 0<br />
WAIT 20<br />
DOCAMERA 1<br />
SETANGLEYAW -31.5<br />
WAIT 20<br />
DOCAMERA 1<br />
SETANGLE 22.5 0 -31.5<br />
WAIT 20<br />
DOCAMERA 1<br />
SETANGLEYAW 0<br />
WAIT 20<br />
DOCAMERA 1<br />
SETANGLEYAW 31.5<br />
WAIT 20<br />
DOCAMERA 1<br />
DORECENTER<br />
STOP<br />
<br />
This short sequence consumes already 62 of the 128 bytes, which shows that only relatively short motion control sequences are possible with the on-board scripts.<br />
<br />
=== Running a Pano Sequence ===<br />
<br />
The previous motion control sequence allows to record a pano, which however is severely limited by the maximal possible script code size. Thus, more powerful commands were introduced, which allow quite extensive pano shots.<br />
<br />
CASE#DEFAULT<br />
DORECENTER<br />
STOP<br />
CASE#1<br />
SETANGLEYAW_W 45 30<br />
SETPANOWAITS 30 30 10<br />
SETPANORANGE 90<br />
DOPANO 30 -8<br />
DOPANO 0 8<br />
DOPANO -30 -8<br />
STOP<br />
<br />
The {{BOX|SETANGLEYAW_W}} command sets the yaw angle to 45°, and waits 3.0 secs in addition to the predicted time for the turn. <br />
<br />
The {{BOX|SETPANOWAITS}} and {{BOX|SETPANORANGE}} commands set some "global" parameters of the pano, namely the time to wait after each pitch movement, the time to wait after each yaw step, the time to wait before each shot, and the total yaw angle range which shall be covered. <br />
<br />
The {{BOX|DOPANO}} commands finally run the pano sequence. The first {{BOX|DOPANO}} command, e.g., sets the pitch angle to 30°, and then does 8 yaw steps in counterclockwise direction. In each step the yaw axis is progressed by 90°/8 = 11.25°. Similarly for the next two {{BOX|DOPANAO}} commands.<br />
<br />
In the above example, the pano cannot be terminated during execution. That is, the script is executed command by command until it reaches the {{BOX|STOP}} command, and only then it is tested if the input has changed and whether it should jump to CASE#DEFAULT. Often this is the desired behavior, e.g. when the pano is triggered with a momentary push button. Often it is however desired that the pano runs for as long as the input is set but is terminated then it is cleared. A typical use case would be when the pano is triggered with a transmitter switch, there one might want it to run when the switch is flipped but be stopped when the switch is cleared, even if the pano is not yet completed. This can be accomplished with the {{BOX|SETPANOALLOWEXIT}} command. An example script would be<br />
<br />
CASE#DEFAULT<br />
STOP<br />
CASE#1<br />
SETANGLEYAW_W 45 30<br />
SETPANOWAITS 30 30 10<br />
SETPANORANGE 90<br />
SETPANOALLOWEXIT<br />
DOPANO 30 -8<br />
WAIT 10<br />
DOPANO -30 8<br />
DORECENTER<br />
STOP<br />
<br />
Note that here only the {{BOX|DOPANO}} commands are cut short if the input becomes different from CASE#1, but that the other commands are still executed until the {{BOX|STOP}} command is reached. That is, in the example, if the input changes while the first {{BOX|DOPANO}} command is executed, the {{BOX|WAIT}} and {{BOX|DORECENTER}} commands would be still executed.<br />
<br />
=== Running a Script in Combination with Serial and MAVLink Commands ===<br />
<br />
The serial RC commands and the MAVLink messages all set the very same internal variables which are also set by the scripts, and conflicts can accordingly occur.<br />
<br />
Such a situation occurs, e.g., when the STorM32 controller is connected to an ArduPilot flight controller via MAVLink, and a continuous stream of DO_MOUNT_CONTROL (or similar) MAVLink commands is sent to the STorM32 controller. In this case a pano script for instance would appear to not work since the commands for setting the angle of the gimbal emitted by the script would be nearly instantaneously overwritten by the DO_MOUNT_CONTROL (or similar) MAVLink commands received from the flight controller. <br />
<br />
Such situations can be resolved by using the {{BOX|REMOTEDISABLE}} and {{BOX|REMOTEENABLE}} script commands. {{BOX|REMOTEDISABLE}} gives the script priority, and essentially disables the serial and MAVLink commands. With {{BOX|REMOTEENABLE}} the default behavior is restored.<br />
<br />
A script using this mechanism would typically look like <br />
<br />
CASE#DEFAULT<br />
STOP<br />
CASE#1<br />
REMOTEDISABLE<br />
...<br />
REMOTEENABLE<br />
STOP<br />
<br />
or<br />
<br />
CASE#DEFAULT<br />
REMOTEDISABLE<br />
STOP<br />
CASE#1<br />
REMOTEENABLE<br />
...<br />
STOP<br />
<br />
The two script do not exactly work the same and which one to use depends on the actual script. The behavior of the second example could also be achieved as<br />
<br />
REMOTEENABLE<br />
CASE#DEFAULT<br />
REMOTEDISABLE<br />
STOP<br />
CASE#1<br />
...<br />
STOP<br />
<br />
which might be easier to write.<br />
<br />
== User Examples ==<br />
<br />
=== Switching Between Two Alternate Functions of a Continuous RC Channel Using a "Shift Key" ===<br />
<br />
''by Hb121280, see also [https://www.rcgroups.com/forums/showthread.php?2262624-STorM32-BGC-Scripts-Discussion-and-Development-Thread/page2&perpage=50#post39876923]''<br />
<br />
Imagine you want to control gimbal pitch and gimbal yaw using an analog dial on the remote control, but only one analog dial is available. This example uses a button channel to switch between alternate functions of one continuous channel.<br />
<br />
CASE#DEFAULT<br />
SETP "Rc Pitch" "Virtual-8"<br />
SETP "Rc Yaw" "off"<br />
STOP<br />
CASE#1<br />
SETP "Rc Pitch" "Virtual-8"<br />
SETP "Rc Yaw" "off"<br />
STOP<br />
CASE#2<br />
SETP "Rc Pitch" "Virtual-8"<br />
SETP "Rc Yaw" "off"<br />
STOP<br />
CASE#3<br />
SETP "Rc Pitch" "off"<br />
SETP "Rc Yaw" "Virtual-8"<br />
STOP<br />
<br />
The {{PARAMNAME|Script Control}} variable is set to the button channel, e.g. {{PARAMVALUE|Virtual-8}}. In the present case the button channel delivers a value 0 in case it is not pressed and 254 if it is pressed. According to [[Inputs_and_Functions#Overview_Diagram|Inputs and Functions: Overview Diagram]], the value ranges for the CASE statements are:<br />
<br />
* CASE#DEFAULT: -166 ... +166<br />
* CASE#1: +333 ... +500<br />
* CASE#2: -500 ... -333<br />
* CASE#3: +216 ... +277<br />
<br />
Thus, the cases CASE#DEFAULT and CASE#3 have to be used, because the button values 0 (not pressed) and 254 (pressed) fall into their value ranges. The script language does not allow 'missing' case statements, and CASE#1 and CASE#2 need also to be specified (they can be filled with any commands, since they never would be triggered).<br />
<br />
In the above script, the standard behavior (button not pressed) uses the analog channel, or input {{PARAMVALUE|Virtual-8}}, for {{PARAMNAME|Rc Pitch}}. {{PARAMNAME|Rc Yaw}} is accordingly set to {{PARAMVALUE|off}}. Pressing the button reverses the assignments: The analog channel on input {{PARAMVALUE|Virtual-8}} is now used for {{PARAMNAME|Rc Yaw}}, and the control of pitch is deactivated.</div>OlliWhttp://www.olliw.eu/storm32bgc-v2-wiki/index.php?title=STorM32_Scripts&diff=11894STorM32 Scripts2025-11-20T02:28:17Z<p>OlliW: /* Scripting Language */</p>
<hr />
<div><span style="font-size:88%">''The information on this page refers to firmware v2.69a and higher.''</span><br />
<br />
With firmware version v0.51 the possibility of uploading scripts to the STorM32 controller, which are then executed on-board, without connection to a PC, has been introduced. It allows you to programmatically affect the behavior of the controller in order to achieve user specific needs and tasks with unprecedented flexibility. The STorM32 controller was the first of its kind to offer this innovative feature, which was when later adopted by others. <br />
<br />
The on-board scripts bring great possibilities, but need some understanding to avoid doing nonsense. This article gives some background, and presents the concepts by means of examples.<br />
<br />
== Overview of Script Types ==<br />
<!--<br />
The STorM32 on-board scripts should not be confused with other types of scripts, thus a short overview:<br />
<br />
* '''''On-board Scripts''''': These scripts are uploaded and stored into the controller, and are executed permanently by the controller. They are programmed by the user via the GUI's {{GUI|Scripts}} tab.<br />
<br />
* '''''Motion Control Scripts''''': In older firmware versions, the GUI did incorporate a dedicated Motion Control processor. These scripts were executed on the PC, sending commands to the STorM32 controller via e.g. USB, Bluetooth, or any other serial connection between the PC and the controller.<br />
<br />
* '''''Mission Planner Scripts''''': ArduPilot's [http://planner.ardupilot.com/ Mission Planner] allows to run Python scripts, which, similar to Motion Control scripts, are executed on the PC, sending messages to the autopilot.<br />
<br />
For all these scripts, the source code is stored in plain ASCII text files (and could hence be edited by any text editor), but the script type can be determined from the default file extension:<br />
<br />
.scr = STorM32 on-board script<br />
.mcs = Motion Control script<br />
.py = Mission Planner Python script<br />
<br />
When using the respective tools for handling the scripts, only the correct scripts, i.e. files with the correct file extension, should be accessible with the tools, avoiding confusion.<br />
<br />
This article focuses exclusively on the STorM32 on-board scripts.<br />
--><br />
The STorM32 on-board scripts should not be confused with other types of scripts. <br />
<br />
These on-board scripts are uploaded and stored into the controller, and are executed permanently by the controller. They are programmed by the user via the GUI's {{GUI|Scripts}} tab. The source code is stored in plain ASCII text files (and could hence be edited by any text editor), with default file extension:<br />
<br />
.scr = STorM32 on-board script<br />
<br />
== Technical Background ==<br />
<br />
Since the code space on the STorM32 controller is very limited (currently only 128 bytes in total are available for the on-board scripts), and especially because of performance reasons the scripts are stored in the controller as binary pseudo code. <br />
<br />
The workflow is thus as follows: The scripts written in the '''''STorM32 on-board scripting language''''' <br />
are translated into pseudo code with a home-brewed compiler, which is integrated into the GUI. The pseudo code is then stored into the STorM32 controller board with a {{GUIFIELD|Write}}. The pseudo code is permanently executed online by the STorM32 controller using an internal pseudo-code processor.<br />
<br />
For understanding the internal working one should realize that the STorM32 controller code is essentially an endless loop, which is triggered and repeated every 1.5 ms. This is called a cycle. Two situations can hence occur in the execution of the pseudo code, namely - first - the next pseudo command should be executed in the same cycle as the previous one, or - second - the next pseudo command should be postponed and executed in the next cycle. Generally, the function commands are of the first kind, while for the control flow commands it depends.<br />
<br />
== Usage ==<br />
<br />
In total four scripts, named Script1 to Script4, can be run concurrently and independently. For each script, two fields are available in the {{GUI|Scripts}} tab, e.g. for Script1 these are:<br />
<br />
* {{PARAMNAME|Script1 Control}}<br />
* {{PARAMNAME|Script1}}<br />
<br />
The first parameter field allows us to select the input channel, to which the script should "listen", i.e., which input value is used in the script for e.g. triggering one of the up to five cases (see below). <br />
<br />
The second parameter field holds the code. It can be edited via the {{GUIFIELD|Edit Script1}} button. It opens the script editor window, which allows you to write, load and save code. Its syntactic correctness may be checked by doing a {{GUIFIELD|Compile}}. For accepting the code use {{GUIFIELD|Accept and Exit}}.<br />
<br />
Script1 is the master script in the sense that it allows us to modify the {{PARAMNAME|Script2 Control}}, {{PARAMNAME|Script3 Control}}, and {{PARAMNAME|Script4 Control}} parameters and hence to affect the behavior of the other scripts, while the other three scripts cannot modify any of script control parameters.<br />
<br />
{{COMMENT|The four scripts are actually not run concurrently, but sequentially, and are thus not totally independent on each other. In each cycle, the scripts are processed in the order script1, script2, script3, script4. Therefore, a later script can undo changes made by an earlier script, and an earlier script can make changes which are seen by the later scripts.}}<br />
<br />
== Scripting Language ==<br />
<br />
The on-board scripting language has a relatively rich set of commands, which allows us to modify the controller behavior in reaction to inputs, as well as to control the camera for motion control.<br />
<br />
'''''Control flow commands:'''''<br />
CASE#DEFAULT<br />
CASE#1<br />
CASE#2<br />
CASE#3<br />
CASE#4<br />
STOP<br />
REPEAT<br />
WAIT time(int, in 0.1secs)<br />
RESTART<br />
<br />
The cases are determined by the value of the input selected with the {{PARAMNAME|Scriptx Control}} parameter (where x stands for 1,2,3,4). The value ranges for the CASE statements are (see also [[Inputs_and_Functions#Overview_Diagram|Inputs and Functions: Overview Diagram]]):<br />
<br />
* CASE#DEFAULT: -166 ... +166<br />
* CASE#1: +333 ... +500<br />
* CASE#2: -500 ... -333<br />
* CASE#3: +216 ... +277<br />
* CASE#4: -277 ... -216<br />
<br />
Note that the ranges for CASE#1 and CASE#2 start at +333 and -333, respectively, which corresponds to ca 1833 us and 1167 us (roughly, this is very transmitter dependent). Default transmitter settings may not reach these values. Note also that the ranges for CASE#3 and CASE#4 are relatively narrow, and thus can easily be missed.<br />
<br />
'''''Parameter value commands:'''''<br />
SETP parametername(string) option(int, float or string)<br />
SETPMINMAX parametername(string) option(int, float or string) option(int, float or string)<br />
RESTORE<br />
RESTOREALL<br />
SET parametername(string) value(int)<br />
SETMINMAX parametername(string) minvalue(int) maxvalue(int)<br />
<br />
The commands {{BOX|SETP}} and {{BOX|SET}} are identical function-wise, namely set a parameter to a value, but differ in the second argument: In {{BOX|SETP}} the set-to value of the parameter is specified as it is displayed in the GUI (except of the unit in value fields), while in {{BOX|SET}} the new value is specified by its internal integer representation. For instance, if the parameter {{PARAMNAME|Camera Model}} should be set to {{PARAMVALUE|GoPro Hero5}}, then the {{BOX|SETP}} command would be {{BOX|SETP "Camera Model" "GoPro Hero5"}}, and the {{BOX|SET}} command would be {{BOX|SET "Camera Model" 10}} (since the option "GoPro Hero5" is internally represented by the integer 10) (you can check this with {{GUI|Share Settings}}).<br />
<br />
Similar holds for the second and third parameters in the {{BOX|SETPMINMAX}} and {{BOX|SETMINMAX}} commands.<br />
<br />
The {{BOX|SET}} and {{BOX|SETMINMAX}} commands are still existing for compatibility, but should not be used in new scripts (in fact, the script compiler replaced them with the newer {{BOX|SETP}} and {{BOX|SETPMINMAX}} commands).<br />
<br />
{{COMMENT|For some paramneters, a change of their setting initiates further actions, such as a restart of the controller. Changing their values in a script can lead to undetermined behavior, and shoucl thu snot be handled in scripts. Parameters of this kind are, e.g., {{PARAMNAME|Pitch Motor Usage}}, Roll Motor Usage, Yaw Motor Usage, Motor Mapping, and Imu Mapping.}}<br />
<br />
<br />
'''''Function commands:'''''<br />
SETANGLEPITCH angle(float, in degree°)<br />
SETANGLEROLL angle(float, in degree°)<br />
SETANGLEYAW angle(float, in degree°)<br />
SETANGLE pitchangle(float, in degree°) rollangle(float, in degree°) yawangle(float, in degree°)<br />
SETANGLEPITCH_W angle(float, in degree°) time(int, in 0.1secs)<br />
SETANGLEROLL_W angle(float, in degree°) time(int, in 0.1secs)<br />
SETANGLEYAW_W angle(float, in degree°) time(int, in 0.1secs)<br />
SETSTANDBY 0/1<br />
SETRETRACT 0/1<br />
DOCAMERA 0/1/2/3/4<br />
DORECENTER<br />
DORECENTERPITCH<br />
DORECENTERROLL<br />
DORECENTERYAW<br />
DORECENTER_W time(int, in 0.1secs)<br />
DORECENTERPITCH_W time(int, in 0.1secs)<br />
DORECENTERROLL_W time(int, in 0.1secs)<br />
DORECENTERYAW_W time(int, in 0.1secs)<br />
SETPWM pwmvalue(int)<br />
SETPANOWAITS pitchtime(int, in 0.1secs) yawtime(int, in 0.1secs) shottime(int, in 0.1secs)<br />
SETPANORANGE yawangle(int, in degree°)<br />
SETPANOALLOWEXIT<br />
DOPANO pitchangle(int, in degree°) steps(int)<br />
BEEP<br />
<br />
Most function commands mirror serial RC commands (both in fact call the same internal functions). For further info thus please see [[Serial_Communication#Serial_Communication_-_RC_Commands|Serial Communication - RC Commands]].<br />
<br />
'''''Additional commands:'''''<br />
REMOTEENABLE<br />
REMOTEDISABLE<br />
<br />
The script function commands modify the very same set of internal variables which are also modified by the serial RC commands and MAVLink messages. This can lead to conflicts when the latter are used in combination with scripts, which can be resolved with the {{BOX|REMOTEDISABLE}}/{{BOX|REMOTEENABLE}} script commands. With {{BOX|REMOTEDISABLE}} the scripts are given priority over the serial RC and MAVLink commands. With {{BOX|REMOTEENABLE}} the default behavior is restored.<br />
<br />
SENDMAVTEXT text(string)<br />
SENDCAMTEXT text(string)<br />
<br />
The {{BOX|SENDMAVTEXT}} command triggers the emission of a MAVLink [https://mavlink.io/en/messages/common.html#STATUSTEXT STATUSTEXT] message. The text is the specified string, prepended by a label "STorM32:". The text string can be 24 characters long, and contain the characters '0'-'9', 'a'-'z', 'A'-'Z', ' '.<br />
<br />
The {{BOX|SENDCAMTEXT}} command sends the specified string, appended by a '\n' char, on the {{PARAMNAME|Camera ComPort}}. The text string can be 24 characters long, and contain the characters '0'-'9', 'a'-'z', 'A'-'Z', ' '. Only for {{PARAMNAME|Camera Model}} = {{PARAMVALUE|Serial Api}}.<br />
<br />
Prefer short text strings, in order to not exhaust the limited code space for scripts.<br />
<br />
== Examples ==<br />
<br />
=== Changing a Parameter via the Transmitter ===<br />
<br />
Adjusting the value of a parameter during operation by e.g. tuning a knob on a transmitter is probably the most basic use-case of the scripts.<br />
<br />
Let's consider GekoCH's application as an example (see [http://www.rcgroups.com/forums/showpost.php?p=29667070&postcount=19 here]): He's using a gimbal on a copter, and asked for the possibility to change the speed by which the camera turns upon a rc signal via another rc signal. He used a poti on the transmitter and the absolute mode to adjust the pitch orientation of the camera. It's obviously not possible to simultaneously fly the copter and to move the poti that precisely that a smooth camera motion is obtained, hence the {{PARAMNAME|Speed Limit}} feature was used. That is, the poti is quickly moved to the target orientation, and thanks to the speed limiter a smooth turn of the camera results. However, only one speed was possible before. Three solutions shall be discussed:<br />
<br />
'''''Method A'''''<br />
<br />
CASE#DEFAULT<br />
SETP "Rc Pitch Speed Limit" 40.0<br />
STOP<br />
CASE#1<br />
SETP "Rc Pitch Speed Limit" 5.0<br />
STOP<br />
<br />
When the input specified in the {{PARAMNAME|Script Control}} parameter field yields a "default" value, then the pitch speed limit is set to 40.0 °/s, respectively, while when the input value is such to trigger {{BOX|CASE#1}}, then the speed limit is set to 5.0 °/s. Every CASE statement needs to be finished with either a {{BOX|STOP}} or {{BOX|REPEAT}}. Here the {{BOX|STOP}} command is used, which means that the preceding {{BOX|SETP}} command is executed only once when the input value changes, and not every cycle again.<br />
<br />
At this point one may ask, which input values triggers which case? The full answer isn't trivial and needs a familiarity with the STorM32 controller. In the given example, the default case is selected then the poti is below ca. 33% (< 1633 us), and case #1 is triggered then the switch is above ca. 83% (> 1830 us).<br />
<br />
'''''Method B'''''<br />
<br />
SETPMINMAX "Rc Pitch Speed Limit" 5.0 40.0<br />
REPEAT<br />
<br />
The {{BOX|SETPMINMAX}} command linearly interpolates between the minimum value (5.0 °/s) and maximum value (40.0 °/s), depending on the input value. For instance, for an input value of 200 the pitch speed limit is set to 200 * (40.0-5.0)/1000 + (40.0+5.0)/2 = 29.5°/s. Hence, method B allows us to adjust the speed limit continuously in the range of 5.0 °/s to 40.0 °/s. The {{BOX|REPEAT}} command at the end ensures, that the {{BOX|SETPMINMAX}} command is executed at every cycle anew, and not just once, so that any change in the input value is quickly tracked.<br />
<br />
A video by GekoCH using this feature is [http://www.rcgroups.com/forums/showpost.php?p=30246328&postcount=2723 here].<br />
<br />
'''''Method C'''''<br />
<br />
CASE#DEFAULT<br />
RESTORE "Rc Pitch Speed Limit"<br />
STOP<br />
CASE#1<br />
SETP "Rc Pitch Speed Limit" 5.0<br />
STOP<br />
<br />
This example is essentially method A, but overcomes a minor yet potentially annoying issue. In method A, the parameter value specified in the {{PARAMVALUE|Rc Pitch Speed Limit}} field of the GUI is overwritten immediately by the script, and hence becomes obsolete. In most cases one would however prefer that the default value is determined by the entry in the GUI, and not by that in the script. This issue is resolved by the {{BOX|RESTORE}} command, which sets the {{PARAMVALUE|Rc Pitch Speed Limit}} parameter to the value stored in the EEPROM.<br />
<br />
A similar {{BOX|RESTOREALL}} command exists, which sets all parameters to their values stored in the EEPROM. However, for efficiency reasons it should not be used, except then it is really absolutely needed. Using several {{BOX|RESTORE}} commands is much preferred over using {{BOX|RESTOREALL}}. In short, avoid {{BOX|RESTOREALL}} if you can.<br />
<br />
'''''Concluding Remarks'''''<br />
<br />
Of course, one is not limited to only the {{PARAMNAME|Rc Pitch Speed Limit}} parameter. ANY other available parameter (except of the {{PARAMNAME|Script Control}} parameters as discussed before), can be used in the {{BOX|SET}} and {{BOX|SETPMINMAX}} commands and hence be modified by the scripts. Furthermore, any case statement can of course be followed by more than one command, such that complex situations can be tackled (it is though not possible to have another case statement within a case statement).<br />
<br />
Up to four cases can be distinguished, via the {{BOX|CASE#DEFAULT}}, {{BOX|CASE#1}}, {{BOX|CASE#2}}, and {{BOX|CASE#3}} statements. A case is chosen dependent on the value of the input selected by the {{PARAMNAME|Script Control}} parameter, in close analogy to all the other available functions such as the Rc Inputs, Pan Control or IR Camera Control, see also [[Inputs and Functions]].<br />
<br />
=== Running a Motion Control Sequence ===<br />
<br />
CASE#DEFAULT<br />
STOP<br />
CASE#1<br />
SETANGLE -22.5 0 31.5<br />
WAIT 20<br />
DOCAMERA 1<br />
SETANGLEYAW 0<br />
WAIT 20<br />
DOCAMERA 1<br />
SETANGLEYAW -31.5<br />
WAIT 20<br />
DOCAMERA 1<br />
SETANGLE 22.5 0 -31.5<br />
WAIT 20<br />
DOCAMERA 1<br />
SETANGLEYAW 0<br />
WAIT 20<br />
DOCAMERA 1<br />
SETANGLEYAW 31.5<br />
WAIT 20<br />
DOCAMERA 1<br />
DORECENTER<br />
STOP<br />
<br />
This short sequence consumes already 62 of the 128 bytes, which shows that only relatively short motion control sequences are possible with the on-board scripts.<br />
<br />
=== Running a Pano Sequence ===<br />
<br />
The previous motion control sequence allows to record a pano, which however is severely limited by the maximal possible script code size. Thus, more powerful commands were introduced, which allow quite extensive pano shots.<br />
<br />
CASE#DEFAULT<br />
DORECENTER<br />
STOP<br />
CASE#1<br />
SETANGLEYAW_W 45 30<br />
SETPANOWAITS 30 30 10<br />
SETPANORANGE 90<br />
DOPANO 30 -8<br />
DOPANO 0 8<br />
DOPANO -30 -8<br />
STOP<br />
<br />
The {{BOX|SETANGLEYAW_W}} command sets the yaw angle to 45°, and waits 3.0 secs in addition to the predicted time for the turn. <br />
<br />
The {{BOX|SETPANOWAITS}} and {{BOX|SETPANORANGE}} commands set some "global" parameters of the pano, namely the time to wait after each pitch movement, the time to wait after each yaw step, the time to wait before each shot, and the total yaw angle range which shall be covered. <br />
<br />
The {{BOX|DOPANO}} commands finally run the pano sequence. The first {{BOX|DOPANO}} command, e.g., sets the pitch angle to 30°, and then does 8 yaw steps in counterclockwise direction. In each step the yaw axis is progressed by 90°/8 = 11.25°. Similarly for the next two {{BOX|DOPANAO}} commands.<br />
<br />
In the above example, the pano cannot be terminated during execution. That is, the script is executed command by command until it reaches the {{BOX|STOP}} command, and only then it is tested if the input has changed and whether it should jump to CASE#DEFAULT. Often this is the desired behavior, e.g. when the pano is triggered with a momentary push button. Often it is however desired that the pano runs for as long as the input is set but is terminated then it is cleared. A typical use case would be when the pano is triggered with a transmitter switch, there one might want it to run when the switch is flipped but be stopped when the switch is cleared, even if the pano is not yet completed. This can be accomplished with the {{BOX|SETPANOALLOWEXIT}} command. An example script would be<br />
<br />
CASE#DEFAULT<br />
STOP<br />
CASE#1<br />
SETANGLEYAW_W 45 30<br />
SETPANOWAITS 30 30 10<br />
SETPANORANGE 90<br />
SETPANOALLOWEXIT<br />
DOPANO 30 -8<br />
WAIT 10<br />
DOPANO -30 8<br />
DORECENTER<br />
STOP<br />
<br />
Note that here only the {{BOX|DOPANO}} commands are cut short if the input becomes different from CASE#1, but that the other commands are still executed until the {{BOX|STOP}} command is reached. That is, in the example, if the input changes while the first {{BOX|DOPANO}} command is executed, the {{BOX|WAIT}} and {{BOX|DORECENTER}} commands would be still executed.<br />
<br />
=== Running a Script in Combination with Serial and MAVLink Commands ===<br />
<br />
The serial RC commands and the MAVLink messages all set the very same internal variables which are also set by the scripts, and conflicts can accordingly occur.<br />
<br />
Such a situation occurs, e.g., when the STorM32 controller is connected to an ArduPilot flight controller via MAVLink, and a continuous stream of DO_MOUNT_CONTROL (or similar) MAVLink commands is sent to the STorM32 controller. In this case a pano script for instance would appear to not work since the commands for setting the angle of the gimbal emitted by the script would be nearly instantaneously overwritten by the DO_MOUNT_CONTROL (or similar) MAVLink commands received from the flight controller. <br />
<br />
Such situations can be resolved by using the {{BOX|REMOTEDISABLE}} and {{BOX|REMOTEENABLE}} script commands. {{BOX|REMOTEDISABLE}} gives the script priority, and essentially disables the serial and MAVLink commands. With {{BOX|REMOTEENABLE}} the default behavior is restored.<br />
<br />
A script using this mechanism would typically look like <br />
<br />
CASE#DEFAULT<br />
STOP<br />
CASE#1<br />
REMOTEDISABLE<br />
...<br />
REMOTEENABLE<br />
STOP<br />
<br />
or<br />
<br />
CASE#DEFAULT<br />
REMOTEDISABLE<br />
STOP<br />
CASE#1<br />
REMOTEENABLE<br />
...<br />
STOP<br />
<br />
The two script do not exactly work the same and which one to use depends on the actual script. The behavior of the second example could also be achieved as<br />
<br />
REMOTEENABLE<br />
CASE#DEFAULT<br />
REMOTEDISABLE<br />
STOP<br />
CASE#1<br />
...<br />
STOP<br />
<br />
which might be easier to write.<br />
<br />
== User Examples ==<br />
<br />
=== Switching Between Two Alternate Functions of a Continuous RC Channel Using a "Shift Key" ===<br />
<br />
''by Hb121280, see also [https://www.rcgroups.com/forums/showthread.php?2262624-STorM32-BGC-Scripts-Discussion-and-Development-Thread/page2&perpage=50#post39876923]''<br />
<br />
Imagine you want to control gimbal pitch and gimbal yaw using an analog dial on the remote control, but only one analog dial is available. This example uses a button channel to switch between alternate functions of one continuous channel.<br />
<br />
CASE#DEFAULT<br />
SETP "Rc Pitch" "Virtual-8"<br />
SETP "Rc Yaw" "off"<br />
STOP<br />
CASE#1<br />
SETP "Rc Pitch" "Virtual-8"<br />
SETP "Rc Yaw" "off"<br />
STOP<br />
CASE#2<br />
SETP "Rc Pitch" "Virtual-8"<br />
SETP "Rc Yaw" "off"<br />
STOP<br />
CASE#3<br />
SETP "Rc Pitch" "off"<br />
SETP "Rc Yaw" "Virtual-8"<br />
STOP<br />
<br />
The {{PARAMNAME|Script Control}} variable is set to the button channel, e.g. {{PARAMVALUE|Virtual-8}}. In the present case the button channel delivers a value 0 in case it is not pressed and 254 if it is pressed. According to [[Inputs_and_Functions#Overview_Diagram|Inputs and Functions: Overview Diagram]], the value ranges for the CASE statements are:<br />
<br />
* CASE#DEFAULT: -166 ... +166<br />
* CASE#1: +333 ... +500<br />
* CASE#2: -500 ... -333<br />
* CASE#3: +216 ... +277<br />
<br />
Thus, the cases CASE#DEFAULT and CASE#3 have to be used, because the button values 0 (not pressed) and 254 (pressed) fall into their value ranges. The script language does not allow 'missing' case statements, and CASE#1 and CASE#2 need also to be specified (they can be filled with any commands, since they never would be triggered).<br />
<br />
In the above script, the standard behavior (button not pressed) uses the analog channel, or input {{PARAMVALUE|Virtual-8}}, for {{PARAMNAME|Rc Pitch}}. {{PARAMNAME|Rc Yaw}} is accordingly set to {{PARAMVALUE|off}}. Pressing the button reverses the assignments: The analog channel on input {{PARAMVALUE|Virtual-8}} is now used for {{PARAMNAME|Rc Yaw}}, and the control of pitch is deactivated.</div>OlliWhttp://www.olliw.eu/storm32bgc-v2-wiki/index.php?title=STorM32_Scripts&diff=11893STorM32 Scripts2025-11-20T02:28:00Z<p>OlliW: /* Scripting Language */</p>
<hr />
<div><span style="font-size:88%">''The information on this page refers to firmware v2.69a and higher.''</span><br />
<br />
With firmware version v0.51 the possibility of uploading scripts to the STorM32 controller, which are then executed on-board, without connection to a PC, has been introduced. It allows you to programmatically affect the behavior of the controller in order to achieve user specific needs and tasks with unprecedented flexibility. The STorM32 controller was the first of its kind to offer this innovative feature, which was when later adopted by others. <br />
<br />
The on-board scripts bring great possibilities, but need some understanding to avoid doing nonsense. This article gives some background, and presents the concepts by means of examples.<br />
<br />
== Overview of Script Types ==<br />
<!--<br />
The STorM32 on-board scripts should not be confused with other types of scripts, thus a short overview:<br />
<br />
* '''''On-board Scripts''''': These scripts are uploaded and stored into the controller, and are executed permanently by the controller. They are programmed by the user via the GUI's {{GUI|Scripts}} tab.<br />
<br />
* '''''Motion Control Scripts''''': In older firmware versions, the GUI did incorporate a dedicated Motion Control processor. These scripts were executed on the PC, sending commands to the STorM32 controller via e.g. USB, Bluetooth, or any other serial connection between the PC and the controller.<br />
<br />
* '''''Mission Planner Scripts''''': ArduPilot's [http://planner.ardupilot.com/ Mission Planner] allows to run Python scripts, which, similar to Motion Control scripts, are executed on the PC, sending messages to the autopilot.<br />
<br />
For all these scripts, the source code is stored in plain ASCII text files (and could hence be edited by any text editor), but the script type can be determined from the default file extension:<br />
<br />
.scr = STorM32 on-board script<br />
.mcs = Motion Control script<br />
.py = Mission Planner Python script<br />
<br />
When using the respective tools for handling the scripts, only the correct scripts, i.e. files with the correct file extension, should be accessible with the tools, avoiding confusion.<br />
<br />
This article focuses exclusively on the STorM32 on-board scripts.<br />
--><br />
The STorM32 on-board scripts should not be confused with other types of scripts. <br />
<br />
These on-board scripts are uploaded and stored into the controller, and are executed permanently by the controller. They are programmed by the user via the GUI's {{GUI|Scripts}} tab. The source code is stored in plain ASCII text files (and could hence be edited by any text editor), with default file extension:<br />
<br />
.scr = STorM32 on-board script<br />
<br />
== Technical Background ==<br />
<br />
Since the code space on the STorM32 controller is very limited (currently only 128 bytes in total are available for the on-board scripts), and especially because of performance reasons the scripts are stored in the controller as binary pseudo code. <br />
<br />
The workflow is thus as follows: The scripts written in the '''''STorM32 on-board scripting language''''' <br />
are translated into pseudo code with a home-brewed compiler, which is integrated into the GUI. The pseudo code is then stored into the STorM32 controller board with a {{GUIFIELD|Write}}. The pseudo code is permanently executed online by the STorM32 controller using an internal pseudo-code processor.<br />
<br />
For understanding the internal working one should realize that the STorM32 controller code is essentially an endless loop, which is triggered and repeated every 1.5 ms. This is called a cycle. Two situations can hence occur in the execution of the pseudo code, namely - first - the next pseudo command should be executed in the same cycle as the previous one, or - second - the next pseudo command should be postponed and executed in the next cycle. Generally, the function commands are of the first kind, while for the control flow commands it depends.<br />
<br />
== Usage ==<br />
<br />
In total four scripts, named Script1 to Script4, can be run concurrently and independently. For each script, two fields are available in the {{GUI|Scripts}} tab, e.g. for Script1 these are:<br />
<br />
* {{PARAMNAME|Script1 Control}}<br />
* {{PARAMNAME|Script1}}<br />
<br />
The first parameter field allows us to select the input channel, to which the script should "listen", i.e., which input value is used in the script for e.g. triggering one of the up to five cases (see below). <br />
<br />
The second parameter field holds the code. It can be edited via the {{GUIFIELD|Edit Script1}} button. It opens the script editor window, which allows you to write, load and save code. Its syntactic correctness may be checked by doing a {{GUIFIELD|Compile}}. For accepting the code use {{GUIFIELD|Accept and Exit}}.<br />
<br />
Script1 is the master script in the sense that it allows us to modify the {{PARAMNAME|Script2 Control}}, {{PARAMNAME|Script3 Control}}, and {{PARAMNAME|Script4 Control}} parameters and hence to affect the behavior of the other scripts, while the other three scripts cannot modify any of script control parameters.<br />
<br />
{{COMMENT|The four scripts are actually not run concurrently, but sequentially, and are thus not totally independent on each other. In each cycle, the scripts are processed in the order script1, script2, script3, script4. Therefore, a later script can undo changes made by an earlier script, and an earlier script can make changes which are seen by the later scripts.}}<br />
<br />
== Scripting Language ==<br />
<br />
The on-board scripting language has a relatively rich set of commands, which allows us to modify the controller behavior in reaction to inputs, as well as to control the camera for motion control.<br />
<br />
'''''Control flow commands:'''''<br />
CASE#DEFAULT<br />
CASE#1<br />
CASE#2<br />
CASE#3<br />
CASE#4<br />
STOP<br />
REPEAT<br />
WAIT time(int, in 0.1secs)<br />
RESTART<br />
<br />
The cases are determined by the value of the input selected with the {{PARAMNAME|Scriptx Control}} parameter (where x stands for 1,2,3,4). The value ranges for the CASE statements are (see also [[Inputs_and_Functions#Overview_Diagram|Inputs and Functions: Overview Diagram]]):<br />
<br />
* CASE#DEFAULT: -166 ... +166<br />
* CASE#1: +333 ... +500<br />
* CASE#2: -500 ... -333<br />
* CASE#3: +216 ... +277<br />
* CASE#4: -277 ... -216<br />
<br />
Note that the ranges for CASE#1 and CASE#2 start at +333 and -333, respectively, which corresponds to ca 1833 us and 1167 us (roughly, this is very transmitter dependent). Default transmitter settings may not reach these values. Note also that the ranges for CASE#3 and CASE#4 are relatively narrow, and thus can easily be missed.<br />
<br />
'''''Parameter value commands:'''''<br />
SETP parametername(string) option(int, float or string)<br />
SETPMINMAX parametername(string) option(int, float or string) option(int, float or string)<br />
RESTORE<br />
RESTOREALL<br />
SET parametername(string) value(int)<br />
SETMINMAX parametername(string) minvalue(int) maxvalue(int)<br />
<br />
The commands {{BOX|SETP}} and {{BOX|SET}} are identical function-wise, namely set a parameter to a value, but differ in the second argument: In {{BOX|SETP}} the set-to value of the parameter is specified as it is displayed in the GUI (except of the unit in value fields), while in {{BOX|SET}} the new value is specified by its internal integer representation. For instance, if the parameter {{PARAMNAME|Camera Model}} should be set to {{PARAMVALUE|GoPro Hero5}}, then the {{BOX|SETP}} command would be {{BOX|SETP "Camera Model" "GoPro Hero5"}}, and the {{BOX|SET}} command would be {{BOX|SET "Camera Model" 10}} (since the option "GoPro Hero5" is internally represented by the integer 10) (you can check this with {{GUI|Share Settings}}).<br />
<br />
Similar holds for the second and third parameters in the {{BOX|SETPMINMAX}} and {{BOX|SETMINMAX}} commands.<br />
<br />
The {{BOX|SET}} and {{BOX|SETMINMAX}} commands are still existing for compatibility, but should not be used in new scripts (in fact, the script compiler replaced them with the newer {{BOX|SETP}} and {{BOX|SETPMINMAX}} commands).<br />
<br />
{{COMMENT|For some paramneters, a change of their setting initiates further actions, such as a restart of the controller. Changing their values in a script can lead to undetermined behavior, and shoucl thu snot be handled in scripts. Parameters of this kind are, e.g., {{PARAMNAME|Pitch Motor Usage}}, Roll Motor Usage, Yaw Motor Usage, Motor Mapping, and Imu Mapping.}<br />
<br />
<br />
'''''Function commands:'''''<br />
SETANGLEPITCH angle(float, in degree°)<br />
SETANGLEROLL angle(float, in degree°)<br />
SETANGLEYAW angle(float, in degree°)<br />
SETANGLE pitchangle(float, in degree°) rollangle(float, in degree°) yawangle(float, in degree°)<br />
SETANGLEPITCH_W angle(float, in degree°) time(int, in 0.1secs)<br />
SETANGLEROLL_W angle(float, in degree°) time(int, in 0.1secs)<br />
SETANGLEYAW_W angle(float, in degree°) time(int, in 0.1secs)<br />
SETSTANDBY 0/1<br />
SETRETRACT 0/1<br />
DOCAMERA 0/1/2/3/4<br />
DORECENTER<br />
DORECENTERPITCH<br />
DORECENTERROLL<br />
DORECENTERYAW<br />
DORECENTER_W time(int, in 0.1secs)<br />
DORECENTERPITCH_W time(int, in 0.1secs)<br />
DORECENTERROLL_W time(int, in 0.1secs)<br />
DORECENTERYAW_W time(int, in 0.1secs)<br />
SETPWM pwmvalue(int)<br />
SETPANOWAITS pitchtime(int, in 0.1secs) yawtime(int, in 0.1secs) shottime(int, in 0.1secs)<br />
SETPANORANGE yawangle(int, in degree°)<br />
SETPANOALLOWEXIT<br />
DOPANO pitchangle(int, in degree°) steps(int)<br />
BEEP<br />
<br />
Most function commands mirror serial RC commands (both in fact call the same internal functions). For further info thus please see [[Serial_Communication#Serial_Communication_-_RC_Commands|Serial Communication - RC Commands]].<br />
<br />
'''''Additional commands:'''''<br />
REMOTEENABLE<br />
REMOTEDISABLE<br />
<br />
The script function commands modify the very same set of internal variables which are also modified by the serial RC commands and MAVLink messages. This can lead to conflicts when the latter are used in combination with scripts, which can be resolved with the {{BOX|REMOTEDISABLE}}/{{BOX|REMOTEENABLE}} script commands. With {{BOX|REMOTEDISABLE}} the scripts are given priority over the serial RC and MAVLink commands. With {{BOX|REMOTEENABLE}} the default behavior is restored.<br />
<br />
SENDMAVTEXT text(string)<br />
SENDCAMTEXT text(string)<br />
<br />
The {{BOX|SENDMAVTEXT}} command triggers the emission of a MAVLink [https://mavlink.io/en/messages/common.html#STATUSTEXT STATUSTEXT] message. The text is the specified string, prepended by a label "STorM32:". The text string can be 24 characters long, and contain the characters '0'-'9', 'a'-'z', 'A'-'Z', ' '.<br />
<br />
The {{BOX|SENDCAMTEXT}} command sends the specified string, appended by a '\n' char, on the {{PARAMNAME|Camera ComPort}}. The text string can be 24 characters long, and contain the characters '0'-'9', 'a'-'z', 'A'-'Z', ' '. Only for {{PARAMNAME|Camera Model}} = {{PARAMVALUE|Serial Api}}.<br />
<br />
Prefer short text strings, in order to not exhaust the limited code space for scripts.<br />
<br />
== Examples ==<br />
<br />
=== Changing a Parameter via the Transmitter ===<br />
<br />
Adjusting the value of a parameter during operation by e.g. tuning a knob on a transmitter is probably the most basic use-case of the scripts.<br />
<br />
Let's consider GekoCH's application as an example (see [http://www.rcgroups.com/forums/showpost.php?p=29667070&postcount=19 here]): He's using a gimbal on a copter, and asked for the possibility to change the speed by which the camera turns upon a rc signal via another rc signal. He used a poti on the transmitter and the absolute mode to adjust the pitch orientation of the camera. It's obviously not possible to simultaneously fly the copter and to move the poti that precisely that a smooth camera motion is obtained, hence the {{PARAMNAME|Speed Limit}} feature was used. That is, the poti is quickly moved to the target orientation, and thanks to the speed limiter a smooth turn of the camera results. However, only one speed was possible before. Three solutions shall be discussed:<br />
<br />
'''''Method A'''''<br />
<br />
CASE#DEFAULT<br />
SETP "Rc Pitch Speed Limit" 40.0<br />
STOP<br />
CASE#1<br />
SETP "Rc Pitch Speed Limit" 5.0<br />
STOP<br />
<br />
When the input specified in the {{PARAMNAME|Script Control}} parameter field yields a "default" value, then the pitch speed limit is set to 40.0 °/s, respectively, while when the input value is such to trigger {{BOX|CASE#1}}, then the speed limit is set to 5.0 °/s. Every CASE statement needs to be finished with either a {{BOX|STOP}} or {{BOX|REPEAT}}. Here the {{BOX|STOP}} command is used, which means that the preceding {{BOX|SETP}} command is executed only once when the input value changes, and not every cycle again.<br />
<br />
At this point one may ask, which input values triggers which case? The full answer isn't trivial and needs a familiarity with the STorM32 controller. In the given example, the default case is selected then the poti is below ca. 33% (< 1633 us), and case #1 is triggered then the switch is above ca. 83% (> 1830 us).<br />
<br />
'''''Method B'''''<br />
<br />
SETPMINMAX "Rc Pitch Speed Limit" 5.0 40.0<br />
REPEAT<br />
<br />
The {{BOX|SETPMINMAX}} command linearly interpolates between the minimum value (5.0 °/s) and maximum value (40.0 °/s), depending on the input value. For instance, for an input value of 200 the pitch speed limit is set to 200 * (40.0-5.0)/1000 + (40.0+5.0)/2 = 29.5°/s. Hence, method B allows us to adjust the speed limit continuously in the range of 5.0 °/s to 40.0 °/s. The {{BOX|REPEAT}} command at the end ensures, that the {{BOX|SETPMINMAX}} command is executed at every cycle anew, and not just once, so that any change in the input value is quickly tracked.<br />
<br />
A video by GekoCH using this feature is [http://www.rcgroups.com/forums/showpost.php?p=30246328&postcount=2723 here].<br />
<br />
'''''Method C'''''<br />
<br />
CASE#DEFAULT<br />
RESTORE "Rc Pitch Speed Limit"<br />
STOP<br />
CASE#1<br />
SETP "Rc Pitch Speed Limit" 5.0<br />
STOP<br />
<br />
This example is essentially method A, but overcomes a minor yet potentially annoying issue. In method A, the parameter value specified in the {{PARAMVALUE|Rc Pitch Speed Limit}} field of the GUI is overwritten immediately by the script, and hence becomes obsolete. In most cases one would however prefer that the default value is determined by the entry in the GUI, and not by that in the script. This issue is resolved by the {{BOX|RESTORE}} command, which sets the {{PARAMVALUE|Rc Pitch Speed Limit}} parameter to the value stored in the EEPROM.<br />
<br />
A similar {{BOX|RESTOREALL}} command exists, which sets all parameters to their values stored in the EEPROM. However, for efficiency reasons it should not be used, except then it is really absolutely needed. Using several {{BOX|RESTORE}} commands is much preferred over using {{BOX|RESTOREALL}}. In short, avoid {{BOX|RESTOREALL}} if you can.<br />
<br />
'''''Concluding Remarks'''''<br />
<br />
Of course, one is not limited to only the {{PARAMNAME|Rc Pitch Speed Limit}} parameter. ANY other available parameter (except of the {{PARAMNAME|Script Control}} parameters as discussed before), can be used in the {{BOX|SET}} and {{BOX|SETPMINMAX}} commands and hence be modified by the scripts. Furthermore, any case statement can of course be followed by more than one command, such that complex situations can be tackled (it is though not possible to have another case statement within a case statement).<br />
<br />
Up to four cases can be distinguished, via the {{BOX|CASE#DEFAULT}}, {{BOX|CASE#1}}, {{BOX|CASE#2}}, and {{BOX|CASE#3}} statements. A case is chosen dependent on the value of the input selected by the {{PARAMNAME|Script Control}} parameter, in close analogy to all the other available functions such as the Rc Inputs, Pan Control or IR Camera Control, see also [[Inputs and Functions]].<br />
<br />
=== Running a Motion Control Sequence ===<br />
<br />
CASE#DEFAULT<br />
STOP<br />
CASE#1<br />
SETANGLE -22.5 0 31.5<br />
WAIT 20<br />
DOCAMERA 1<br />
SETANGLEYAW 0<br />
WAIT 20<br />
DOCAMERA 1<br />
SETANGLEYAW -31.5<br />
WAIT 20<br />
DOCAMERA 1<br />
SETANGLE 22.5 0 -31.5<br />
WAIT 20<br />
DOCAMERA 1<br />
SETANGLEYAW 0<br />
WAIT 20<br />
DOCAMERA 1<br />
SETANGLEYAW 31.5<br />
WAIT 20<br />
DOCAMERA 1<br />
DORECENTER<br />
STOP<br />
<br />
This short sequence consumes already 62 of the 128 bytes, which shows that only relatively short motion control sequences are possible with the on-board scripts.<br />
<br />
=== Running a Pano Sequence ===<br />
<br />
The previous motion control sequence allows to record a pano, which however is severely limited by the maximal possible script code size. Thus, more powerful commands were introduced, which allow quite extensive pano shots.<br />
<br />
CASE#DEFAULT<br />
DORECENTER<br />
STOP<br />
CASE#1<br />
SETANGLEYAW_W 45 30<br />
SETPANOWAITS 30 30 10<br />
SETPANORANGE 90<br />
DOPANO 30 -8<br />
DOPANO 0 8<br />
DOPANO -30 -8<br />
STOP<br />
<br />
The {{BOX|SETANGLEYAW_W}} command sets the yaw angle to 45°, and waits 3.0 secs in addition to the predicted time for the turn. <br />
<br />
The {{BOX|SETPANOWAITS}} and {{BOX|SETPANORANGE}} commands set some "global" parameters of the pano, namely the time to wait after each pitch movement, the time to wait after each yaw step, the time to wait before each shot, and the total yaw angle range which shall be covered. <br />
<br />
The {{BOX|DOPANO}} commands finally run the pano sequence. The first {{BOX|DOPANO}} command, e.g., sets the pitch angle to 30°, and then does 8 yaw steps in counterclockwise direction. In each step the yaw axis is progressed by 90°/8 = 11.25°. Similarly for the next two {{BOX|DOPANAO}} commands.<br />
<br />
In the above example, the pano cannot be terminated during execution. That is, the script is executed command by command until it reaches the {{BOX|STOP}} command, and only then it is tested if the input has changed and whether it should jump to CASE#DEFAULT. Often this is the desired behavior, e.g. when the pano is triggered with a momentary push button. Often it is however desired that the pano runs for as long as the input is set but is terminated then it is cleared. A typical use case would be when the pano is triggered with a transmitter switch, there one might want it to run when the switch is flipped but be stopped when the switch is cleared, even if the pano is not yet completed. This can be accomplished with the {{BOX|SETPANOALLOWEXIT}} command. An example script would be<br />
<br />
CASE#DEFAULT<br />
STOP<br />
CASE#1<br />
SETANGLEYAW_W 45 30<br />
SETPANOWAITS 30 30 10<br />
SETPANORANGE 90<br />
SETPANOALLOWEXIT<br />
DOPANO 30 -8<br />
WAIT 10<br />
DOPANO -30 8<br />
DORECENTER<br />
STOP<br />
<br />
Note that here only the {{BOX|DOPANO}} commands are cut short if the input becomes different from CASE#1, but that the other commands are still executed until the {{BOX|STOP}} command is reached. That is, in the example, if the input changes while the first {{BOX|DOPANO}} command is executed, the {{BOX|WAIT}} and {{BOX|DORECENTER}} commands would be still executed.<br />
<br />
=== Running a Script in Combination with Serial and MAVLink Commands ===<br />
<br />
The serial RC commands and the MAVLink messages all set the very same internal variables which are also set by the scripts, and conflicts can accordingly occur.<br />
<br />
Such a situation occurs, e.g., when the STorM32 controller is connected to an ArduPilot flight controller via MAVLink, and a continuous stream of DO_MOUNT_CONTROL (or similar) MAVLink commands is sent to the STorM32 controller. In this case a pano script for instance would appear to not work since the commands for setting the angle of the gimbal emitted by the script would be nearly instantaneously overwritten by the DO_MOUNT_CONTROL (or similar) MAVLink commands received from the flight controller. <br />
<br />
Such situations can be resolved by using the {{BOX|REMOTEDISABLE}} and {{BOX|REMOTEENABLE}} script commands. {{BOX|REMOTEDISABLE}} gives the script priority, and essentially disables the serial and MAVLink commands. With {{BOX|REMOTEENABLE}} the default behavior is restored.<br />
<br />
A script using this mechanism would typically look like <br />
<br />
CASE#DEFAULT<br />
STOP<br />
CASE#1<br />
REMOTEDISABLE<br />
...<br />
REMOTEENABLE<br />
STOP<br />
<br />
or<br />
<br />
CASE#DEFAULT<br />
REMOTEDISABLE<br />
STOP<br />
CASE#1<br />
REMOTEENABLE<br />
...<br />
STOP<br />
<br />
The two script do not exactly work the same and which one to use depends on the actual script. The behavior of the second example could also be achieved as<br />
<br />
REMOTEENABLE<br />
CASE#DEFAULT<br />
REMOTEDISABLE<br />
STOP<br />
CASE#1<br />
...<br />
STOP<br />
<br />
which might be easier to write.<br />
<br />
== User Examples ==<br />
<br />
=== Switching Between Two Alternate Functions of a Continuous RC Channel Using a "Shift Key" ===<br />
<br />
''by Hb121280, see also [https://www.rcgroups.com/forums/showthread.php?2262624-STorM32-BGC-Scripts-Discussion-and-Development-Thread/page2&perpage=50#post39876923]''<br />
<br />
Imagine you want to control gimbal pitch and gimbal yaw using an analog dial on the remote control, but only one analog dial is available. This example uses a button channel to switch between alternate functions of one continuous channel.<br />
<br />
CASE#DEFAULT<br />
SETP "Rc Pitch" "Virtual-8"<br />
SETP "Rc Yaw" "off"<br />
STOP<br />
CASE#1<br />
SETP "Rc Pitch" "Virtual-8"<br />
SETP "Rc Yaw" "off"<br />
STOP<br />
CASE#2<br />
SETP "Rc Pitch" "Virtual-8"<br />
SETP "Rc Yaw" "off"<br />
STOP<br />
CASE#3<br />
SETP "Rc Pitch" "off"<br />
SETP "Rc Yaw" "Virtual-8"<br />
STOP<br />
<br />
The {{PARAMNAME|Script Control}} variable is set to the button channel, e.g. {{PARAMVALUE|Virtual-8}}. In the present case the button channel delivers a value 0 in case it is not pressed and 254 if it is pressed. According to [[Inputs_and_Functions#Overview_Diagram|Inputs and Functions: Overview Diagram]], the value ranges for the CASE statements are:<br />
<br />
* CASE#DEFAULT: -166 ... +166<br />
* CASE#1: +333 ... +500<br />
* CASE#2: -500 ... -333<br />
* CASE#3: +216 ... +277<br />
<br />
Thus, the cases CASE#DEFAULT and CASE#3 have to be used, because the button values 0 (not pressed) and 254 (pressed) fall into their value ranges. The script language does not allow 'missing' case statements, and CASE#1 and CASE#2 need also to be specified (they can be filled with any commands, since they never would be triggered).<br />
<br />
In the above script, the standard behavior (button not pressed) uses the analog channel, or input {{PARAMVALUE|Virtual-8}}, for {{PARAMNAME|Rc Pitch}}. {{PARAMNAME|Rc Yaw}} is accordingly set to {{PARAMVALUE|off}}. Pressing the button reverses the assignments: The analog channel on input {{PARAMVALUE|Virtual-8}} is now used for {{PARAMNAME|Rc Yaw}}, and the control of pitch is deactivated.</div>OlliWhttp://www.olliw.eu/storm32bgc-v2-wiki/index.php?title=Downloads&diff=11892Downloads2025-11-17T16:52:03Z<p>OlliW: </p>
<hr />
<div>{{ALERT| '''PLEASE READ THIS FIRST''' <br />
There are 2 types of IMU modules which STorM32 v1.3x controllers can use, NT IMUs and I2C IMUs, and there are 2 firmwares which correspond to each type. It is important to choose the correct firmware, otherwise your controller and gimbal will not work. Read this page to understand the difference between the two types of IMUs [[//www.olliw.eu/storm32bgc-v2-wiki/What_is_STorM32_NT_about%3F]], and this post to identify your IMU [[//www.rcgroups.com/forums/showpost.php?p=38258334&postcount=10256]]. <br />
<br />
The STorM32 v3.x, v4.x, v6.x controllers can only use NT IMUs, not I2C IMUs.<br />
<br />
Only firmwares with version v0.96 or less work with I2C IMUs. Firmwares with version numbers v2.xx are not usable for setups with I2C IMU. If you do not know what a NT IMU is, then you likely have a I2C IMU and need firmware v0.96.}} <br />
<br/><br />
{{ALERT| '''ANNOUNCEMENTS'''<br />
- The v2.xx firmware series will phase out, i.e., currently it is planned that firmware 2.74 is the last release in this series. <br/><br />
- Development will shift to [//www.olliw.eu/storm32bgc-wiki STorM32 v3]. STorM32 v3 will not support the old and tried v1.3x boards, as well as not the v3.3 and v4.1 boards. Reason is that the STM32F103 microcontroller used on these boards has simply become too limited.<br />
<!--- Support of the v1.3x STorM32 boards will phase out. That is, the next official release (whenever this will be), will be the last release which supports these old and tried main boards. Reason is that since few years I have migrated to the STM32 HAL&LL libraries, but the v1.3x code is still on the legacy SPL library since it's I2C is ca 50-100 us faster than the HAL I2C lib. So I maintain two codes, which is obviously not sustainable.<br />
- Support for quite a number of presumably "old" cameras will phase out. Some of them are so old that it's hard to imagine they are still in use. Examples are Git2, Mapir Survey, Firefly Split 4K, Runcam, GoPro Hero5&7.-->}}<br />
<br />
== v2.xx Firmware for NT IMUs ==<br />
<br />
Firmware for STorM32 setups using a NT camera IMU. <br />
<br />
<br />
Direct link to v2.53 firmware download (this firmware is pretty old, it is highly recommended to use v2.67e):<br> <br />
<br />
:[//github.com/olliw42/storm32bgc/raw/main/firmware%20binaries%20%26%20gui/o323bgc-release-v253-v20200517.zip o323bgc-release-v253-v20200517] [.zip] (12.2 MB)<br />
:[//www.rcgroups.com/forums/showpost.php?p=44539519&postcount=12349 Release Notes]<br />
<br />
<br />
Latest beta release v2.73e:<br><br />
:[//github.com/olliw42/storm32bgc/raw/main/firmware%20binaries%20%26%20gui/o323bgc-release-v273e-v20250711.zip o323bgc-release-v273e-v20250711] [.zip] (15.9 MB)<br />
:[https://www.rcgroups.com/forums/showpost.php?p=53978973&postcount=15988 Release Notes]<br />
<br />
<br />
NTLoggerTool release v0.50:<br><br />
:[//www.olliw.eu/downloads/storm32/ntloggertool/ntloggertool-release-v050-v20231003.zip ntloggertool-release-v050-v20231003] [.zip] (295 MB)<br />
<br />
<br />
BetaCopter/BetaPlane 4.7-dev:<br><br />
:For downloading the firmwares and all further info please visit the article [[Using STorM32 with BetaPilot]].<br />
<br />
== v0.96 Firmware for I2C IMUs ==<br />
<br />
Firmware for STorM32 setups using a I2C camera IMU. Examples are the HakRC gimbal and other gimbals from Aliexpress.<br />
<br />
Latest firmware v0.96 for I2C IMUs:<br> <br />
:[//github.com/olliw42/storm32bgc/raw/master/firmware%20binaries%20%26%20gui/o323bgc-release-v096-v20160319.zip o323bgc-release-v096-v20160319] [.zip] (9.4MB)<br />
<br />
Note: This wiki here is not appropriate for v0.96 I2C setups, you should go to [//www.olliw.eu/storm32bgc-v1-wiki/Main_Page STorM32 v0.xx Wiki].<br />
<br />
{{COMMENT|The v0.96 release also includes firmwares for NT IMUs, identifiable by a label "nt" in the file names. Don't use them, use the v0.96 firmware (without a "nt" in the file name).}}<br />
<br />
== Repository ==<br />
<br />
Various files related to the STorM32-BGC project can be downloaded from several places:<br />
* [//github.com/olliw42/storm32bgc Github repository]<br />
* 1st page of the [//www.rcgroups.com/forums/showthread.php?t=2055844 rcgroups discussion thread]</div>OlliWhttp://www.olliw.eu/storm32bgc-v2-wiki/index.php?title=Downloads&diff=11891Downloads2025-11-17T16:51:12Z<p>OlliW: </p>
<hr />
<div>{{ALERT| '''PLEASE READ THIS FIRST''' <br />
There are 2 types of IMU modules which STorM32 v1.3x controllers can use, NT IMUs and I2C IMUs, and there are 2 firmwares which correspond to each type. It is important to choose the correct firmware, otherwise your controller and gimbal will not work. Read this page to understand the difference between the two types of IMUs [[//www.olliw.eu/storm32bgc-v2-wiki/What_is_STorM32_NT_about%3F]], and this post to identify your IMU [[//www.rcgroups.com/forums/showpost.php?p=38258334&postcount=10256]]. <br />
<br />
The STorM32 v3.x, v4.x, v6.x controllers can only use NT IMUs, not I2C IMUs.<br />
<br />
Only firmwares with version v0.96 or less work with I2C IMUs. Firmwares with version numbers v2.xx are not usable for setups with I2C IMU. If you do not know what a NT IMU is, then you likely have a I2C IMU and need firmware v0.96.}} <br />
<br/><br />
{{ALERT| '''ANNOUNCEMENTS'''<br />
- The v2.xx firmware series will phase out, i.e., currently it is planned that firmware 2.74 is the last release in this series. <br/><br />
- Development will shift to [//www.olliw.eu/storm32bgc-wiki STorM32 v3]. STorM32 v3 will not support the old and tried v1.3x boards, as well as not the v3.3 and v4.1 boards. The reason is that the STM32F103 microcontroller used on these boards has simply become too limited.<br />
<!--- Support of the v1.3x STorM32 boards will phase out. That is, the next official release (whenever this will be), will be the last release which supports these old and tried main boards. Reason is that since few years I have migrated to the STM32 HAL&LL libraries, but the v1.3x code is still on the legacy SPL library since it's I2C is ca 50-100 us faster than the HAL I2C lib. So I maintain two codes, which is obviously not sustainable.<br />
- Support for quite a number of presumably "old" cameras will phase out. Some of them are so old that it's hard to imagine they are still in use. Examples are Git2, Mapir Survey, Firefly Split 4K, Runcam, GoPro Hero5&7.-->}}<br />
<br />
== v2.xx Firmware for NT IMUs ==<br />
<br />
Firmware for STorM32 setups using a NT camera IMU. <br />
<br />
<br />
Direct link to v2.53 firmware download (this firmware is pretty old, it is highly recommended to use v2.67e):<br> <br />
<br />
:[//github.com/olliw42/storm32bgc/raw/main/firmware%20binaries%20%26%20gui/o323bgc-release-v253-v20200517.zip o323bgc-release-v253-v20200517] [.zip] (12.2 MB)<br />
:[//www.rcgroups.com/forums/showpost.php?p=44539519&postcount=12349 Release Notes]<br />
<br />
<br />
Latest beta release v2.73e:<br><br />
:[//github.com/olliw42/storm32bgc/raw/main/firmware%20binaries%20%26%20gui/o323bgc-release-v273e-v20250711.zip o323bgc-release-v273e-v20250711] [.zip] (15.9 MB)<br />
:[https://www.rcgroups.com/forums/showpost.php?p=53978973&postcount=15988 Release Notes]<br />
<br />
<br />
NTLoggerTool release v0.50:<br><br />
:[//www.olliw.eu/downloads/storm32/ntloggertool/ntloggertool-release-v050-v20231003.zip ntloggertool-release-v050-v20231003] [.zip] (295 MB)<br />
<br />
<br />
BetaCopter/BetaPlane 4.7-dev:<br><br />
:For downloading the firmwares and all further info please visit the article [[Using STorM32 with BetaPilot]].<br />
<br />
== v0.96 Firmware for I2C IMUs ==<br />
<br />
Firmware for STorM32 setups using a I2C camera IMU. Examples are the HakRC gimbal and other gimbals from Aliexpress.<br />
<br />
Latest firmware v0.96 for I2C IMUs:<br> <br />
:[//github.com/olliw42/storm32bgc/raw/master/firmware%20binaries%20%26%20gui/o323bgc-release-v096-v20160319.zip o323bgc-release-v096-v20160319] [.zip] (9.4MB)<br />
<br />
Note: This wiki here is not appropriate for v0.96 I2C setups, you should go to [//www.olliw.eu/storm32bgc-v1-wiki/Main_Page STorM32 v0.xx Wiki].<br />
<br />
{{COMMENT|The v0.96 release also includes firmwares for NT IMUs, identifiable by a label "nt" in the file names. Don't use them, use the v0.96 firmware (without a "nt" in the file name).}}<br />
<br />
== Repository ==<br />
<br />
Various files related to the STorM32-BGC project can be downloaded from several places:<br />
* [//github.com/olliw42/storm32bgc Github repository]<br />
* 1st page of the [//www.rcgroups.com/forums/showthread.php?t=2055844 rcgroups discussion thread]</div>OlliWhttp://www.olliw.eu/storm32bgc-v2-wiki/index.php?title=Downloads&diff=11890Downloads2025-11-17T16:50:53Z<p>OlliW: </p>
<hr />
<div>{{ALERT| '''PLEASE READ THIS FIRST''' <br />
There are 2 types of IMU modules which STorM32 v1.3x controllers can use, NT IMUs and I2C IMUs, and there are 2 firmwares which correspond to each type. It is important to choose the correct firmware, otherwise your controller and gimbal will not work. Read this page to understand the difference between the two types of IMUs [[//www.olliw.eu/storm32bgc-v2-wiki/What_is_STorM32_NT_about%3F]], and this post to identify your IMU [[//www.rcgroups.com/forums/showpost.php?p=38258334&postcount=10256]]. <br />
<br />
The STorM32 v3.x, v4.x, v6.x controllers can only use NT IMUs, not I2C IMUs.<br />
<br />
Only firmwares with version v0.96 or less work with I2C IMUs. Firmwares with version numbers v2.xx are not usable for setups with I2C IMU. If you do not know what a NT IMU is, then you likely have a I2C IMU and need firmware v0.96.}} <br />
<br/><br />
{{ALERT| '''ANNOUNCEMENTS'''<br />
- The v2.xx firmware series will phase out, i.e., currently it is planned that firmware 2.74 is the last release in this series.<br />
- Development will shift to [//www.olliw.eu/storm32bgc-wiki STorM32 v3]. STorM32 v3 will not support the old and tried v1.3x boards, as well as not the v3.3 and v4.1 boards. The reason is that the STM32F103 microcontroller used on these boards has simply become too limited.<br />
<!--- Support of the v1.3x STorM32 boards will phase out. That is, the next official release (whenever this will be), will be the last release which supports these old and tried main boards. Reason is that since few years I have migrated to the STM32 HAL&LL libraries, but the v1.3x code is still on the legacy SPL library since it's I2C is ca 50-100 us faster than the HAL I2C lib. So I maintain two codes, which is obviously not sustainable.<br />
- Support for quite a number of presumably "old" cameras will phase out. Some of them are so old that it's hard to imagine they are still in use. Examples are Git2, Mapir Survey, Firefly Split 4K, Runcam, GoPro Hero5&7.-->}}<br />
<br />
== v2.xx Firmware for NT IMUs ==<br />
<br />
Firmware for STorM32 setups using a NT camera IMU. <br />
<br />
<br />
Direct link to v2.53 firmware download (this firmware is pretty old, it is highly recommended to use v2.67e):<br> <br />
<br />
:[//github.com/olliw42/storm32bgc/raw/main/firmware%20binaries%20%26%20gui/o323bgc-release-v253-v20200517.zip o323bgc-release-v253-v20200517] [.zip] (12.2 MB)<br />
:[//www.rcgroups.com/forums/showpost.php?p=44539519&postcount=12349 Release Notes]<br />
<br />
<br />
Latest beta release v2.73e:<br><br />
:[//github.com/olliw42/storm32bgc/raw/main/firmware%20binaries%20%26%20gui/o323bgc-release-v273e-v20250711.zip o323bgc-release-v273e-v20250711] [.zip] (15.9 MB)<br />
:[https://www.rcgroups.com/forums/showpost.php?p=53978973&postcount=15988 Release Notes]<br />
<br />
<br />
NTLoggerTool release v0.50:<br><br />
:[//www.olliw.eu/downloads/storm32/ntloggertool/ntloggertool-release-v050-v20231003.zip ntloggertool-release-v050-v20231003] [.zip] (295 MB)<br />
<br />
<br />
BetaCopter/BetaPlane 4.7-dev:<br><br />
:For downloading the firmwares and all further info please visit the article [[Using STorM32 with BetaPilot]].<br />
<br />
== v0.96 Firmware for I2C IMUs ==<br />
<br />
Firmware for STorM32 setups using a I2C camera IMU. Examples are the HakRC gimbal and other gimbals from Aliexpress.<br />
<br />
Latest firmware v0.96 for I2C IMUs:<br> <br />
:[//github.com/olliw42/storm32bgc/raw/master/firmware%20binaries%20%26%20gui/o323bgc-release-v096-v20160319.zip o323bgc-release-v096-v20160319] [.zip] (9.4MB)<br />
<br />
Note: This wiki here is not appropriate for v0.96 I2C setups, you should go to [//www.olliw.eu/storm32bgc-v1-wiki/Main_Page STorM32 v0.xx Wiki].<br />
<br />
{{COMMENT|The v0.96 release also includes firmwares for NT IMUs, identifiable by a label "nt" in the file names. Don't use them, use the v0.96 firmware (without a "nt" in the file name).}}<br />
<br />
== Repository ==<br />
<br />
Various files related to the STorM32-BGC project can be downloaded from several places:<br />
* [//github.com/olliw42/storm32bgc Github repository]<br />
* 1st page of the [//www.rcgroups.com/forums/showthread.php?t=2055844 rcgroups discussion thread]</div>OlliWhttp://www.olliw.eu/storm32bgc-v2-wiki/index.php?title=Downloads&diff=11889Downloads2025-11-17T16:50:34Z<p>OlliW: </p>
<hr />
<div>{{ALERT| '''PLEASE READ THIS FIRST''' <br />
There are 2 types of IMU modules which STorM32 v1.3x controllers can use, NT IMUs and I2C IMUs, and there are 2 firmwares which correspond to each type. It is important to choose the correct firmware, otherwise your controller and gimbal will not work. Read this page to understand the difference between the two types of IMUs [[//www.olliw.eu/storm32bgc-v2-wiki/What_is_STorM32_NT_about%3F]], and this post to identify your IMU [[//www.rcgroups.com/forums/showpost.php?p=38258334&postcount=10256]]. <br />
<br />
The STorM32 v3.x, v4.x, v6.x controllers can only use NT IMUs, not I2C IMUs.<br />
<br />
Only firmwares with version v0.96 or less work with I2C IMUs. Firmwares with version numbers v2.xx are not usable for setups with I2C IMU. If you do not know what a NT IMU is, then you likely have a I2C IMU and need firmware v0.96.}} <br />
<br/><br />
{{ALERT| '''ANNOUNCEMENTS'''<br />
- The v2.xx firmware series will phase out, i.e., currently it is planned that firmware 2.74 is the last release in this series. <br />
- Development will shift to [//www.olliw.eu/storm32bgc-wiki STorM32 v3]. STorM32 v3 will not support the old and tried v1.3x boards, as well as not the v3.3 and v4.1 boards. The reason is that the STM32F103 microcontroller used on these boards has simply become too limited.<br />
<!--- Support of the v1.3x STorM32 boards will phase out. That is, the next official release (whenever this will be), will be the last release which supports these old and tried main boards. Reason is that since few years I have migrated to the STM32 HAL&LL libraries, but the v1.3x code is still on the legacy SPL library since it's I2C is ca 50-100 us faster than the HAL I2C lib. So I maintain two codes, which is obviously not sustainable.<br />
- Support for quite a number of presumably "old" cameras will phase out. Some of them are so old that it's hard to imagine they are still in use. Examples are Git2, Mapir Survey, Firefly Split 4K, Runcam, GoPro Hero5&7.-->}}<br />
<br />
== v2.xx Firmware for NT IMUs ==<br />
<br />
Firmware for STorM32 setups using a NT camera IMU. <br />
<br />
<br />
Direct link to v2.53 firmware download (this firmware is pretty old, it is highly recommended to use v2.67e):<br> <br />
<br />
:[//github.com/olliw42/storm32bgc/raw/main/firmware%20binaries%20%26%20gui/o323bgc-release-v253-v20200517.zip o323bgc-release-v253-v20200517] [.zip] (12.2 MB)<br />
:[//www.rcgroups.com/forums/showpost.php?p=44539519&postcount=12349 Release Notes]<br />
<br />
<br />
Latest beta release v2.73e:<br><br />
:[//github.com/olliw42/storm32bgc/raw/main/firmware%20binaries%20%26%20gui/o323bgc-release-v273e-v20250711.zip o323bgc-release-v273e-v20250711] [.zip] (15.9 MB)<br />
:[https://www.rcgroups.com/forums/showpost.php?p=53978973&postcount=15988 Release Notes]<br />
<br />
<br />
NTLoggerTool release v0.50:<br><br />
:[//www.olliw.eu/downloads/storm32/ntloggertool/ntloggertool-release-v050-v20231003.zip ntloggertool-release-v050-v20231003] [.zip] (295 MB)<br />
<br />
<br />
BetaCopter/BetaPlane 4.7-dev:<br><br />
:For downloading the firmwares and all further info please visit the article [[Using STorM32 with BetaPilot]].<br />
<br />
== v0.96 Firmware for I2C IMUs ==<br />
<br />
Firmware for STorM32 setups using a I2C camera IMU. Examples are the HakRC gimbal and other gimbals from Aliexpress.<br />
<br />
Latest firmware v0.96 for I2C IMUs:<br> <br />
:[//github.com/olliw42/storm32bgc/raw/master/firmware%20binaries%20%26%20gui/o323bgc-release-v096-v20160319.zip o323bgc-release-v096-v20160319] [.zip] (9.4MB)<br />
<br />
Note: This wiki here is not appropriate for v0.96 I2C setups, you should go to [//www.olliw.eu/storm32bgc-v1-wiki/Main_Page STorM32 v0.xx Wiki].<br />
<br />
{{COMMENT|The v0.96 release also includes firmwares for NT IMUs, identifiable by a label "nt" in the file names. Don't use them, use the v0.96 firmware (without a "nt" in the file name).}}<br />
<br />
== Repository ==<br />
<br />
Various files related to the STorM32-BGC project can be downloaded from several places:<br />
* [//github.com/olliw42/storm32bgc Github repository]<br />
* 1st page of the [//www.rcgroups.com/forums/showthread.php?t=2055844 rcgroups discussion thread]</div>OlliWhttp://www.olliw.eu/storm32bgc-v2-wiki/index.php?title=Downloads&diff=11888Downloads2025-11-17T16:49:54Z<p>OlliW: </p>
<hr />
<div>{{ALERT| '''PLEASE READ THIS FIRST''' <br />
There are 2 types of IMU modules which STorM32 v1.3x controllers can use, NT IMUs and I2C IMUs, and there are 2 firmwares which correspond to each type. It is important to choose the correct firmware, otherwise your controller and gimbal will not work. Read this page to understand the difference between the two types of IMUs [[//www.olliw.eu/storm32bgc-v2-wiki/What_is_STorM32_NT_about%3F]], and this post to identify your IMU [[//www.rcgroups.com/forums/showpost.php?p=38258334&postcount=10256]]. <br />
<br />
The STorM32 v3.x, v4.x, v6.x controllers can only use NT IMUs, not I2C IMUs.<br />
<br />
Only firmwares with version v0.96 or less work with I2C IMUs. Firmwares with version numbers v2.xx are not usable for setups with I2C IMU. If you do not know what a NT IMU is, then you likely have a I2C IMU and need firmware v0.96.}} <br />
<br/><br />
{{ALERT| '''ANNOUNCEMENTS'''<br />
- The v2.xx firmware series will phase out, i.e., currently it is planned that firmware 2.74 is the last release in this series. Development will shift to [//www.olliw.eu/storm32bgc-wiki STorM32 v3].<br />
- STorM32 v3 will not support the old and tried v1.3x boards, as well as not the v3.3 and v4.1 boards. The reason is that the STM32F103 microcontroller used on these boards has simply become too limited.<br />
<!--- Support of the v1.3x STorM32 boards will phase out. That is, the next official release (whenever this will be), will be the last release which supports these old and tried main boards. Reason is that since few years I have migrated to the STM32 HAL&LL libraries, but the v1.3x code is still on the legacy SPL library since it's I2C is ca 50-100 us faster than the HAL I2C lib. So I maintain two codes, which is obviously not sustainable.<br />
- Support for quite a number of presumably "old" cameras will phase out. Some of them are so old that it's hard to imagine they are still in use. Examples are Git2, Mapir Survey, Firefly Split 4K, Runcam, GoPro Hero5&7.-->}}<br />
<br />
== v2.xx Firmware for NT IMUs ==<br />
<br />
Firmware for STorM32 setups using a NT camera IMU. <br />
<br />
<br />
Direct link to v2.53 firmware download (this firmware is pretty old, it is highly recommended to use v2.67e):<br> <br />
<br />
:[//github.com/olliw42/storm32bgc/raw/main/firmware%20binaries%20%26%20gui/o323bgc-release-v253-v20200517.zip o323bgc-release-v253-v20200517] [.zip] (12.2 MB)<br />
:[//www.rcgroups.com/forums/showpost.php?p=44539519&postcount=12349 Release Notes]<br />
<br />
<br />
Latest beta release v2.73e:<br><br />
:[//github.com/olliw42/storm32bgc/raw/main/firmware%20binaries%20%26%20gui/o323bgc-release-v273e-v20250711.zip o323bgc-release-v273e-v20250711] [.zip] (15.9 MB)<br />
:[https://www.rcgroups.com/forums/showpost.php?p=53978973&postcount=15988 Release Notes]<br />
<br />
<br />
NTLoggerTool release v0.50:<br><br />
:[//www.olliw.eu/downloads/storm32/ntloggertool/ntloggertool-release-v050-v20231003.zip ntloggertool-release-v050-v20231003] [.zip] (295 MB)<br />
<br />
<br />
BetaCopter/BetaPlane 4.7-dev:<br><br />
:For downloading the firmwares and all further info please visit the article [[Using STorM32 with BetaPilot]].<br />
<br />
== v0.96 Firmware for I2C IMUs ==<br />
<br />
Firmware for STorM32 setups using a I2C camera IMU. Examples are the HakRC gimbal and other gimbals from Aliexpress.<br />
<br />
Latest firmware v0.96 for I2C IMUs:<br> <br />
:[//github.com/olliw42/storm32bgc/raw/master/firmware%20binaries%20%26%20gui/o323bgc-release-v096-v20160319.zip o323bgc-release-v096-v20160319] [.zip] (9.4MB)<br />
<br />
Note: This wiki here is not appropriate for v0.96 I2C setups, you should go to [//www.olliw.eu/storm32bgc-v1-wiki/Main_Page STorM32 v0.xx Wiki].<br />
<br />
{{COMMENT|The v0.96 release also includes firmwares for NT IMUs, identifiable by a label "nt" in the file names. Don't use them, use the v0.96 firmware (without a "nt" in the file name).}}<br />
<br />
== Repository ==<br />
<br />
Various files related to the STorM32-BGC project can be downloaded from several places:<br />
* [//github.com/olliw42/storm32bgc Github repository]<br />
* 1st page of the [//www.rcgroups.com/forums/showthread.php?t=2055844 rcgroups discussion thread]</div>OlliWhttp://www.olliw.eu/storm32bgc-v2-wiki/index.php?title=Downloads&diff=11887Downloads2025-11-17T16:45:15Z<p>OlliW: </p>
<hr />
<div>{{ALERT| '''PLEASE READ THIS FIRST''' <br />
There are 2 types of IMU modules which STorM32 v1.3x controllers can use, NT IMUs and I2C IMUs, and there are 2 firmwares which correspond to each type. It is important to choose the correct firmware, otherwise your controller and gimbal will not work. Read this page to understand the difference between the two types of IMUs [[//www.olliw.eu/storm32bgc-v2-wiki/What_is_STorM32_NT_about%3F]], and this post to identify your IMU [[//www.rcgroups.com/forums/showpost.php?p=38258334&postcount=10256]]. <br />
<br />
The STorM32 v3.x, v4.x, v6.x controllers can only use NT IMUs, not I2C IMUs.<br />
<br />
Only firmwares with version v0.96 or less work with I2C IMUs. Firmwares with version numbers v2.xx are not usable for setups with I2C IMU. If you do not know what a NT IMU is, then you likely have a I2C IMU and need firmware v0.96.}} <br />
<br/><br />
{{ALERT| '''ANNOUNCEMENTS'''<br />
- The v2.xx firmware series will phase out, i.e., currently it is planned that firmware 2.74 is the last release in this series. Development will shift to [//www.olliw.eu/storm32bgc-wiki STorM32 v3].<br />
<!--- Support of the v1.3x STorM32 boards will phase out. That is, the next official release (whenever this will be), will be the last release which supports these old and tried main boards. Reason is that since few years I have migrated to the STM32 HAL&LL libraries, but the v1.3x code is still on the legacy SPL library since it's I2C is ca 50-100 us faster than the HAL I2C lib. So I maintain two codes, which is obviously not sustainable.<br />
- Support for quite a number of presumably "old" cameras will phase out. Some of them are so old that it's hard to imagine they are still in use. Examples are Git2, Mapir Survey, Firefly Split 4K, Runcam, GoPro Hero5&7.-->}}<br />
<br />
== v2.xx Firmware for NT IMUs ==<br />
<br />
Firmware for STorM32 setups using a NT camera IMU. <br />
<br />
<br />
Direct link to v2.53 firmware download (this firmware is pretty old, it is highly recommended to use v2.67e):<br> <br />
<br />
:[//github.com/olliw42/storm32bgc/raw/main/firmware%20binaries%20%26%20gui/o323bgc-release-v253-v20200517.zip o323bgc-release-v253-v20200517] [.zip] (12.2 MB)<br />
:[//www.rcgroups.com/forums/showpost.php?p=44539519&postcount=12349 Release Notes]<br />
<br />
<br />
Latest beta release v2.73e:<br><br />
:[//github.com/olliw42/storm32bgc/raw/main/firmware%20binaries%20%26%20gui/o323bgc-release-v273e-v20250711.zip o323bgc-release-v273e-v20250711] [.zip] (15.9 MB)<br />
:[https://www.rcgroups.com/forums/showpost.php?p=53978973&postcount=15988 Release Notes]<br />
<br />
<br />
NTLoggerTool release v0.50:<br><br />
:[//www.olliw.eu/downloads/storm32/ntloggertool/ntloggertool-release-v050-v20231003.zip ntloggertool-release-v050-v20231003] [.zip] (295 MB)<br />
<br />
<br />
BetaCopter/BetaPlane 4.7-dev:<br><br />
:For downloading the firmwares and all further info please visit the article [[Using STorM32 with BetaPilot]].<br />
<br />
== v0.96 Firmware for I2C IMUs ==<br />
<br />
Firmware for STorM32 setups using a I2C camera IMU. Examples are the HakRC gimbal and other gimbals from Aliexpress.<br />
<br />
Latest firmware v0.96 for I2C IMUs:<br> <br />
:[//github.com/olliw42/storm32bgc/raw/master/firmware%20binaries%20%26%20gui/o323bgc-release-v096-v20160319.zip o323bgc-release-v096-v20160319] [.zip] (9.4MB)<br />
<br />
Note: This wiki here is not appropriate for v0.96 I2C setups, you should go to [//www.olliw.eu/storm32bgc-v1-wiki/Main_Page STorM32 v0.xx Wiki].<br />
<br />
{{COMMENT|The v0.96 release also includes firmwares for NT IMUs, identifiable by a label "nt" in the file names. Don't use them, use the v0.96 firmware (without a "nt" in the file name).}}<br />
<br />
== Repository ==<br />
<br />
Various files related to the STorM32-BGC project can be downloaded from several places:<br />
* [//github.com/olliw42/storm32bgc Github repository]<br />
* 1st page of the [//www.rcgroups.com/forums/showthread.php?t=2055844 rcgroups discussion thread]</div>OlliWhttp://www.olliw.eu/storm32bgc-v2-wiki/index.php?title=Downloads&diff=11886Downloads2025-11-17T16:44:59Z<p>OlliW: </p>
<hr />
<div>{{ALERT| '''PLEASE READ THIS FIRST''' <br />
There are 2 types of IMU modules which STorM32 v1.3x controllers can use, NT IMUs and I2C IMUs, and there are 2 firmwares which correspond to each type. It is important to choose the correct firmware, otherwise your controller and gimbal will not work. Read this page to understand the difference between the two types of IMUs [[//www.olliw.eu/storm32bgc-v2-wiki/What_is_STorM32_NT_about%3F]], and this post to identify your IMU [[//www.rcgroups.com/forums/showpost.php?p=38258334&postcount=10256]]. <br />
<br />
The STorM32 v3.x, v4.x, v6.x controllers can only use NT IMUs, not I2C IMUs.<br />
<br />
Only firmwares with version v0.96 or less work with I2C IMUs. Firmwares with version numbers v2.xx are not usable for setups with I2C IMU. If you do not know what a NT IMU is, then you likely have a I2C IMU and need firmware v0.96.}} <br />
<br/><br />
{{ALERT| '''ANNOUNCEMENTS'''<br />
<!--- Support of the v1.3x STorM32 boards will phase out. That is, the next official release (whenever this will be), will be the last release which supports these old and tried main boards. Reason is that since few years I have migrated to the STM32 HAL&LL libraries, but the v1.3x code is still on the legacy SPL library since it's I2C is ca 50-100 us faster than the HAL I2C lib. So I maintain two codes, which is obviously not sustainable.<br />
- Support for quite a number of presumably "old" cameras will phase out. Some of them are so old that it's hard to imagine they are still in use. Examples are Git2, Mapir Survey, Firefly Split 4K, Runcam, GoPro Hero5&7.--><br />
<br />
- The v2.xx firmware series will phase out, i.e., currently it is planned that firmware 2.74 is the last release in this series. Development will shift to [//www.olliw.eu/storm32bgc-wiki STorM32 v3].}}<br />
<br />
== v2.xx Firmware for NT IMUs ==<br />
<br />
Firmware for STorM32 setups using a NT camera IMU. <br />
<br />
<br />
Direct link to v2.53 firmware download (this firmware is pretty old, it is highly recommended to use v2.67e):<br> <br />
<br />
:[//github.com/olliw42/storm32bgc/raw/main/firmware%20binaries%20%26%20gui/o323bgc-release-v253-v20200517.zip o323bgc-release-v253-v20200517] [.zip] (12.2 MB)<br />
:[//www.rcgroups.com/forums/showpost.php?p=44539519&postcount=12349 Release Notes]<br />
<br />
<br />
Latest beta release v2.73e:<br><br />
:[//github.com/olliw42/storm32bgc/raw/main/firmware%20binaries%20%26%20gui/o323bgc-release-v273e-v20250711.zip o323bgc-release-v273e-v20250711] [.zip] (15.9 MB)<br />
:[https://www.rcgroups.com/forums/showpost.php?p=53978973&postcount=15988 Release Notes]<br />
<br />
<br />
NTLoggerTool release v0.50:<br><br />
:[//www.olliw.eu/downloads/storm32/ntloggertool/ntloggertool-release-v050-v20231003.zip ntloggertool-release-v050-v20231003] [.zip] (295 MB)<br />
<br />
<br />
BetaCopter/BetaPlane 4.7-dev:<br><br />
:For downloading the firmwares and all further info please visit the article [[Using STorM32 with BetaPilot]].<br />
<br />
== v0.96 Firmware for I2C IMUs ==<br />
<br />
Firmware for STorM32 setups using a I2C camera IMU. Examples are the HakRC gimbal and other gimbals from Aliexpress.<br />
<br />
Latest firmware v0.96 for I2C IMUs:<br> <br />
:[//github.com/olliw42/storm32bgc/raw/master/firmware%20binaries%20%26%20gui/o323bgc-release-v096-v20160319.zip o323bgc-release-v096-v20160319] [.zip] (9.4MB)<br />
<br />
Note: This wiki here is not appropriate for v0.96 I2C setups, you should go to [//www.olliw.eu/storm32bgc-v1-wiki/Main_Page STorM32 v0.xx Wiki].<br />
<br />
{{COMMENT|The v0.96 release also includes firmwares for NT IMUs, identifiable by a label "nt" in the file names. Don't use them, use the v0.96 firmware (without a "nt" in the file name).}}<br />
<br />
== Repository ==<br />
<br />
Various files related to the STorM32-BGC project can be downloaded from several places:<br />
* [//github.com/olliw42/storm32bgc Github repository]<br />
* 1st page of the [//www.rcgroups.com/forums/showthread.php?t=2055844 rcgroups discussion thread]</div>OlliWhttp://www.olliw.eu/storm32bgc-v2-wiki/index.php?title=Downloads&diff=11885Downloads2025-11-17T16:44:48Z<p>OlliW: </p>
<hr />
<div>{{ALERT| '''PLEASE READ THIS FIRST''' <br />
There are 2 types of IMU modules which STorM32 v1.3x controllers can use, NT IMUs and I2C IMUs, and there are 2 firmwares which correspond to each type. It is important to choose the correct firmware, otherwise your controller and gimbal will not work. Read this page to understand the difference between the two types of IMUs [[//www.olliw.eu/storm32bgc-v2-wiki/What_is_STorM32_NT_about%3F]], and this post to identify your IMU [[//www.rcgroups.com/forums/showpost.php?p=38258334&postcount=10256]]. <br />
<br />
The STorM32 v3.x, v4.x, v6.x controllers can only use NT IMUs, not I2C IMUs.<br />
<br />
Only firmwares with version v0.96 or less work with I2C IMUs. Firmwares with version numbers v2.xx are not usable for setups with I2C IMU. If you do not know what a NT IMU is, then you likely have a I2C IMU and need firmware v0.96.}} <br />
<br/><br />
{{ALERT| '''ANNOUNCEMENTS'''<br />
<!--- Support of the v1.3x STorM32 boards will phase out. That is, the next official release (whenever this will be), will be the last release which supports these old and tried main boards. Reason is that since few years I have migrated to the STM32 HAL&LL libraries, but the v1.3x code is still on the legacy SPL library since it's I2C is ca 50-100 us faster than the HAL I2C lib. So I maintain two codes, which is obviously not sustainable.<br />
- Support for quite a number of presumably "old" cameras will phase out. Some of them are so old that it's hard to imagine they are still in use. Examples are Git2, Mapir Survey, Firefly Split 4K, Runcam, GoPro Hero5&7.--><br />
- The v2.xx firmware series will phase out, i.e., currently it is planned that firmware 2.74 is the last release in this series. Development will shift to [//www.olliw.eu/storm32bgc-wiki STorM32 v3].}}<br />
<br />
== v2.xx Firmware for NT IMUs ==<br />
<br />
Firmware for STorM32 setups using a NT camera IMU. <br />
<br />
<br />
Direct link to v2.53 firmware download (this firmware is pretty old, it is highly recommended to use v2.67e):<br> <br />
<br />
:[//github.com/olliw42/storm32bgc/raw/main/firmware%20binaries%20%26%20gui/o323bgc-release-v253-v20200517.zip o323bgc-release-v253-v20200517] [.zip] (12.2 MB)<br />
:[//www.rcgroups.com/forums/showpost.php?p=44539519&postcount=12349 Release Notes]<br />
<br />
<br />
Latest beta release v2.73e:<br><br />
:[//github.com/olliw42/storm32bgc/raw/main/firmware%20binaries%20%26%20gui/o323bgc-release-v273e-v20250711.zip o323bgc-release-v273e-v20250711] [.zip] (15.9 MB)<br />
:[https://www.rcgroups.com/forums/showpost.php?p=53978973&postcount=15988 Release Notes]<br />
<br />
<br />
NTLoggerTool release v0.50:<br><br />
:[//www.olliw.eu/downloads/storm32/ntloggertool/ntloggertool-release-v050-v20231003.zip ntloggertool-release-v050-v20231003] [.zip] (295 MB)<br />
<br />
<br />
BetaCopter/BetaPlane 4.7-dev:<br><br />
:For downloading the firmwares and all further info please visit the article [[Using STorM32 with BetaPilot]].<br />
<br />
== v0.96 Firmware for I2C IMUs ==<br />
<br />
Firmware for STorM32 setups using a I2C camera IMU. Examples are the HakRC gimbal and other gimbals from Aliexpress.<br />
<br />
Latest firmware v0.96 for I2C IMUs:<br> <br />
:[//github.com/olliw42/storm32bgc/raw/master/firmware%20binaries%20%26%20gui/o323bgc-release-v096-v20160319.zip o323bgc-release-v096-v20160319] [.zip] (9.4MB)<br />
<br />
Note: This wiki here is not appropriate for v0.96 I2C setups, you should go to [//www.olliw.eu/storm32bgc-v1-wiki/Main_Page STorM32 v0.xx Wiki].<br />
<br />
{{COMMENT|The v0.96 release also includes firmwares for NT IMUs, identifiable by a label "nt" in the file names. Don't use them, use the v0.96 firmware (without a "nt" in the file name).}}<br />
<br />
== Repository ==<br />
<br />
Various files related to the STorM32-BGC project can be downloaded from several places:<br />
* [//github.com/olliw42/storm32bgc Github repository]<br />
* 1st page of the [//www.rcgroups.com/forums/showthread.php?t=2055844 rcgroups discussion thread]</div>OlliWhttp://www.olliw.eu/storm32bgc-v2-wiki/index.php?title=Downloads&diff=11884Downloads2025-11-17T16:42:34Z<p>OlliW: </p>
<hr />
<div>{{ALERT| '''PLEASE READ THIS FIRST''' <br />
There are 2 types of IMU modules which STorM32 v1.3x controllers can use, NT IMUs and I2C IMUs, and there are 2 firmwares which correspond to each type. It is important to choose the correct firmware, otherwise your controller and gimbal will not work. Read this page to understand the difference between the two types of IMUs [[//www.olliw.eu/storm32bgc-v2-wiki/What_is_STorM32_NT_about%3F]], and this post to identify your IMU [[//www.rcgroups.com/forums/showpost.php?p=38258334&postcount=10256]]. <br />
<br />
The STorM32 v3.x, v4.x, v6.x controllers can only use NT IMUs, not I2C IMUs.<br />
<br />
Only firmwares with version v0.96 or less work with I2C IMUs. Firmwares with version numbers v2.xx are not usable for setups with I2C IMU. If you do not know what a NT IMU is, then you likely have a I2C IMU and need firmware v0.96.}} <br />
<br/><br />
{{ALERT| '''ANNOUNCEMENTS'''<br />
- Support of the v1.3x STorM32 boards will phase out. That is, the next official release (whenever this will be), will be the last release which supports these old and tried main boards. Reason is that since few years I have migrated to the STM32 HAL&LL libraries, but the v1.3x code is still on the legacy SPL library since it's I2C is ca 50-100 us faster than the HAL I2C lib. So I maintain two codes, which is obviously not sustainable.<br />
<!--- Support for quite a number of presumably "old" cameras will phase out. Some of them are so old that it's hard to imagine they are still in use. Examples are Git2, Mapir Survey, Firefly Split 4K, Runcam, GoPro Hero5&7.--><br />
- The v2.xx firmware series will phase out, i.e., currently it is planned that firmware 2.74 is the last release in this series. Development will shift to [//www.olliw.eu/storm32bgc-wiki STorM32 v3].}}<br />
<br />
== v2.xx Firmware for NT IMUs ==<br />
<br />
Firmware for STorM32 setups using a NT camera IMU. <br />
<br />
<br />
Direct link to v2.53 firmware download (this firmware is pretty old, it is highly recommended to use v2.67e):<br> <br />
<br />
:[//github.com/olliw42/storm32bgc/raw/main/firmware%20binaries%20%26%20gui/o323bgc-release-v253-v20200517.zip o323bgc-release-v253-v20200517] [.zip] (12.2 MB)<br />
:[//www.rcgroups.com/forums/showpost.php?p=44539519&postcount=12349 Release Notes]<br />
<br />
<br />
Latest beta release v2.73e:<br><br />
:[//github.com/olliw42/storm32bgc/raw/main/firmware%20binaries%20%26%20gui/o323bgc-release-v273e-v20250711.zip o323bgc-release-v273e-v20250711] [.zip] (15.9 MB)<br />
:[https://www.rcgroups.com/forums/showpost.php?p=53978973&postcount=15988 Release Notes]<br />
<br />
<br />
NTLoggerTool release v0.50:<br><br />
:[//www.olliw.eu/downloads/storm32/ntloggertool/ntloggertool-release-v050-v20231003.zip ntloggertool-release-v050-v20231003] [.zip] (295 MB)<br />
<br />
<br />
BetaCopter/BetaPlane 4.7-dev:<br><br />
:For downloading the firmwares and all further info please visit the article [[Using STorM32 with BetaPilot]].<br />
<br />
== v0.96 Firmware for I2C IMUs ==<br />
<br />
Firmware for STorM32 setups using a I2C camera IMU. Examples are the HakRC gimbal and other gimbals from Aliexpress.<br />
<br />
Latest firmware v0.96 for I2C IMUs:<br> <br />
:[//github.com/olliw42/storm32bgc/raw/master/firmware%20binaries%20%26%20gui/o323bgc-release-v096-v20160319.zip o323bgc-release-v096-v20160319] [.zip] (9.4MB)<br />
<br />
Note: This wiki here is not appropriate for v0.96 I2C setups, you should go to [//www.olliw.eu/storm32bgc-v1-wiki/Main_Page STorM32 v0.xx Wiki].<br />
<br />
{{COMMENT|The v0.96 release also includes firmwares for NT IMUs, identifiable by a label "nt" in the file names. Don't use them, use the v0.96 firmware (without a "nt" in the file name).}}<br />
<br />
== Repository ==<br />
<br />
Various files related to the STorM32-BGC project can be downloaded from several places:<br />
* [//github.com/olliw42/storm32bgc Github repository]<br />
* 1st page of the [//www.rcgroups.com/forums/showthread.php?t=2055844 rcgroups discussion thread]</div>OlliWhttp://www.olliw.eu/storm32bgc-v2-wiki/index.php?title=Downloads&diff=11883Downloads2025-11-17T16:42:04Z<p>OlliW: </p>
<hr />
<div>{{ALERT| '''PLEASE READ THIS FIRST''' <br />
There are 2 types of IMU modules which STorM32 v1.3x controllers can use, NT IMUs and I2C IMUs, and there are 2 firmwares which correspond to each type. It is important to choose the correct firmware, otherwise your controller and gimbal will not work. Read this page to understand the difference between the two types of IMUs [[//www.olliw.eu/storm32bgc-wiki/What_is_STorM32_NT_about%3F]], and this post to identify your IMU [[//www.rcgroups.com/forums/showpost.php?p=38258334&postcount=10256]]. <br />
<br />
The STorM32 v3.x, v4.x, v6.x controllers can only use NT IMUs, not I2C IMUs.<br />
<br />
Only firmwares with version v0.96 or less work with I2C IMUs. Firmwares with version numbers v2.xx are not usable for setups with I2C IMU. If you do not know what a NT IMU is, then you likely have a I2C IMU and need firmware v0.96.}} <br />
<br/><br />
{{ALERT| '''ANNOUNCEMENTS'''<br />
- Support of the v1.3x STorM32 boards will phase out. That is, the next official release (whenever this will be), will be the last release which supports these old and tried main boards. Reason is that since few years I have migrated to the STM32 HAL&LL libraries, but the v1.3x code is still on the legacy SPL library since it's I2C is ca 50-100 us faster than the HAL I2C lib. So I maintain two codes, which is obviously not sustainable.<br />
<!--- Support for quite a number of presumably "old" cameras will phase out. Some of them are so old that it's hard to imagine they are still in use. Examples are Git2, Mapir Survey, Firefly Split 4K, Runcam, GoPro Hero5&7.--><br />
- The v2.xx firmware series will phase out, i.e., currently it is planned that firmware 2.74 is the last release in this series. Development will shift to [//www.olliw.eu/storm32bgc-wiki STorM32 v3].}}<br />
<br />
== v2.xx Firmware for NT IMUs ==<br />
<br />
Firmware for STorM32 setups using a NT camera IMU. <br />
<br />
<br />
Direct link to v2.53 firmware download (this firmware is pretty old, it is highly recommended to use v2.67e):<br> <br />
<br />
:[//github.com/olliw42/storm32bgc/raw/main/firmware%20binaries%20%26%20gui/o323bgc-release-v253-v20200517.zip o323bgc-release-v253-v20200517] [.zip] (12.2 MB)<br />
:[//www.rcgroups.com/forums/showpost.php?p=44539519&postcount=12349 Release Notes]<br />
<br />
<br />
Latest beta release v2.73e:<br><br />
:[//github.com/olliw42/storm32bgc/raw/main/firmware%20binaries%20%26%20gui/o323bgc-release-v273e-v20250711.zip o323bgc-release-v273e-v20250711] [.zip] (15.9 MB)<br />
:[https://www.rcgroups.com/forums/showpost.php?p=53978973&postcount=15988 Release Notes]<br />
<br />
<br />
NTLoggerTool release v0.50:<br><br />
:[//www.olliw.eu/downloads/storm32/ntloggertool/ntloggertool-release-v050-v20231003.zip ntloggertool-release-v050-v20231003] [.zip] (295 MB)<br />
<br />
<br />
BetaCopter/BetaPlane 4.7-dev:<br><br />
:For downloading the firmwares and all further info please visit the article [[Using STorM32 with BetaPilot]].<br />
<br />
== v0.96 Firmware for I2C IMUs ==<br />
<br />
Firmware for STorM32 setups using a I2C camera IMU. Examples are the HakRC gimbal and other gimbals from Aliexpress.<br />
<br />
Latest firmware v0.96 for I2C IMUs:<br> <br />
:[//github.com/olliw42/storm32bgc/raw/master/firmware%20binaries%20%26%20gui/o323bgc-release-v096-v20160319.zip o323bgc-release-v096-v20160319] [.zip] (9.4MB)<br />
<br />
Note: This wiki here is not appropriate for v0.96 I2C setups, you should go to [//www.olliw.eu/storm32bgc-v1-wiki/Main_Page STorM32 v0.xx Wiki].<br />
<br />
{{COMMENT|The v0.96 release also includes firmwares for NT IMUs, identifiable by a label "nt" in the file names. Don't use them, use the v0.96 firmware (without a "nt" in the file name).}}<br />
<br />
== Repository ==<br />
<br />
Various files related to the STorM32-BGC project can be downloaded from several places:<br />
* [//github.com/olliw42/storm32bgc Github repository]<br />
* 1st page of the [//www.rcgroups.com/forums/showthread.php?t=2055844 rcgroups discussion thread]</div>OlliWhttp://www.olliw.eu/storm32bgc-v2-wiki/index.php?title=Downloads&diff=11882Downloads2025-11-17T16:41:12Z<p>OlliW: </p>
<hr />
<div>{{ALERT| '''PLEASE READ THIS FIRST''' <br />
There are 2 types of IMU modules which STorM32 v1.3x controllers can use, NT IMUs and I2C IMUs, and there are 2 firmwares which correspond to each type. It is important to choose the correct firmware, otherwise your controller and gimbal will not work. Read this page to understand the difference between the two types of IMUs [[//www.olliw.eu/storm32bgc-wiki/What_is_STorM32_NT_about%3F]], and this post to identify your IMU [[//www.rcgroups.com/forums/showpost.php?p=38258334&postcount=10256]]. <br />
<br />
The STorM32 v3.x, v4.x, v6.x controllers can only use NT IMUs, not I2C IMUs.<br />
<br />
Only firmwares with version v0.96 or less work with I2C IMUs. Firmwares with version numbers v2.xx are not usable for setups with I2C IMU. If you do not know what a NT IMU is, then you likely have a I2C IMU and need firmware v0.96.}} <br />
<br/><br />
{{ALERT| '''ANNOUNCEMENTS'''<br />
- Support of the v1.3x STorM32 boards will phase out. That is, the next official release (whenever this will be), will be the last release which supports these old and tried main boards. Reason is that since few years I have migrated to the STM32 HAL&LL libraries, but the v1.3x code is still on the legacy SPL library since it's I2C is ca 50-100 us faster than the HAL I2C lib. So I maintain two codes, which is obviously not sustainable.<br />
<!--- Support for quite a number of presumably "old" cameras will phase out. Some of them are so old that it's hard to imagine they are still in use. Examples are Git2, Mapir Survey, Firefly Split 4K, Runcam, GoPro Hero5&7.--><br />
- The v2.xx firmware series will phase out, i.e., currently it is planned that firmware 2.74 is the last release in this series. Development will shift to STorM32 v3.}}<br />
<br />
== v2.xx Firmware for NT IMUs ==<br />
<br />
Firmware for STorM32 setups using a NT camera IMU. <br />
<br />
<br />
Direct link to v2.53 firmware download (this firmware is pretty old, it is highly recommended to use v2.67e):<br> <br />
<br />
:[//github.com/olliw42/storm32bgc/raw/main/firmware%20binaries%20%26%20gui/o323bgc-release-v253-v20200517.zip o323bgc-release-v253-v20200517] [.zip] (12.2 MB)<br />
:[//www.rcgroups.com/forums/showpost.php?p=44539519&postcount=12349 Release Notes]<br />
<br />
<br />
Latest beta release v2.73e:<br><br />
:[//github.com/olliw42/storm32bgc/raw/main/firmware%20binaries%20%26%20gui/o323bgc-release-v273e-v20250711.zip o323bgc-release-v273e-v20250711] [.zip] (15.9 MB)<br />
:[https://www.rcgroups.com/forums/showpost.php?p=53978973&postcount=15988 Release Notes]<br />
<br />
<br />
NTLoggerTool release v0.50:<br><br />
:[//www.olliw.eu/downloads/storm32/ntloggertool/ntloggertool-release-v050-v20231003.zip ntloggertool-release-v050-v20231003] [.zip] (295 MB)<br />
<br />
<br />
BetaCopter/BetaPlane 4.7-dev:<br><br />
:For downloading the firmwares and all further info please visit the article [[Using STorM32 with BetaPilot]].<br />
<br />
== v0.96 Firmware for I2C IMUs ==<br />
<br />
Firmware for STorM32 setups using a I2C camera IMU. Examples are the HakRC gimbal and other gimbals from Aliexpress.<br />
<br />
Latest firmware v0.96 for I2C IMUs:<br> <br />
:[//github.com/olliw42/storm32bgc/raw/master/firmware%20binaries%20%26%20gui/o323bgc-release-v096-v20160319.zip o323bgc-release-v096-v20160319] [.zip] (9.4MB)<br />
<br />
Note: This wiki here is not appropriate for v0.96 I2C setups, you should go to [//www.olliw.eu/storm32bgc-v1-wiki/Main_Page STorM32 v0.xx Wiki].<br />
<br />
{{COMMENT|The v0.96 release also includes firmwares for NT IMUs, identifiable by a label "nt" in the file names. Don't use them, use the v0.96 firmware (without a "nt" in the file name).}}<br />
<br />
== Repository ==<br />
<br />
Various files related to the STorM32-BGC project can be downloaded from several places:<br />
* [//github.com/olliw42/storm32bgc Github repository]<br />
* 1st page of the [//www.rcgroups.com/forums/showthread.php?t=2055844 rcgroups discussion thread]</div>OlliWhttp://www.olliw.eu/storm32bgc-v2-wiki/index.php?title=Downloads&diff=11881Downloads2025-11-17T16:39:32Z<p>OlliW: </p>
<hr />
<div>{{ALERT| '''PLEASE READ THIS FIRST''' <br />
There are 2 types of IMU modules which STorM32 v1.3x controllers can use, NT IMUs and I2C IMUs, and there are 2 firmwares which correspond to each type. It is important to choose the correct firmware, otherwise your controller and gimbal will not work. Read this page to understand the difference between the two types of IMUs [[//www.olliw.eu/storm32bgc-wiki/What_is_STorM32_NT_about%3F]], and this post to identify your IMU [[//www.rcgroups.com/forums/showpost.php?p=38258334&postcount=10256]]. <br />
<br />
The STorM32 v3.x, v4.x, v6.x controllers can only use NT IMUs, not I2C IMUs.<br />
<br />
Only firmwares with version v0.96 or less work with I2C IMUs. Firmwares with version numbers v2.xx are not usable for setups with I2C IMU. If you do not know what a NT IMU is, then you likely have a I2C IMU and need firmware v0.96.}} <br />
<br/><br />
{{ALERT| '''ANNOUNCEMENTS'''<br />
- Support of the v1.3x STorM32 boards will phase out. That is, the next official release (whenever this will be), will be the last release which supports these old and tried main boards. Reason is that since few years I have migrated to the STM32 HAL&LL libraries, but the v1.3x code is still on the legacy SPL library since it's I2C is ca 50-100 us faster than the HAL I2C lib. So I maintain two codes, which is obviously not sustainable.<br />
<!--- Support for quite a number of presumably "old" cameras will phase out. Some of them are so old that it's hard to imagine they are still in use. Examples are Git2, Mapir Survey, Firefly Split 4K, Runcam, GoPro Hero5&7.-->}}<br />
<br />
== v2.xx Firmware for NT IMUs ==<br />
<br />
Firmware for STorM32 setups using a NT camera IMU. <br />
<br />
<br />
Direct link to v2.53 firmware download (this firmware is pretty old, it is highly recommended to use v2.67e):<br> <br />
<br />
:[//github.com/olliw42/storm32bgc/raw/main/firmware%20binaries%20%26%20gui/o323bgc-release-v253-v20200517.zip o323bgc-release-v253-v20200517] [.zip] (12.2 MB)<br />
:[//www.rcgroups.com/forums/showpost.php?p=44539519&postcount=12349 Release Notes]<br />
<br />
<br />
Latest beta release v2.73e:<br><br />
:[//github.com/olliw42/storm32bgc/raw/main/firmware%20binaries%20%26%20gui/o323bgc-release-v273e-v20250711.zip o323bgc-release-v273e-v20250711] [.zip] (15.9 MB)<br />
:[https://www.rcgroups.com/forums/showpost.php?p=53978973&postcount=15988 Release Notes]<br />
<br />
<br />
NTLoggerTool release v0.50:<br><br />
:[//www.olliw.eu/downloads/storm32/ntloggertool/ntloggertool-release-v050-v20231003.zip ntloggertool-release-v050-v20231003] [.zip] (295 MB)<br />
<br />
<br />
BetaCopter/BetaPlane 4.7-dev:<br><br />
:For downloading the firmwares and all further info please visit the article [[Using STorM32 with BetaPilot]].<br />
<br />
== v0.96 Firmware for I2C IMUs ==<br />
<br />
Firmware for STorM32 setups using a I2C camera IMU. Examples are the HakRC gimbal and other gimbals from Aliexpress.<br />
<br />
Latest firmware v0.96 for I2C IMUs:<br> <br />
:[//github.com/olliw42/storm32bgc/raw/master/firmware%20binaries%20%26%20gui/o323bgc-release-v096-v20160319.zip o323bgc-release-v096-v20160319] [.zip] (9.4MB)<br />
<br />
Note: This wiki here is not appropriate for v0.96 I2C setups, you should go to [//www.olliw.eu/storm32bgc-v1-wiki/Main_Page STorM32 v0.xx Wiki].<br />
<br />
{{COMMENT|The v0.96 release also includes firmwares for NT IMUs, identifiable by a label "nt" in the file names. Don't use them, use the v0.96 firmware (without a "nt" in the file name).}}<br />
<br />
== Repository ==<br />
<br />
Various files related to the STorM32-BGC project can be downloaded from several places:<br />
* [//github.com/olliw42/storm32bgc Github repository]<br />
* 1st page of the [//www.rcgroups.com/forums/showthread.php?t=2055844 rcgroups discussion thread]</div>OlliWhttp://www.olliw.eu/storm32bgc-v2-wiki/index.php?title=Downloads&diff=11880Downloads2025-11-17T16:39:11Z<p>OlliW: </p>
<hr />
<div>{{ALERT| '''PLEASE READ THIS FIRST''' <br />
There are 2 types of IMU modules which STorM32 v1.3x controllers can use, NT IMUs and I2C IMUs, and there are 2 firmwares which correspond to each type. It is important to choose the correct firmware, otherwise your controller and gimbal will not work. Read this page to understand the difference between the two types of IMUs [[//www.olliw.eu/storm32bgc-wiki/What_is_STorM32_NT_about%3F]], and this post to identify your IMU [[//www.rcgroups.com/forums/showpost.php?p=38258334&postcount=10256]]. <br />
<br />
The STorM32 v3.x, v4.x, v6.x controllers can only use NT IMUs, not I2C IMUs.<br />
<br />
Only firmwares with version v0.96 or less work with I2C IMUs. Firmwares with version numbers v2.xx are not usable for setups with I2C IMU. If you do not know what a NT IMU is, then you likely have a I2C IMU and need firmware v0.96.}} <br />
<br/><br />
{{ALERT| '''ANNOUNCEMENTS'''<br />
- Support of the v1.3x STorM32 boards will phase out. That is, the next official release (whenever this will be), will be the last release which supports these old and tried main boards. Reason is that since few years I have migrated to the STM32 HAL&LL libraries, but the v1.3x code is still on the legacy SPL library since it's I2C is ca 50-100 us faster than the HAL I2C lib. So I maintain two codes, which is obviously not sustainable.<br />
- Support for quite a number of presumably "old" cameras will phase out. Some of them are so old that it's hard to imagine they are still in use. Examples are Git2, Mapir Survey, Firefly Split 4K, Runcam, GoPro Hero5&7.}}<br />
<br />
== v2.xx Firmware for NT IMUs ==<br />
<br />
Firmware for STorM32 setups using a NT camera IMU. <br />
<br />
<br />
Direct link to v2.53 firmware download (this firmware is pretty old, it is highly recommended to use v2.67e):<br> <br />
<br />
:[//github.com/olliw42/storm32bgc/raw/main/firmware%20binaries%20%26%20gui/o323bgc-release-v253-v20200517.zip o323bgc-release-v253-v20200517] [.zip] (12.2 MB)<br />
:[//www.rcgroups.com/forums/showpost.php?p=44539519&postcount=12349 Release Notes]<br />
<br />
<br />
Latest beta release v2.73e:<br><br />
:[//github.com/olliw42/storm32bgc/raw/main/firmware%20binaries%20%26%20gui/o323bgc-release-v273e-v20250711.zip o323bgc-release-v273e-v20250711] [.zip] (15.9 MB)<br />
:[https://www.rcgroups.com/forums/showpost.php?p=53978973&postcount=15988 Release Notes]<br />
<br />
<br />
NTLoggerTool release v0.50:<br><br />
:[//www.olliw.eu/downloads/storm32/ntloggertool/ntloggertool-release-v050-v20231003.zip ntloggertool-release-v050-v20231003] [.zip] (295 MB)<br />
<br />
<br />
BetaCopter/BetaPlane 4.7-dev:<br><br />
:For downloading the firmwares and all further info please visit the article [[Using STorM32 with BetaPilot]].<br />
<br />
== v0.96 Firmware for I2C IMUs ==<br />
<br />
Firmware for STorM32 setups using a I2C camera IMU. Examples are the HakRC gimbal and other gimbals from Aliexpress.<br />
<br />
Latest firmware v0.96 for I2C IMUs:<br> <br />
:[//github.com/olliw42/storm32bgc/raw/master/firmware%20binaries%20%26%20gui/o323bgc-release-v096-v20160319.zip o323bgc-release-v096-v20160319] [.zip] (9.4MB)<br />
<br />
Note: This wiki here is not appropriate for v0.96 I2C setups, you should go to [//www.olliw.eu/storm32bgc-v1-wiki/Main_Page STorM32 v0.xx Wiki].<br />
<br />
{{COMMENT|The v0.96 release also includes firmwares for NT IMUs, identifiable by a label "nt" in the file names. Don't use them, use the v0.96 firmware (without a "nt" in the file name).}}<br />
<br />
== Repository ==<br />
<br />
Various files related to the STorM32-BGC project can be downloaded from several places:<br />
* [//github.com/olliw42/storm32bgc Github repository]<br />
* 1st page of the [//www.rcgroups.com/forums/showthread.php?t=2055844 rcgroups discussion thread]</div>OlliWhttp://www.olliw.eu/storm32bgc-v2-wiki/index.php?title=Downloads&diff=11879Downloads2025-11-17T16:39:01Z<p>OlliW: </p>
<hr />
<div>{{ALERT| '''PLEASE READ THIS FIRST''' <br />
There are 2 types of IMU modules which STorM32 v1.3x controllers can use, NT IMUs and I2C IMUs, and there are 2 firmwares which correspond to each type. It is important to choose the correct firmware, otherwise your controller and gimbal will not work. Read this page to understand the difference between the two types of IMUs [[//www.olliw.eu/storm32bgc-wiki/What_is_STorM32_NT_about%3F]], and this post to identify your IMU [[//www.rcgroups.com/forums/showpost.php?p=38258334&postcount=10256]]. <br />
<br />
The STorM32 v3.x, v4.x, v6.x controllers can only use NT IMUs, not I2C IMUs.<br />
<br />
Only firmwares with version v0.96 or less work with I2C IMUs. Firmwares with version numbers v2.xx are not usable for setups with I2C IMU. If you do not know what a NT IMU is, then you likely have a I2C IMU and need firmware v0.96.}} <br/><br />
{{ALERT| '''ANNOUNCEMENTS'''<br />
- Support of the v1.3x STorM32 boards will phase out. That is, the next official release (whenever this will be), will be the last release which supports these old and tried main boards. Reason is that since few years I have migrated to the STM32 HAL&LL libraries, but the v1.3x code is still on the legacy SPL library since it's I2C is ca 50-100 us faster than the HAL I2C lib. So I maintain two codes, which is obviously not sustainable.<br />
- Support for quite a number of presumably "old" cameras will phase out. Some of them are so old that it's hard to imagine they are still in use. Examples are Git2, Mapir Survey, Firefly Split 4K, Runcam, GoPro Hero5&7.}}<br />
<br />
== v2.xx Firmware for NT IMUs ==<br />
<br />
Firmware for STorM32 setups using a NT camera IMU. <br />
<br />
<br />
Direct link to v2.53 firmware download (this firmware is pretty old, it is highly recommended to use v2.67e):<br> <br />
<br />
:[//github.com/olliw42/storm32bgc/raw/main/firmware%20binaries%20%26%20gui/o323bgc-release-v253-v20200517.zip o323bgc-release-v253-v20200517] [.zip] (12.2 MB)<br />
:[//www.rcgroups.com/forums/showpost.php?p=44539519&postcount=12349 Release Notes]<br />
<br />
<br />
Latest beta release v2.73e:<br><br />
:[//github.com/olliw42/storm32bgc/raw/main/firmware%20binaries%20%26%20gui/o323bgc-release-v273e-v20250711.zip o323bgc-release-v273e-v20250711] [.zip] (15.9 MB)<br />
:[https://www.rcgroups.com/forums/showpost.php?p=53978973&postcount=15988 Release Notes]<br />
<br />
<br />
NTLoggerTool release v0.50:<br><br />
:[//www.olliw.eu/downloads/storm32/ntloggertool/ntloggertool-release-v050-v20231003.zip ntloggertool-release-v050-v20231003] [.zip] (295 MB)<br />
<br />
<br />
BetaCopter/BetaPlane 4.7-dev:<br><br />
:For downloading the firmwares and all further info please visit the article [[Using STorM32 with BetaPilot]].<br />
<br />
== v0.96 Firmware for I2C IMUs ==<br />
<br />
Firmware for STorM32 setups using a I2C camera IMU. Examples are the HakRC gimbal and other gimbals from Aliexpress.<br />
<br />
Latest firmware v0.96 for I2C IMUs:<br> <br />
:[//github.com/olliw42/storm32bgc/raw/master/firmware%20binaries%20%26%20gui/o323bgc-release-v096-v20160319.zip o323bgc-release-v096-v20160319] [.zip] (9.4MB)<br />
<br />
Note: This wiki here is not appropriate for v0.96 I2C setups, you should go to [//www.olliw.eu/storm32bgc-v1-wiki/Main_Page STorM32 v0.xx Wiki].<br />
<br />
{{COMMENT|The v0.96 release also includes firmwares for NT IMUs, identifiable by a label "nt" in the file names. Don't use them, use the v0.96 firmware (without a "nt" in the file name).}}<br />
<br />
== Repository ==<br />
<br />
Various files related to the STorM32-BGC project can be downloaded from several places:<br />
* [//github.com/olliw42/storm32bgc Github repository]<br />
* 1st page of the [//www.rcgroups.com/forums/showthread.php?t=2055844 rcgroups discussion thread]</div>OlliWhttp://www.olliw.eu/storm32bgc-v2-wiki/index.php?title=Downloads&diff=11878Downloads2025-11-17T16:38:52Z<p>OlliW: </p>
<hr />
<div>{{ALERT| '''PLEASE READ THIS FIRST''' <br />
There are 2 types of IMU modules which STorM32 v1.3x controllers can use, NT IMUs and I2C IMUs, and there are 2 firmwares which correspond to each type. It is important to choose the correct firmware, otherwise your controller and gimbal will not work. Read this page to understand the difference between the two types of IMUs [[//www.olliw.eu/storm32bgc-wiki/What_is_STorM32_NT_about%3F]], and this post to identify your IMU [[//www.rcgroups.com/forums/showpost.php?p=38258334&postcount=10256]]. <br />
<br />
The STorM32 v3.x, v4.x, v6.x controllers can only use NT IMUs, not I2C IMUs.<br />
<br />
Only firmwares with version v0.96 or less work with I2C IMUs. Firmwares with version numbers v2.xx are not usable for setups with I2C IMU. If you do not know what a NT IMU is, then you likely have a I2C IMU and need firmware v0.96.}} <br/><br />
<br />
{{ALERT| '''ANNOUNCEMENTS'''<br />
- Support of the v1.3x STorM32 boards will phase out. That is, the next official release (whenever this will be), will be the last release which supports these old and tried main boards. Reason is that since few years I have migrated to the STM32 HAL&LL libraries, but the v1.3x code is still on the legacy SPL library since it's I2C is ca 50-100 us faster than the HAL I2C lib. So I maintain two codes, which is obviously not sustainable.<br />
- Support for quite a number of presumably "old" cameras will phase out. Some of them are so old that it's hard to imagine they are still in use. Examples are Git2, Mapir Survey, Firefly Split 4K, Runcam, GoPro Hero5&7.}}<br />
<br />
== v2.xx Firmware for NT IMUs ==<br />
<br />
Firmware for STorM32 setups using a NT camera IMU. <br />
<br />
<br />
Direct link to v2.53 firmware download (this firmware is pretty old, it is highly recommended to use v2.67e):<br> <br />
<br />
:[//github.com/olliw42/storm32bgc/raw/main/firmware%20binaries%20%26%20gui/o323bgc-release-v253-v20200517.zip o323bgc-release-v253-v20200517] [.zip] (12.2 MB)<br />
:[//www.rcgroups.com/forums/showpost.php?p=44539519&postcount=12349 Release Notes]<br />
<br />
<br />
Latest beta release v2.73e:<br><br />
:[//github.com/olliw42/storm32bgc/raw/main/firmware%20binaries%20%26%20gui/o323bgc-release-v273e-v20250711.zip o323bgc-release-v273e-v20250711] [.zip] (15.9 MB)<br />
:[https://www.rcgroups.com/forums/showpost.php?p=53978973&postcount=15988 Release Notes]<br />
<br />
<br />
NTLoggerTool release v0.50:<br><br />
:[//www.olliw.eu/downloads/storm32/ntloggertool/ntloggertool-release-v050-v20231003.zip ntloggertool-release-v050-v20231003] [.zip] (295 MB)<br />
<br />
<br />
BetaCopter/BetaPlane 4.7-dev:<br><br />
:For downloading the firmwares and all further info please visit the article [[Using STorM32 with BetaPilot]].<br />
<br />
== v0.96 Firmware for I2C IMUs ==<br />
<br />
Firmware for STorM32 setups using a I2C camera IMU. Examples are the HakRC gimbal and other gimbals from Aliexpress.<br />
<br />
Latest firmware v0.96 for I2C IMUs:<br> <br />
:[//github.com/olliw42/storm32bgc/raw/master/firmware%20binaries%20%26%20gui/o323bgc-release-v096-v20160319.zip o323bgc-release-v096-v20160319] [.zip] (9.4MB)<br />
<br />
Note: This wiki here is not appropriate for v0.96 I2C setups, you should go to [//www.olliw.eu/storm32bgc-v1-wiki/Main_Page STorM32 v0.xx Wiki].<br />
<br />
{{COMMENT|The v0.96 release also includes firmwares for NT IMUs, identifiable by a label "nt" in the file names. Don't use them, use the v0.96 firmware (without a "nt" in the file name).}}<br />
<br />
== Repository ==<br />
<br />
Various files related to the STorM32-BGC project can be downloaded from several places:<br />
* [//github.com/olliw42/storm32bgc Github repository]<br />
* 1st page of the [//www.rcgroups.com/forums/showthread.php?t=2055844 rcgroups discussion thread]</div>OlliWhttp://www.olliw.eu/storm32bgc-v2-wiki/index.php?title=Downloads&diff=11877Downloads2025-11-17T16:38:40Z<p>OlliW: </p>
<hr />
<div>{{ALERT| '''PLEASE READ THIS FIRST''' <br />
There are 2 types of IMU modules which STorM32 v1.3x controllers can use, NT IMUs and I2C IMUs, and there are 2 firmwares which correspond to each type. It is important to choose the correct firmware, otherwise your controller and gimbal will not work. Read this page to understand the difference between the two types of IMUs [[//www.olliw.eu/storm32bgc-wiki/What_is_STorM32_NT_about%3F]], and this post to identify your IMU [[//www.rcgroups.com/forums/showpost.php?p=38258334&postcount=10256]]. <br />
<br />
The STorM32 v3.x, v4.x, v6.x controllers can only use NT IMUs, not I2C IMUs.<br />
<br />
Only firmwares with version v0.96 or less work with I2C IMUs. Firmwares with version numbers v2.xx are not usable for setups with I2C IMU. If you do not know what a NT IMU is, then you likely have a I2C IMU and need firmware v0.96.}}<br />
<br />
{{ALERT| '''ANNOUNCEMENTS'''<br />
- Support of the v1.3x STorM32 boards will phase out. That is, the next official release (whenever this will be), will be the last release which supports these old and tried main boards. Reason is that since few years I have migrated to the STM32 HAL&LL libraries, but the v1.3x code is still on the legacy SPL library since it's I2C is ca 50-100 us faster than the HAL I2C lib. So I maintain two codes, which is obviously not sustainable.<br />
- Support for quite a number of presumably "old" cameras will phase out. Some of them are so old that it's hard to imagine they are still in use. Examples are Git2, Mapir Survey, Firefly Split 4K, Runcam, GoPro Hero5&7.}}<br />
<br />
== v2.xx Firmware for NT IMUs ==<br />
<br />
Firmware for STorM32 setups using a NT camera IMU. <br />
<br />
<br />
Direct link to v2.53 firmware download (this firmware is pretty old, it is highly recommended to use v2.67e):<br> <br />
<br />
:[//github.com/olliw42/storm32bgc/raw/main/firmware%20binaries%20%26%20gui/o323bgc-release-v253-v20200517.zip o323bgc-release-v253-v20200517] [.zip] (12.2 MB)<br />
:[//www.rcgroups.com/forums/showpost.php?p=44539519&postcount=12349 Release Notes]<br />
<br />
<br />
Latest beta release v2.73e:<br><br />
:[//github.com/olliw42/storm32bgc/raw/main/firmware%20binaries%20%26%20gui/o323bgc-release-v273e-v20250711.zip o323bgc-release-v273e-v20250711] [.zip] (15.9 MB)<br />
:[https://www.rcgroups.com/forums/showpost.php?p=53978973&postcount=15988 Release Notes]<br />
<br />
<br />
NTLoggerTool release v0.50:<br><br />
:[//www.olliw.eu/downloads/storm32/ntloggertool/ntloggertool-release-v050-v20231003.zip ntloggertool-release-v050-v20231003] [.zip] (295 MB)<br />
<br />
<br />
BetaCopter/BetaPlane 4.7-dev:<br><br />
:For downloading the firmwares and all further info please visit the article [[Using STorM32 with BetaPilot]].<br />
<br />
== v0.96 Firmware for I2C IMUs ==<br />
<br />
Firmware for STorM32 setups using a I2C camera IMU. Examples are the HakRC gimbal and other gimbals from Aliexpress.<br />
<br />
Latest firmware v0.96 for I2C IMUs:<br> <br />
:[//github.com/olliw42/storm32bgc/raw/master/firmware%20binaries%20%26%20gui/o323bgc-release-v096-v20160319.zip o323bgc-release-v096-v20160319] [.zip] (9.4MB)<br />
<br />
Note: This wiki here is not appropriate for v0.96 I2C setups, you should go to [//www.olliw.eu/storm32bgc-v1-wiki/Main_Page STorM32 v0.xx Wiki].<br />
<br />
{{COMMENT|The v0.96 release also includes firmwares for NT IMUs, identifiable by a label "nt" in the file names. Don't use them, use the v0.96 firmware (without a "nt" in the file name).}}<br />
<br />
== Repository ==<br />
<br />
Various files related to the STorM32-BGC project can be downloaded from several places:<br />
* [//github.com/olliw42/storm32bgc Github repository]<br />
* 1st page of the [//www.rcgroups.com/forums/showthread.php?t=2055844 rcgroups discussion thread]</div>OlliWhttp://www.olliw.eu/storm32bgc-v2-wiki/index.php?title=Downloads&diff=11876Downloads2025-11-17T16:37:54Z<p>OlliW: /* Repository */</p>
<hr />
<div>{{ALERT| '''PLEASE READ THIS FIRST''' <br />
There are 2 types of IMU modules which STorM32 v1.3x controllers can use, NT IMUs and I2C IMUs, and there are 2 firmwares which correspond to each type. It is important to choose the correct firmware, otherwise your controller and gimbal will not work. Read this page to understand the difference between the two types of IMUs [[//www.olliw.eu/storm32bgc-wiki/What_is_STorM32_NT_about%3F]], and this post to identify your IMU [[//www.rcgroups.com/forums/showpost.php?p=38258334&postcount=10256]]. <br />
<br />
The STorM32 v3.x, v4.x, v6.x controllers can only use NT IMUs, not I2C IMUs.<br />
<br />
Only firmwares with version v0.96 or less work with I2C IMUs. Firmwares with version numbers v2.xx are not usable for setups with I2C IMU. If you do not know what a NT IMU is, then you likely have a I2C IMU and need firmware v0.96.}}<br />
<br />
<br />
{{ALERT| '''ANNOUNCEMENTS'''<br />
- Support of the v1.3x STorM32 boards will phase out. That is, the next official release (whenever this will be), will be the last release which supports these old and tried main boards. Reason is that since few years I have migrated to the STM32 HAL&LL libraries, but the v1.3x code is still on the legacy SPL library since it's I2C is ca 50-100 us faster than the HAL I2C lib. So I maintain two codes, which is obviously not sustainable.<br />
- Support for quite a number of presumably "old" cameras will phase out. Some of them are so old that it's hard to imagine they are still in use. Examples are Git2, Mapir Survey, Firefly Split 4K, Runcam, GoPro Hero5&7.}}<br />
<br />
== v2.xx Firmware for NT IMUs ==<br />
<br />
Firmware for STorM32 setups using a NT camera IMU. <br />
<br />
<br />
Direct link to v2.53 firmware download (this firmware is pretty old, it is highly recommended to use v2.67e):<br> <br />
<br />
:[//github.com/olliw42/storm32bgc/raw/main/firmware%20binaries%20%26%20gui/o323bgc-release-v253-v20200517.zip o323bgc-release-v253-v20200517] [.zip] (12.2 MB)<br />
:[//www.rcgroups.com/forums/showpost.php?p=44539519&postcount=12349 Release Notes]<br />
<br />
<br />
Latest beta release v2.73e:<br><br />
:[//github.com/olliw42/storm32bgc/raw/main/firmware%20binaries%20%26%20gui/o323bgc-release-v273e-v20250711.zip o323bgc-release-v273e-v20250711] [.zip] (15.9 MB)<br />
:[https://www.rcgroups.com/forums/showpost.php?p=53978973&postcount=15988 Release Notes]<br />
<br />
<br />
NTLoggerTool release v0.50:<br><br />
:[//www.olliw.eu/downloads/storm32/ntloggertool/ntloggertool-release-v050-v20231003.zip ntloggertool-release-v050-v20231003] [.zip] (295 MB)<br />
<br />
<br />
BetaCopter/BetaPlane 4.7-dev:<br><br />
:For downloading the firmwares and all further info please visit the article [[Using STorM32 with BetaPilot]].<br />
<br />
== v0.96 Firmware for I2C IMUs ==<br />
<br />
Firmware for STorM32 setups using a I2C camera IMU. Examples are the HakRC gimbal and other gimbals from Aliexpress.<br />
<br />
Latest firmware v0.96 for I2C IMUs:<br> <br />
:[//github.com/olliw42/storm32bgc/raw/master/firmware%20binaries%20%26%20gui/o323bgc-release-v096-v20160319.zip o323bgc-release-v096-v20160319] [.zip] (9.4MB)<br />
<br />
Note: This wiki here is not appropriate for v0.96 I2C setups, you should go to [//www.olliw.eu/storm32bgc-v1-wiki/Main_Page STorM32 v0.xx Wiki].<br />
<br />
{{COMMENT|The v0.96 release also includes firmwares for NT IMUs, identifiable by a label "nt" in the file names. Don't use them, use the v0.96 firmware (without a "nt" in the file name).}}<br />
<br />
== Repository ==<br />
<br />
Various files related to the STorM32-BGC project can be downloaded from several places:<br />
* [//github.com/olliw42/storm32bgc Github repository]<br />
* 1st page of the [//www.rcgroups.com/forums/showthread.php?t=2055844 rcgroups discussion thread]</div>OlliWhttp://www.olliw.eu/storm32bgc-v2-wiki/index.php?title=Downloads&diff=11875Downloads2025-11-17T16:37:03Z<p>OlliW: </p>
<hr />
<div>{{ALERT| '''PLEASE READ THIS FIRST''' <br />
There are 2 types of IMU modules which STorM32 v1.3x controllers can use, NT IMUs and I2C IMUs, and there are 2 firmwares which correspond to each type. It is important to choose the correct firmware, otherwise your controller and gimbal will not work. Read this page to understand the difference between the two types of IMUs [[//www.olliw.eu/storm32bgc-wiki/What_is_STorM32_NT_about%3F]], and this post to identify your IMU [[//www.rcgroups.com/forums/showpost.php?p=38258334&postcount=10256]]. <br />
<br />
The STorM32 v3.x, v4.x, v6.x controllers can only use NT IMUs, not I2C IMUs.<br />
<br />
Only firmwares with version v0.96 or less work with I2C IMUs. Firmwares with version numbers v2.xx are not usable for setups with I2C IMU. If you do not know what a NT IMU is, then you likely have a I2C IMU and need firmware v0.96.}}<br />
<br />
<br />
{{ALERT| '''ANNOUNCEMENTS'''<br />
- Support of the v1.3x STorM32 boards will phase out. That is, the next official release (whenever this will be), will be the last release which supports these old and tried main boards. Reason is that since few years I have migrated to the STM32 HAL&LL libraries, but the v1.3x code is still on the legacy SPL library since it's I2C is ca 50-100 us faster than the HAL I2C lib. So I maintain two codes, which is obviously not sustainable.<br />
- Support for quite a number of presumably "old" cameras will phase out. Some of them are so old that it's hard to imagine they are still in use. Examples are Git2, Mapir Survey, Firefly Split 4K, Runcam, GoPro Hero5&7.}}<br />
<br />
== v2.xx Firmware for NT IMUs ==<br />
<br />
Firmware for STorM32 setups using a NT camera IMU. <br />
<br />
<br />
Direct link to v2.53 firmware download (this firmware is pretty old, it is highly recommended to use v2.67e):<br> <br />
<br />
:[//github.com/olliw42/storm32bgc/raw/main/firmware%20binaries%20%26%20gui/o323bgc-release-v253-v20200517.zip o323bgc-release-v253-v20200517] [.zip] (12.2 MB)<br />
:[//www.rcgroups.com/forums/showpost.php?p=44539519&postcount=12349 Release Notes]<br />
<br />
<br />
Latest beta release v2.73e:<br><br />
:[//github.com/olliw42/storm32bgc/raw/main/firmware%20binaries%20%26%20gui/o323bgc-release-v273e-v20250711.zip o323bgc-release-v273e-v20250711] [.zip] (15.9 MB)<br />
:[https://www.rcgroups.com/forums/showpost.php?p=53978973&postcount=15988 Release Notes]<br />
<br />
<br />
NTLoggerTool release v0.50:<br><br />
:[//www.olliw.eu/downloads/storm32/ntloggertool/ntloggertool-release-v050-v20231003.zip ntloggertool-release-v050-v20231003] [.zip] (295 MB)<br />
<br />
<br />
BetaCopter/BetaPlane 4.7-dev:<br><br />
:For downloading the firmwares and all further info please visit the article [[Using STorM32 with BetaPilot]].<br />
<br />
== v0.96 Firmware for I2C IMUs ==<br />
<br />
Firmware for STorM32 setups using a I2C camera IMU. Examples are the HakRC gimbal and other gimbals from Aliexpress.<br />
<br />
Latest firmware v0.96 for I2C IMUs:<br> <br />
:[//github.com/olliw42/storm32bgc/raw/master/firmware%20binaries%20%26%20gui/o323bgc-release-v096-v20160319.zip o323bgc-release-v096-v20160319] [.zip] (9.4MB)<br />
<br />
Note: This wiki here is not appropriate for v0.96 I2C setups, you should go to [//www.olliw.eu/storm32bgc-v1-wiki/Main_Page STorM32 v0.xx Wiki].<br />
<br />
{{COMMENT|The v0.96 release also includes firmwares for NT IMUs, identifiable by a label "nt" in the file names. Don't use them, use the v0.96 firmware (without a "nt" in the file name).}}<br />
<br />
== Repository ==<br />
<br />
Various files related to the STorM32-BGC project can be downloaded from several places:<br />
* [//github.com/olliw42/storm32bgc Github repository]<br />
* For other firmware versions see the 1st page of the [//www.rcgroups.com/forums/showthread.php?t=2055844 rcgroups discussion thread]</div>OlliWhttp://www.olliw.eu/storm32bgc-v2-wiki/index.php?title=STorM32_Boards&diff=11874STorM32 Boards2025-11-17T14:19:42Z<p>OlliW: /* STorM32-BGC v4.1 */</p>
<hr />
<div>The technical specifications of various STorM32 boards are presented, as far as they are known. To find suppliers/vendors please go to [[Where to buy STorM32 boards]]. For a detailed description of the various connectors on the (original) boards see [[Pins and Connectors]].<br />
<br />
== "Original" STorM32 Boards ==<br />
<br />
At present, board versions v1.3, v3.3, v4.1, v6.2 and v6.3 are in use and supported (v0.17/v1.0, v1.1, v1.2 and v2.4 boards are deprecated).<br />
{|<br />
|- valign="top"<br />
* The characteristic of the v1.3 board is a linear voltage regulator and on-board TC4452 motor drivers. <br />
* The v3.3 board is specifically designed for NT and especially T-STorM32, and is available in different form factors. It is distinguished by a low-noise 5 V switching voltage regulator and a 2nd UART2 port, but it has no motor drivers on board.<br />
* The v4.1 board combines, so to say, the v1.3 and v3.3 boards; it is designed for NT and T-STorM32 but also provides DRV8839 motor drivers on board.<br />
* The v6.2 board is similar to the v3.3 board, butsubstantially upgraded. It has STM32H7 processor and runs much faster, and also offers beefier voltage regulators. <br />
* The v6.3 board is the v6.x version which also provides DRV8839 motor drivers on board.. <br />
|}<br />
<br />
=== STorM32-BGC v6.3 ===<br />
----<br />
{|<br />
|- valign="top"<br />
|width=300px|<br />
* MCU: STM32H7A3RG at 280 MHz<br />
* motor drivers: DRV8839<br />
* voltage regulator: 5 V, 2 A (??) switching regulator<br />
* on-board ICM42688P/ICM42688V connected to SPI<br />
* 2x NT port and 1x NT-X port<br />
* UART2/ESP port<br />
* USB-C connector, permits flashing per USB<br />
* Futaba S-Bus, CRSF, Spektrum satellite<br />
* up to four PWM/Sum-PPM inputs/outputs<br />
* joystick port for two axes<br />
* 2 auxiliary ports, BUT port<br />
|<br />
* supply voltage: 6 - 12 V or 2 - 3S (with motor drivers enabled) <br/>'''''Comment''': The motor drivers are enabled by closing the JP1 solder bridge on the bottom side of the board. When the solder bridge is open (motor drivers disabled), the board can be used with voltages up to 20 V or 4S.''<br />
* motor current: 1.0 A (??)<br />
* board dimensions: 40 mm x 28 mm, 35 mm bolt to bolt, holes Ø3 mm<br />
|}<br />
<br />
{{COMMENT|This board is design of [https://www.gohstanddesigns.com/ Gohstand Designs] and based on the v4.1 design of [https://www.krattworks.com/ KrattWorks].}}<br />
<br />
=== STorM32-BGC v6.2 ===<br />
----<br />
{|<br />
|- valign="top"<br />
|width=300px|<br />
* MCU: STM32H7A3RG at 280 MHz<br />
* motor drivers: none<br />
* voltage regulator: 5 V, 2.0 A low-noise switching regulator<br />
* on-board ICM42688P/ICM42688V connected to SPI<br />
* 2x NT port and 1x NT-X port<br />
* UART2/ESP port<br />
* USB-C connector, permits flashing per USB<br />
* Futaba S-Bus, CRSF, Spektrum satellite<br />
* up to four PWM/Sum-PPM inputs/outputs<br />
* joystick port for two axes<br />
* 2 auxiliary ports, BUT port<br />
|<br />
* supply voltage: 6 - 27 V or 2 - 6S<br />
* motor current: depends on used NT motor modules<br />
* board dimensions: 40 mm x 25 mm, 35 mm bolt to bolt, holes Ø3 mm<br />
|}<br />
<br />
=== STorM32-BGC v4.1 ===<br />
----<br />
[[File:Storm32-bgc-nt-v41-picture.jpg|thumb|caption|STorM32 board v4.1, for NT and T-STorM32, with on-board motor drivers and USB-C connector.]]<br />
{|<br />
|- valign="top"<br />
|width=300px|<br />
* MCU: STM32F103RC at 72 MHz<br />
* motor drivers: DRV8839<br />
* voltage regulator: 5 V, 2 A (??) switching regulator<br />
* on-board IMU ICM42688P/ICM42688V, connected to SPI<br />
* 2x NT port and 1x NT-X port<br />
* UART2 port<br />
* on-board USB-TTL adapter CP2102, permits flashing per USB<br />
* USB-C connector<br />
* Futaba S-Bus, CRSF, Spektrum satellite<br />
* up to four PWM/Sum-PPM inputs/outputs<br />
* joystick port for two axes<br />
* 2 auxiliary ports, BUT port<br />
|<br />
* supply voltage: 6 - 12 V or 2 - 3S (with motor drivers enabled) <br/>'''''Comment''': The motor drivers are enabled by closing the JP1 solder bridge on the bottom side of the board. When the solder bridge is open (motor drivers disabled), the board can be used with voltages up to 20 V or 4S (??).''<br />
* motor current: 1.0 A (??)<br />
* board dimensions: 40 mm x 28 mm, 35 mm bolt to bolt, holes Ø3 mm<br />
|}<br />
<br />
{{COMMENT|This board is design of [https://www.krattworks.com/ KrattWorks], [https://bitbucket.org/teamkrattworks/hw_storm32_v4/src/master/release/storm32-nt-v4_1/].}}<br />
<br />
=== STorM32-BGC v3.3m, v3.3i ===<br />
----<br />
[[File:Storm32-v33m-thumb.jpg|thumb|caption|STorM32 board v3.3 specifically designed for NT and T-STorM32]]<br />
{|<br />
|- valign="top"<br />
|width=300px|<br />
* MCU: STM32F103RC at 72 MHz<br />
* motor drivers: none<br />
* voltage regulator: 5 V, 0.6 A low-noise switching regulator<br />
* on-board IMU MPU9250 (v3.3m) or ICM42605/ICM42688P/ICM42688V (v3.3i), connected to SPI<br />
* 2x NT port and 1x NT-X port<br />
* UART2/ESP port<br />
* CAN bus port (obsolete as not supported anymore)<br />
* on-board USB-TTL adapter CP2102, permits flashing per USB<br />
* Futaba S-Bus, CRSF, Spektrum satellite<br />
* up to four PWM/Sum-PPM inputs/outputs<br />
* joystick port for two axes<br />
* 2 auxiliary ports, BUT port<br />
|<br />
* supply voltage: 6 - 27 V or 2 - 6S<br />
* motor current: depends on used NT motor modules<br />
* board dimensions: 40 mm x 25 mm, 35 mm bolt to bolt, holes Ø3 mm<br />
|}<br />
<br />
{{COMMENT|The v3.3m version has a MPU9250 on-board IMU and the v3.3i version has a ICM42605/ICM42688P/ICM42688V on-board IMU.}}<br />
<br />
{{COMMENT|{{WARNING|This board has no motor drivers; NT motor modules are thus mandatorily required.}}}}<br />
<!--<br />
=== STorM32-BGC v2.4 ===<br />
----<br />
[[File:Storm32-bgc-nt-v24-picture.jpg|thumb|caption|STorM32-BGC board v2.4 specifically designed for NT]]<br />
{|<br />
|- valign="top"<br />
|width=300px|<br />
* MCU: STM32F103RC at 72 MHz<br />
* motor drivers for yaw axis: TC4452<br />
* voltage regulator: linear resistive<br />
* on-board MPU9250 IMU<br />
* Futaba S-Bus<br />
* Spektrum satellite<br />
* up to four PWM/Sum-PPM inputs/outputs<br />
* joystick port for two axes<br />
* 2 auxiliary ports, one BUT port<br />
* 2x NT ports and 1x NT-X port<br />
|<br />
* supply voltage: 6 - 18 V or 2 - 4S<br />
* motor current: max. 1 A per motor<br />
* board dimensions: 40 mm x 25 mm, 35 mm bolt to bolt, holes Ø3 mm<br />
|}<br />
<br />
{{COMMENT|{{WARNING|This board has been deprecated.}}}}--><br />
<br />
=== Micro STorM32-BGC v3.3i ===<br />
----<br />
[[File:Storm32-micro-v33i-thumb.jpg|thumb|caption|Micro STorM32 board v3.3i]]<br />
{|<br />
|- valign="top"<br />
|width=300px|<br />
* MCU: STM32F103RC at 72 MHz<br />
* motor drivers: none<br />
* voltage regulator: none<br />
* on-board IMU ICM42605/ICM42688P/ICM42688V, connected to SPI<br />
* 1x NT port and 1x NT-X port<br />
* UART2/ESP port<br />
* Futaba S-Bus, CRSF, Spektrum satellite<br />
* up to four PWM/Sum-PPM inputs/outputs<br />
* joystick port for two axes<br />
* 2 auxiliary ports, BUT port<br />
|<br />
* supply voltage: 5 V<br />
* motor current: depends on used NT motor modules<br />
* board dimensions: 26 mm x 26 mm, 20 mm bolt to bolt, holes Ø2 mm<br />
|}<br />
<br />
{{COMMENT|{{WARNING|This board has no motor drivers; NT motor modules are thus mandatorily required.}}}}<br />
<br />
{{COMMENT|Also the STorM32 Raspberry Pi Hat v3.3i exists, which is essentially the Micro board in different form factor with some additional peripherals useful for Raspberry Pi applications.}}<br />
<!--<br />
=== STorM32 Raspberry Pi Hat v3.3i ===<br />
----<br />
[[File:Storm32-rpihat-v33i-thumb.jpg|thumb|caption|STorM32 RPi Hat]]<br />
{|<br />
|- valign="top"<br />
|width=300px|<br />
* MCU: STM32F103RC at 72 MHz<br />
* motor drivers: none<br />
* voltage regulator: none<br />
* on-board IMU ICM42605/ICM42688P/ICM42688V, connected to SPI<br />
* 1x NT port and 1x NT-X port<br />
* UART2/ESP port<br />
* Futaba S-Bus, CRSF, Spektrum satellite<br />
* up to three PWM/Sum-PPM inputs/outputs<br />
* joystick port for two axes<br />
* 2 auxiliary ports, BUT port<br />
* Dual UART expander SC16IS762, connected to SPI<br />
* RPi Uart and RPi I2C on 6-pin JST-GH connector, DroneCode compatible<br />
* UART expander Uart on 6-pin JST-GH connector, DroneCode compatible<br />
* LED, controllable by RPi<br />
* extension board for dual 5.3V/3.5A power supply available<br />
|<br />
* supply voltage: 5 V<br />
* motor current: depends on used NT motor modules<br />
* board dimensions: RaspberryPi micro hat<br />
|}<br />
<br />
{{COMMENT|{{WARNING|This board has no motor drivers; NT motor modules are thus mandatorily required.}}}}<br />
<br clear="all" /><br />
--><br />
<br />
=== STorM32-BGC v1.3 ===<br />
----<br />
[[File:Joepaisley-storm32-bgc-v13-board-wiki.jpg|thumb|caption|STorM32-BGC board v1.3 with motor drivers in SOIC package]]<br />
<!--[[File:Storm32 bgc v120 board dfn mpu-01-wp01.jpg|thumb|caption|STorM32-BGC board v1.2 with motor drivers in DFN package]]<br />
[[File:Storm32-bgc-v110-board-top-01-wp01.jpg|thumb|caption|STorM32-BGC board v1.1 with motor drivers in SOIC package]]--><br />
{|<br />
|- valign="top"<br />
|width=300px|<br />
* MCU: STM32F103RC at 72 MHz<br />
* motor drivers: TC4452<br />
* voltage regulator: linear resistive<br />
* on-board Bluetooth (optional)<br />
* on-board IMU (MPU6050)<br />
* IR led<br />
* Futaba S-Bus, CRSF, Spektrum satellite<br />
* up to seven PWM/Sum-PPM inputs/outputs<br />
* joystick ports for three axes<br />
* additional I2C port (I2C#2)<br />
* 3 auxiliary ports <br />
* BUT port<br />
|<br />
* supply voltage: 6 - 18 V or 2 - 4S<br />
* motor current: max. 1.5 A per motor<br/>'''''Comment''': This is not yet fully exploited and also depends on the package, with DFN packages motors with resistances of 12 Ohm or larger have been tested to be well handled at 4S, motors with 10 Ohm may be handled with care; for the latest summary see [http://www.rcgroups.com/forums/showpost.php?p=30564101&postcount=3166 here] (for details see also [//www.rcgroups.com/forums/showthread.php?t=2055844&page=2&pp=50#post27515444 here], [//www.rcgroups.com/forums/showthread.php?t=2055844&page=15&pp=50#post28578479 here]), [http://www.rcgroups.com/forums/showpost.php?p=28825482&postcount=947 here] and [http://www.rcgroups.com/forums/showpost.php?p=28852888&postcount=953 here])''.<br />
* board dimensions: 50 mm x 50 mm, 45 mm bolt to bolt, holes Ø3 mm<br />
|}<br />
<br />
{{COMMENT|This board was designed in cooperation with Martinez.}}<br />
<br />
<br />
<!--=== STorM32-BGC v1.2 ===<br />
----<br />
Differences to the v1.3 board:<br />
* voltage regulator: smaller SOT223 package<br />
* only 2 auxiliary ports <br />
<br />
=== STorM32-BGC v1.1 ===<br />
----<br />
Differences to the v1.3 board:<br />
* no Futaba S-bus support<br />
* Spektrum satellite is supported, but no extra Spektrum connector on board<br />
* no extra USB voltage protection diode<br />
* voltage regulator: smaller SOT223 package<br />
* only 2 auxiliary ports <br />
<br />
''{{WARNING|'''WARNING:''' The pins of connector I2C#2 are in reverse order to those of connector I2C, which implies also reversed voltage polarity. Pay attention to that before connecting a second IMU to the I2C#2 port.}}'' --><br />
<br />
<br clear="all" /><br />
<br />
== Descendants ==<br />
<br />
The STorM32 boards listed here are designs of third parties, which are based on or derived from the "original" board designs, but modified in some ways.<br />
<br />
=== Ensys STorM32 v3.3 ===<br />
----<br />
[[File:Ensys storm32 33 persp.png|thumb|caption|Ensys STorM32 v3.3]]<br />
{|<br />
|- valign="top"<br />
|width=300px|<br />
* MCU: STM32F103RC at 72 MHz<br />
* motor drivers: none<br />
* voltage regulator: 5.5 V, 1 A switching regulator<br />
* on-board MPU9250, connected to SPI<br />
* 2x NT ports and 1x NT-X port<br />
* UART2/ESP port<br />
* CAN bus port (obsolete as not supported anymore)<br />
* on-board CH340, enables flashing per USB<br />
* Futaba S-Bus, CRSF, Spektrum satellite<br />
* up to four PWM/Sum-PPM inputs/outputs<br />
* joystick port for two axes<br />
* 2 auxiliary ports, one BUT port<br />
|<br />
* supply voltage: 6 - 17 V or 2 - 4S<br />
* motor current: depends on used NT motor modules<br />
* board dimensions: 40 mm x 25 mm, 35 mm bolt to bolt, holes Ø3 mm<br />
|}<br />
<br />
{{COMMENT|{{WARNING|This board has no motor drivers; NT motor modules are thus mandatorily required.}}}}<br />
<br />
=== GLB STorM32 v1.31 ===<br />
----<br />
[[File:Sku 110143 1.jpg|thumb|caption|STorM32-BGC board v1.31 with DRV8313 motor drivers]]<br />
{|<br />
|- valign="top"<br />
|width=300px|<br />
* MCU: STM32F103RC at 72 MHz<br />
* motor drivers: DRV8313<br />
* voltage regulator: switched step-down<br />
* on-board Bluetooth (optional)<br />
* on-board 6DOF IMU (MPU6050)<br />
* IR led<br />
* Futaba S-Bus<br />
* Spektrum satellite<br />
* up to seven PWM/Sum-PPM inputs/outputs<br />
* joystick ports for all three axes<br />
* additional I2C port (I2C#2)<br />
* 3 auxiliary ports <br />
* BUT port<br />
|<br />
* supply voltage: 9 - 25 V or 3 - 6S (according to the specs given by GLB, not yet confirmed in practice)<br />
* motor current: 1.5 A<br/>'''''Comment''': The board uses the same motor drivers as the BaseCam SimpleBGC 32-bit board, and the same spec can hence be expected, but the real capability has not yet been tested in practice''.<br />
* board dimensions: 50 mm x 50 mm, 45 mm bolt to bolt, holes Ø3 mm<br />
|}<br />
<br />
{{COMMENT|{{WARNING|The 3.3V power on this board seems to be quite weak, and has caused repeatedly issues with powering NT modules. One single NT IMU seems to be ok, but not more. See also [[https://www.rcgroups.com/forums/showpost.php?p=36049535&postcount=9117]].}}}}<br />
<br />
{{COMMENT|{{WARNING|There had been cases with a problem with EMI noise on the 433/915 MHz band from this board, see [[https://www.rcgroups.com/forums/showpost.php?p=34132760&postcount=579]]. For solutions see [[https://www.rcgroups.com/forums/showpost.php?p=34139984&postcount=585]]. EMI noise seems not to be a problem in general, however, see [[https://github.com/ArduPilot/ardupilot_wiki/pull/885]].}}}}<br />
<br />
=== STorM32 v1.32 ===<br />
----<br />
[[File:Storm32-BGC-32Bit-3-Axis-Brushless-Gimbal-Controller-V1-31-ESC-Alexmos32-RC-Gimbal-RC-Quadcopter.jpg|thumb|caption|STorM32-BGC board v1.32 with DRV8313 motor drivers]]<br />
{|<br />
|- valign="top"<br />
|width=300px|<br />
* MCU: STM32F103RC at 72 MHz<br />
* motor drivers: DRV8313<br />
* voltage regulator: linear<br />
* on-board Bluetooth (optional)<br />
* on-board 6DOF IMU (MPU6050)<br />
* IR led<br />
* Futaba S-Bus<br />
* Spektrum satellite<br />
* up to seven PWM/Sum-PPM inputs/outputs<br />
* joystick ports for all three axes<br />
* additional I2C port (I2C#2)<br />
* 3 auxiliary ports <br />
* BUT port<br />
|<br />
* supply voltage: 9 - 18 V or 3 - 4S<br />
* motor current: 1.5 A<br/>'''''Comment''': The board uses the same motor drivers as the BaseCam SimpleBGC 32-bit board, and the same spec can hence be expected, but the real capability has not yet been tested in practice''.<br />
* board dimensions: 50 mm x 50 mm, 45 mm bolt to bolt, holes Ø3 mm<br />
|}<br />
<br />
{{COMMENT|For NT setups this board might be preferred over the v1.31 board, since it uses the same linear regulator as the v1.3 and not the weak switching regulator of the v1.31. For older I2C-based setups it's probably better to get a v1.31, which tends to be cheaper and especially offers a switching voltage regulator.}}<br />
<br />
=== Witespy STorM32-BGC v1.1 Mosfet Version ===<br />
----<br />
[[File:Witespy-v11-mosfet.jpg|thumb|caption|Witespy STorM32-BGC v1.1 board with mosfet motor drivers]]<br />
{|<br />
|- valign="top"<br />
|width=300px|<br />
* MCU: STM32F103RC at 72 MHz<br />
* motor drivers: mosfet<br />
* voltage regulator: linear<br />
|<br />
* supply voltage: ? (no specs given by witespy)<br />
* motor current: ? (no specs given by wiitespy)<br />
* board dimensions: 50 mm x 50 mm, 45 mm bolt to bolt, holes Ø3 mm<br />
|}<br clear="all" /><br />
<br />
== Third-Party Boards ==<br />
<br />
The terms of usage of the STorM32 project allows, and in fact encourages, making own hardware, for both DIY and commercial purposes, without restrictions. The STorM32 boards listed here are independent designs by third-parties.<br />
<br />
=== Micro STorM32 BGC ===<br />
----<br />
[[File:HTB1REO1IpXXXXXjXpXXq6xXFXXX3-kl.jpg|thumb|caption|Micro STorM32-BGC board]]<br />
{|<br />
|- valign="top"<br />
|width=300px|<br />
* MCU: STM32F103RC at 72 MHz<br />
* motor drivers: TC4452<br />
* voltage regulator: linear (LG33)<br />
|<br />
* supply voltage: 7.4 - 16.8 V or 2 - 4S<br />
* motor current: 1.5 A (according to the given specs, whatever this means)<br />
* board dimensions: 40 mm x 22 mm, no mounting holes<br />
* no BOOT0 and RESET buttons<br />
|}<br />
<br />
{{COMMENT|{{WARNING| This board is suitable only for 2S (see [[http://www.rcgroups.com/forums/showpost.php?p=33480082&postcount=7004]]), with higher voltages it gets quite hot and may malfunction. Read also this: [[http://www.rcgroups.com/forums/showthread.php?t=2055844&page=144&pp=50#post33773254]]. The board can only be flashed with a ST-Link adapter via SWD, it cannot be flashed via the "usual" procedure. Many pins/ports are not available. Overall, this board cannot be recommended, except for special applications.}}}} <br />
<br clear="all" /><br />
<br />
=== GLB Mini STorM32 BGC ===<br />
----<br />
[[File:Sku 113113 1.jpg|thumb|caption|GLB Mini STorM32-BGC board with L6230 motor drivers]]<br />
{|<br />
|- valign="top"<br />
|width=300px|<br />
* MCU: STM32F103RC at 72 MHz<br />
* motor drivers: L6230<br />
* voltage regulator: switched step-down<br />
|<br />
* supply voltage: 7 - 25 V or 3 - 6S (according to the specs given by GLB, whatever this means)<br />
* motor current: 1.5 A (according to the specs given by GLB, whatever this means)<br />
* board dimensions: 42 mm x 30 mm, ? mm bolt to bolt, holes Ø? mm<br />
|}<br clear="all" /><br />
<br />
=== AliExpress Mini STorM32 BGC ===<br />
----<br />
[[File:Aliexpress-min-storm32.jpg|thumb|caption|AliExpress Mini STorM32-BGC board]]<br />
{|<br />
|- valign="top"<br />
|width=300px|<br />
* MCU: STM32F103RC at 72 MHz<br />
* motor drivers: DRV8313<br />
* voltage regulator: linear<br />
|<br />
* supply voltage: 7.4 - 16.8 V or 2 - 4S (according to the specs given by AE, whatever this means)<br />
* motor current: 1.5 A<br />
* board dimensions: 40 mm x 30 mm, 43 mm pitch ??, holes Ø2 mm<br />
|}<br />
<br />
{{COMMENT|{{WARNING|The info given on some pages is definitely wrong in some aspects.}}}} ''What we know so far (see also [http://www.rcgroups.com/forums/showpost.php?p=32058700&postcount=5525 here] and followup posts):''<br />
* DRV8313 motor drivers do not allow 2S operation<br />
* only the RC port is available<br />
* SBus is not supported<br />
* BT module cannot be installed on-board</div>OlliWhttp://www.olliw.eu/storm32bgc-v2-wiki/index.php?title=STorM32_Boards&diff=11873STorM32 Boards2025-11-17T14:19:27Z<p>OlliW: /* STorM32-BGC v6.3 */</p>
<hr />
<div>The technical specifications of various STorM32 boards are presented, as far as they are known. To find suppliers/vendors please go to [[Where to buy STorM32 boards]]. For a detailed description of the various connectors on the (original) boards see [[Pins and Connectors]].<br />
<br />
== "Original" STorM32 Boards ==<br />
<br />
At present, board versions v1.3, v3.3, v4.1, v6.2 and v6.3 are in use and supported (v0.17/v1.0, v1.1, v1.2 and v2.4 boards are deprecated).<br />
{|<br />
|- valign="top"<br />
* The characteristic of the v1.3 board is a linear voltage regulator and on-board TC4452 motor drivers. <br />
* The v3.3 board is specifically designed for NT and especially T-STorM32, and is available in different form factors. It is distinguished by a low-noise 5 V switching voltage regulator and a 2nd UART2 port, but it has no motor drivers on board.<br />
* The v4.1 board combines, so to say, the v1.3 and v3.3 boards; it is designed for NT and T-STorM32 but also provides DRV8839 motor drivers on board.<br />
* The v6.2 board is similar to the v3.3 board, butsubstantially upgraded. It has STM32H7 processor and runs much faster, and also offers beefier voltage regulators. <br />
* The v6.3 board is the v6.x version which also provides DRV8839 motor drivers on board.. <br />
|}<br />
<br />
=== STorM32-BGC v6.3 ===<br />
----<br />
{|<br />
|- valign="top"<br />
|width=300px|<br />
* MCU: STM32H7A3RG at 280 MHz<br />
* motor drivers: DRV8839<br />
* voltage regulator: 5 V, 2 A (??) switching regulator<br />
* on-board ICM42688P/ICM42688V connected to SPI<br />
* 2x NT port and 1x NT-X port<br />
* UART2/ESP port<br />
* USB-C connector, permits flashing per USB<br />
* Futaba S-Bus, CRSF, Spektrum satellite<br />
* up to four PWM/Sum-PPM inputs/outputs<br />
* joystick port for two axes<br />
* 2 auxiliary ports, BUT port<br />
|<br />
* supply voltage: 6 - 12 V or 2 - 3S (with motor drivers enabled) <br/>'''''Comment''': The motor drivers are enabled by closing the JP1 solder bridge on the bottom side of the board. When the solder bridge is open (motor drivers disabled), the board can be used with voltages up to 20 V or 4S.''<br />
* motor current: 1.0 A (??)<br />
* board dimensions: 40 mm x 28 mm, 35 mm bolt to bolt, holes Ø3 mm<br />
|}<br />
<br />
{{COMMENT|This board is design of [https://www.gohstanddesigns.com/ Gohstand Designs] and based on the v4.1 design of [https://www.krattworks.com/ KrattWorks].}}<br />
<br />
=== STorM32-BGC v6.2 ===<br />
----<br />
{|<br />
|- valign="top"<br />
|width=300px|<br />
* MCU: STM32H7A3RG at 280 MHz<br />
* motor drivers: none<br />
* voltage regulator: 5 V, 2.0 A low-noise switching regulator<br />
* on-board ICM42688P/ICM42688V connected to SPI<br />
* 2x NT port and 1x NT-X port<br />
* UART2/ESP port<br />
* USB-C connector, permits flashing per USB<br />
* Futaba S-Bus, CRSF, Spektrum satellite<br />
* up to four PWM/Sum-PPM inputs/outputs<br />
* joystick port for two axes<br />
* 2 auxiliary ports, BUT port<br />
|<br />
* supply voltage: 6 - 27 V or 2 - 6S<br />
* motor current: depends on used NT motor modules<br />
* board dimensions: 40 mm x 25 mm, 35 mm bolt to bolt, holes Ø3 mm<br />
|}<br />
<br />
=== STorM32-BGC v4.1 ===<br />
----<br />
[[File:Storm32-bgc-nt-v41-picture.jpg|thumb|caption|STorM32 board v4.1, for NT and T-STorM32, with on-board motor drivers and USB-C connector.]]<br />
{|<br />
|- valign="top"<br />
|width=300px|<br />
* MCU: STM32F103RC at 72 MHz<br />
* motor drivers: DRV8839<br />
* voltage regulator: 5 V, 2 A (??) switching regulator<br />
* on-board IMU ICM42688P/ICM42688V, connected to SPI<br />
* 2x NT port and 1x NT-X port<br />
* UART2 port<br />
* on-board USB-TTL adapter CP2102, permits flashing per USB<br />
* USB-C connector<br />
* Futaba S-Bus, CRSF, Spektrum satellite<br />
* up to four PWM/Sum-PPM inputs/outputs<br />
* joystick port for two axes<br />
* 2 auxiliary ports, BUT port<br />
|<br />
* supply voltage: 6 - 12 V or 2 - 3S (with motor drivers enabled) <br/>'''''Comment''': The motor drivers are enabled by closing the JP1 solder bridge (on the bottom side of the board). When the solder bridge is open, the board can be used with voltages up to 20 V or 4S (??).''<br />
* motor current: 1.0 A (??)<br />
* board dimensions: 40 mm x 28 mm, 35 mm bolt to bolt, holes Ø3 mm<br />
|}<br />
<br />
{{COMMENT|This board is design of [https://www.krattworks.com/ KrattWorks], [https://bitbucket.org/teamkrattworks/hw_storm32_v4/src/master/release/storm32-nt-v4_1/].}}<br />
<br />
=== STorM32-BGC v3.3m, v3.3i ===<br />
----<br />
[[File:Storm32-v33m-thumb.jpg|thumb|caption|STorM32 board v3.3 specifically designed for NT and T-STorM32]]<br />
{|<br />
|- valign="top"<br />
|width=300px|<br />
* MCU: STM32F103RC at 72 MHz<br />
* motor drivers: none<br />
* voltage regulator: 5 V, 0.6 A low-noise switching regulator<br />
* on-board IMU MPU9250 (v3.3m) or ICM42605/ICM42688P/ICM42688V (v3.3i), connected to SPI<br />
* 2x NT port and 1x NT-X port<br />
* UART2/ESP port<br />
* CAN bus port (obsolete as not supported anymore)<br />
* on-board USB-TTL adapter CP2102, permits flashing per USB<br />
* Futaba S-Bus, CRSF, Spektrum satellite<br />
* up to four PWM/Sum-PPM inputs/outputs<br />
* joystick port for two axes<br />
* 2 auxiliary ports, BUT port<br />
|<br />
* supply voltage: 6 - 27 V or 2 - 6S<br />
* motor current: depends on used NT motor modules<br />
* board dimensions: 40 mm x 25 mm, 35 mm bolt to bolt, holes Ø3 mm<br />
|}<br />
<br />
{{COMMENT|The v3.3m version has a MPU9250 on-board IMU and the v3.3i version has a ICM42605/ICM42688P/ICM42688V on-board IMU.}}<br />
<br />
{{COMMENT|{{WARNING|This board has no motor drivers; NT motor modules are thus mandatorily required.}}}}<br />
<!--<br />
=== STorM32-BGC v2.4 ===<br />
----<br />
[[File:Storm32-bgc-nt-v24-picture.jpg|thumb|caption|STorM32-BGC board v2.4 specifically designed for NT]]<br />
{|<br />
|- valign="top"<br />
|width=300px|<br />
* MCU: STM32F103RC at 72 MHz<br />
* motor drivers for yaw axis: TC4452<br />
* voltage regulator: linear resistive<br />
* on-board MPU9250 IMU<br />
* Futaba S-Bus<br />
* Spektrum satellite<br />
* up to four PWM/Sum-PPM inputs/outputs<br />
* joystick port for two axes<br />
* 2 auxiliary ports, one BUT port<br />
* 2x NT ports and 1x NT-X port<br />
|<br />
* supply voltage: 6 - 18 V or 2 - 4S<br />
* motor current: max. 1 A per motor<br />
* board dimensions: 40 mm x 25 mm, 35 mm bolt to bolt, holes Ø3 mm<br />
|}<br />
<br />
{{COMMENT|{{WARNING|This board has been deprecated.}}}}--><br />
<br />
=== Micro STorM32-BGC v3.3i ===<br />
----<br />
[[File:Storm32-micro-v33i-thumb.jpg|thumb|caption|Micro STorM32 board v3.3i]]<br />
{|<br />
|- valign="top"<br />
|width=300px|<br />
* MCU: STM32F103RC at 72 MHz<br />
* motor drivers: none<br />
* voltage regulator: none<br />
* on-board IMU ICM42605/ICM42688P/ICM42688V, connected to SPI<br />
* 1x NT port and 1x NT-X port<br />
* UART2/ESP port<br />
* Futaba S-Bus, CRSF, Spektrum satellite<br />
* up to four PWM/Sum-PPM inputs/outputs<br />
* joystick port for two axes<br />
* 2 auxiliary ports, BUT port<br />
|<br />
* supply voltage: 5 V<br />
* motor current: depends on used NT motor modules<br />
* board dimensions: 26 mm x 26 mm, 20 mm bolt to bolt, holes Ø2 mm<br />
|}<br />
<br />
{{COMMENT|{{WARNING|This board has no motor drivers; NT motor modules are thus mandatorily required.}}}}<br />
<br />
{{COMMENT|Also the STorM32 Raspberry Pi Hat v3.3i exists, which is essentially the Micro board in different form factor with some additional peripherals useful for Raspberry Pi applications.}}<br />
<!--<br />
=== STorM32 Raspberry Pi Hat v3.3i ===<br />
----<br />
[[File:Storm32-rpihat-v33i-thumb.jpg|thumb|caption|STorM32 RPi Hat]]<br />
{|<br />
|- valign="top"<br />
|width=300px|<br />
* MCU: STM32F103RC at 72 MHz<br />
* motor drivers: none<br />
* voltage regulator: none<br />
* on-board IMU ICM42605/ICM42688P/ICM42688V, connected to SPI<br />
* 1x NT port and 1x NT-X port<br />
* UART2/ESP port<br />
* Futaba S-Bus, CRSF, Spektrum satellite<br />
* up to three PWM/Sum-PPM inputs/outputs<br />
* joystick port for two axes<br />
* 2 auxiliary ports, BUT port<br />
* Dual UART expander SC16IS762, connected to SPI<br />
* RPi Uart and RPi I2C on 6-pin JST-GH connector, DroneCode compatible<br />
* UART expander Uart on 6-pin JST-GH connector, DroneCode compatible<br />
* LED, controllable by RPi<br />
* extension board for dual 5.3V/3.5A power supply available<br />
|<br />
* supply voltage: 5 V<br />
* motor current: depends on used NT motor modules<br />
* board dimensions: RaspberryPi micro hat<br />
|}<br />
<br />
{{COMMENT|{{WARNING|This board has no motor drivers; NT motor modules are thus mandatorily required.}}}}<br />
<br clear="all" /><br />
--><br />
<br />
=== STorM32-BGC v1.3 ===<br />
----<br />
[[File:Joepaisley-storm32-bgc-v13-board-wiki.jpg|thumb|caption|STorM32-BGC board v1.3 with motor drivers in SOIC package]]<br />
<!--[[File:Storm32 bgc v120 board dfn mpu-01-wp01.jpg|thumb|caption|STorM32-BGC board v1.2 with motor drivers in DFN package]]<br />
[[File:Storm32-bgc-v110-board-top-01-wp01.jpg|thumb|caption|STorM32-BGC board v1.1 with motor drivers in SOIC package]]--><br />
{|<br />
|- valign="top"<br />
|width=300px|<br />
* MCU: STM32F103RC at 72 MHz<br />
* motor drivers: TC4452<br />
* voltage regulator: linear resistive<br />
* on-board Bluetooth (optional)<br />
* on-board IMU (MPU6050)<br />
* IR led<br />
* Futaba S-Bus, CRSF, Spektrum satellite<br />
* up to seven PWM/Sum-PPM inputs/outputs<br />
* joystick ports for three axes<br />
* additional I2C port (I2C#2)<br />
* 3 auxiliary ports <br />
* BUT port<br />
|<br />
* supply voltage: 6 - 18 V or 2 - 4S<br />
* motor current: max. 1.5 A per motor<br/>'''''Comment''': This is not yet fully exploited and also depends on the package, with DFN packages motors with resistances of 12 Ohm or larger have been tested to be well handled at 4S, motors with 10 Ohm may be handled with care; for the latest summary see [http://www.rcgroups.com/forums/showpost.php?p=30564101&postcount=3166 here] (for details see also [//www.rcgroups.com/forums/showthread.php?t=2055844&page=2&pp=50#post27515444 here], [//www.rcgroups.com/forums/showthread.php?t=2055844&page=15&pp=50#post28578479 here]), [http://www.rcgroups.com/forums/showpost.php?p=28825482&postcount=947 here] and [http://www.rcgroups.com/forums/showpost.php?p=28852888&postcount=953 here])''.<br />
* board dimensions: 50 mm x 50 mm, 45 mm bolt to bolt, holes Ø3 mm<br />
|}<br />
<br />
{{COMMENT|This board was designed in cooperation with Martinez.}}<br />
<br />
<br />
<!--=== STorM32-BGC v1.2 ===<br />
----<br />
Differences to the v1.3 board:<br />
* voltage regulator: smaller SOT223 package<br />
* only 2 auxiliary ports <br />
<br />
=== STorM32-BGC v1.1 ===<br />
----<br />
Differences to the v1.3 board:<br />
* no Futaba S-bus support<br />
* Spektrum satellite is supported, but no extra Spektrum connector on board<br />
* no extra USB voltage protection diode<br />
* voltage regulator: smaller SOT223 package<br />
* only 2 auxiliary ports <br />
<br />
''{{WARNING|'''WARNING:''' The pins of connector I2C#2 are in reverse order to those of connector I2C, which implies also reversed voltage polarity. Pay attention to that before connecting a second IMU to the I2C#2 port.}}'' --><br />
<br />
<br clear="all" /><br />
<br />
== Descendants ==<br />
<br />
The STorM32 boards listed here are designs of third parties, which are based on or derived from the "original" board designs, but modified in some ways.<br />
<br />
=== Ensys STorM32 v3.3 ===<br />
----<br />
[[File:Ensys storm32 33 persp.png|thumb|caption|Ensys STorM32 v3.3]]<br />
{|<br />
|- valign="top"<br />
|width=300px|<br />
* MCU: STM32F103RC at 72 MHz<br />
* motor drivers: none<br />
* voltage regulator: 5.5 V, 1 A switching regulator<br />
* on-board MPU9250, connected to SPI<br />
* 2x NT ports and 1x NT-X port<br />
* UART2/ESP port<br />
* CAN bus port (obsolete as not supported anymore)<br />
* on-board CH340, enables flashing per USB<br />
* Futaba S-Bus, CRSF, Spektrum satellite<br />
* up to four PWM/Sum-PPM inputs/outputs<br />
* joystick port for two axes<br />
* 2 auxiliary ports, one BUT port<br />
|<br />
* supply voltage: 6 - 17 V or 2 - 4S<br />
* motor current: depends on used NT motor modules<br />
* board dimensions: 40 mm x 25 mm, 35 mm bolt to bolt, holes Ø3 mm<br />
|}<br />
<br />
{{COMMENT|{{WARNING|This board has no motor drivers; NT motor modules are thus mandatorily required.}}}}<br />
<br />
=== GLB STorM32 v1.31 ===<br />
----<br />
[[File:Sku 110143 1.jpg|thumb|caption|STorM32-BGC board v1.31 with DRV8313 motor drivers]]<br />
{|<br />
|- valign="top"<br />
|width=300px|<br />
* MCU: STM32F103RC at 72 MHz<br />
* motor drivers: DRV8313<br />
* voltage regulator: switched step-down<br />
* on-board Bluetooth (optional)<br />
* on-board 6DOF IMU (MPU6050)<br />
* IR led<br />
* Futaba S-Bus<br />
* Spektrum satellite<br />
* up to seven PWM/Sum-PPM inputs/outputs<br />
* joystick ports for all three axes<br />
* additional I2C port (I2C#2)<br />
* 3 auxiliary ports <br />
* BUT port<br />
|<br />
* supply voltage: 9 - 25 V or 3 - 6S (according to the specs given by GLB, not yet confirmed in practice)<br />
* motor current: 1.5 A<br/>'''''Comment''': The board uses the same motor drivers as the BaseCam SimpleBGC 32-bit board, and the same spec can hence be expected, but the real capability has not yet been tested in practice''.<br />
* board dimensions: 50 mm x 50 mm, 45 mm bolt to bolt, holes Ø3 mm<br />
|}<br />
<br />
{{COMMENT|{{WARNING|The 3.3V power on this board seems to be quite weak, and has caused repeatedly issues with powering NT modules. One single NT IMU seems to be ok, but not more. See also [[https://www.rcgroups.com/forums/showpost.php?p=36049535&postcount=9117]].}}}}<br />
<br />
{{COMMENT|{{WARNING|There had been cases with a problem with EMI noise on the 433/915 MHz band from this board, see [[https://www.rcgroups.com/forums/showpost.php?p=34132760&postcount=579]]. For solutions see [[https://www.rcgroups.com/forums/showpost.php?p=34139984&postcount=585]]. EMI noise seems not to be a problem in general, however, see [[https://github.com/ArduPilot/ardupilot_wiki/pull/885]].}}}}<br />
<br />
=== STorM32 v1.32 ===<br />
----<br />
[[File:Storm32-BGC-32Bit-3-Axis-Brushless-Gimbal-Controller-V1-31-ESC-Alexmos32-RC-Gimbal-RC-Quadcopter.jpg|thumb|caption|STorM32-BGC board v1.32 with DRV8313 motor drivers]]<br />
{|<br />
|- valign="top"<br />
|width=300px|<br />
* MCU: STM32F103RC at 72 MHz<br />
* motor drivers: DRV8313<br />
* voltage regulator: linear<br />
* on-board Bluetooth (optional)<br />
* on-board 6DOF IMU (MPU6050)<br />
* IR led<br />
* Futaba S-Bus<br />
* Spektrum satellite<br />
* up to seven PWM/Sum-PPM inputs/outputs<br />
* joystick ports for all three axes<br />
* additional I2C port (I2C#2)<br />
* 3 auxiliary ports <br />
* BUT port<br />
|<br />
* supply voltage: 9 - 18 V or 3 - 4S<br />
* motor current: 1.5 A<br/>'''''Comment''': The board uses the same motor drivers as the BaseCam SimpleBGC 32-bit board, and the same spec can hence be expected, but the real capability has not yet been tested in practice''.<br />
* board dimensions: 50 mm x 50 mm, 45 mm bolt to bolt, holes Ø3 mm<br />
|}<br />
<br />
{{COMMENT|For NT setups this board might be preferred over the v1.31 board, since it uses the same linear regulator as the v1.3 and not the weak switching regulator of the v1.31. For older I2C-based setups it's probably better to get a v1.31, which tends to be cheaper and especially offers a switching voltage regulator.}}<br />
<br />
=== Witespy STorM32-BGC v1.1 Mosfet Version ===<br />
----<br />
[[File:Witespy-v11-mosfet.jpg|thumb|caption|Witespy STorM32-BGC v1.1 board with mosfet motor drivers]]<br />
{|<br />
|- valign="top"<br />
|width=300px|<br />
* MCU: STM32F103RC at 72 MHz<br />
* motor drivers: mosfet<br />
* voltage regulator: linear<br />
|<br />
* supply voltage: ? (no specs given by witespy)<br />
* motor current: ? (no specs given by wiitespy)<br />
* board dimensions: 50 mm x 50 mm, 45 mm bolt to bolt, holes Ø3 mm<br />
|}<br clear="all" /><br />
<br />
== Third-Party Boards ==<br />
<br />
The terms of usage of the STorM32 project allows, and in fact encourages, making own hardware, for both DIY and commercial purposes, without restrictions. The STorM32 boards listed here are independent designs by third-parties.<br />
<br />
=== Micro STorM32 BGC ===<br />
----<br />
[[File:HTB1REO1IpXXXXXjXpXXq6xXFXXX3-kl.jpg|thumb|caption|Micro STorM32-BGC board]]<br />
{|<br />
|- valign="top"<br />
|width=300px|<br />
* MCU: STM32F103RC at 72 MHz<br />
* motor drivers: TC4452<br />
* voltage regulator: linear (LG33)<br />
|<br />
* supply voltage: 7.4 - 16.8 V or 2 - 4S<br />
* motor current: 1.5 A (according to the given specs, whatever this means)<br />
* board dimensions: 40 mm x 22 mm, no mounting holes<br />
* no BOOT0 and RESET buttons<br />
|}<br />
<br />
{{COMMENT|{{WARNING| This board is suitable only for 2S (see [[http://www.rcgroups.com/forums/showpost.php?p=33480082&postcount=7004]]), with higher voltages it gets quite hot and may malfunction. Read also this: [[http://www.rcgroups.com/forums/showthread.php?t=2055844&page=144&pp=50#post33773254]]. The board can only be flashed with a ST-Link adapter via SWD, it cannot be flashed via the "usual" procedure. Many pins/ports are not available. Overall, this board cannot be recommended, except for special applications.}}}} <br />
<br clear="all" /><br />
<br />
=== GLB Mini STorM32 BGC ===<br />
----<br />
[[File:Sku 113113 1.jpg|thumb|caption|GLB Mini STorM32-BGC board with L6230 motor drivers]]<br />
{|<br />
|- valign="top"<br />
|width=300px|<br />
* MCU: STM32F103RC at 72 MHz<br />
* motor drivers: L6230<br />
* voltage regulator: switched step-down<br />
|<br />
* supply voltage: 7 - 25 V or 3 - 6S (according to the specs given by GLB, whatever this means)<br />
* motor current: 1.5 A (according to the specs given by GLB, whatever this means)<br />
* board dimensions: 42 mm x 30 mm, ? mm bolt to bolt, holes Ø? mm<br />
|}<br clear="all" /><br />
<br />
=== AliExpress Mini STorM32 BGC ===<br />
----<br />
[[File:Aliexpress-min-storm32.jpg|thumb|caption|AliExpress Mini STorM32-BGC board]]<br />
{|<br />
|- valign="top"<br />
|width=300px|<br />
* MCU: STM32F103RC at 72 MHz<br />
* motor drivers: DRV8313<br />
* voltage regulator: linear<br />
|<br />
* supply voltage: 7.4 - 16.8 V or 2 - 4S (according to the specs given by AE, whatever this means)<br />
* motor current: 1.5 A<br />
* board dimensions: 40 mm x 30 mm, 43 mm pitch ??, holes Ø2 mm<br />
|}<br />
<br />
{{COMMENT|{{WARNING|The info given on some pages is definitely wrong in some aspects.}}}} ''What we know so far (see also [http://www.rcgroups.com/forums/showpost.php?p=32058700&postcount=5525 here] and followup posts):''<br />
* DRV8313 motor drivers do not allow 2S operation<br />
* only the RC port is available<br />
* SBus is not supported<br />
* BT module cannot be installed on-board</div>OlliW