Project Years: 2025-2026
Contributors: Joshua Sumaylo, Matthew Thomson, Sovereign Shahid, Shenura Mendis, Brian Lin
Altium365 Project: https://americas-starr-university-of-alberta.365.altium.com/designs/F7915BDE-4677-4D5E-B6EA-360A3CBAE0B4
Github Repo: UASTARR/Wireless-Arming-Switch (STM32 Code) and UASTARR/wasabi and UASTARR/wireless-arming-app (arming apps)
The Wireless Arming Switch V1 is a descendent of the GPS Power Distribution Board. It uses the same STM32WB15CCU microcontroller to act as a way to wirelessly arm or disarm COTS components over Bluetooth Low Energy. However, it uses high continuous current MOSFETs that let it be used to provide power to altimeters which may consume multiple amps when firing. For Albireo, it is only used to remotely arm the second stage ignitor from a safe distance. For the sake of redundancy, there are two independently developed arming applications.
The op-amp chosen to buffer the MCU’s ADC had a very poor maximum output voltage compared to the supply rails, which meant we needed to change the input voltage divider ratio to limit the maximum output voltage.
Additionally, we had to use EEPROM emulation because a dedicated EEPROM IC was missed in the design. EEPROM emulation should be avoided AT ALL COSTS because the STM32-provided code is riddled with bugs.
Despite “working”, we should hardly consider the V1 WAS a success of engineering design. The requirements were not enforced or directly tested against. Testing was only surface level, testing whether the WAS could withstand simple power failures and dropped Bluetooth connections. Testing should have probed all possible failures, including artificially inducing hard faults to ensure the code does not get caught in any infinite loops. There is a lot to be learned in designing extremely reliable flight critical code.
Finally, zero work was done to add power saving. While the radio must always be on to receive Bluetooth commands, the main core of the microcontroller can be put into a sleep mode to save more power. The main issue is actually fighting the STM32 middleware code. It’s actually an incredible mess.
The V1 WAS was a good attempt, but in the end it needed more testing and stricter adherence to its design requirements. A second iteration of the WAS should focus on improving the ADC buffer, adding an EEPROM, greatly expanding the suite of software tests, and adding power saving. Future designs don’t have to be married to the STM32 ecosystem either. A good option might be to explore chips from Nordic Semiconductor.