The 2025 - 2026 ERS firmware specification doc describes a truth table to map Hall sensor readings to lock ring position. It also describes a set of lock ring states used to determine the drogue board's and main chute board's current state variable to indicate "Rocket ready", as in ready to launch. The set of ring positions are a superset of lock ring states. Lock ring positions have two additional states or named elements which more finely qualify the ring being in its locked position and in its unlocked position.
Is this necessary? The code is more complex for supporting these two very similar sets of states. The two sets of states are implemented in the Zephyr based firmware as C enumerations. The ring position enum has elements whose names all begin with RING_POS_. This is self-documenting, or close to it, and intuitive to understand what is being numbered. The lock ring state enumeration has elements whose names all begin with RING_STATE_. This is a little less clear, because "state" is an abstract idea.
Given that the spec document implies or leaves no clear other implementation to mapping ring positions "locked" and "locked fully qualified" to a single ring state, and same for unlocked positions, do we actually need both these enumerable lock ring sets of states?
The 2025 - 2026 ERS firmware specification doc describes a truth table to map Hall sensor readings to lock ring position. It also describes a set of lock ring states used to determine the drogue board's and main chute board's current state variable to indicate "Rocket ready", as in ready to launch. The set of ring positions are a superset of lock ring states. Lock ring positions have two additional states or named elements which more finely qualify the ring being in its locked position and in its unlocked position.
Is this necessary? The code is more complex for supporting these two very similar sets of states. The two sets of states are implemented in the Zephyr based firmware as C enumerations. The ring position enum has elements whose names all begin with
RING_POS_. This is self-documenting, or close to it, and intuitive to understand what is being numbered. The lock ring state enumeration has elements whose names all begin withRING_STATE_. This is a little less clear, because "state" is an abstract idea.Given that the spec document implies or leaves no clear other implementation to mapping ring positions "locked" and "locked fully qualified" to a single ring state, and same for unlocked positions, do we actually need both these enumerable lock ring sets of states?