Fixing CAM Brownouts: A Power-Up Delay Solution

Experiencing CAM brownouts? During testing of the CAM system, a critical issue has been identified where the CAM would reset or completely die when attempting to power on both cameras and the Video Transmitter (VTX) simultaneously. This article explores the root cause of this problem and details a proposed solution involving a power-up delay.

Understanding the CAM Brownout Issue

The CAM brownout issue manifests as a system failure, specifically, the CAM resetting or shutting down entirely during the activation of cameras and the VTX. Interestingly, when these devices are powered on in a staggered sequence, the system operates flawlessly. This behavior strongly suggests that the root cause lies in a high inrush current. Inrush current, for those not in the know, is the instantaneous high input current drawn by an electrical device when it is first turned on.

In this particular setup, the VTX seems to be the primary culprit. Why? Because it's the only component that has been changed since the system was successfully running on Aether II. The VTX likely demands a significant surge of current upon startup, and when combined with the cameras' inrush current, it overloads the system. This overload leads to a voltage drop, causing the dreaded brownout and subsequent system failure. It’s like trying to start too many appliances at once and tripping a breaker – but in this case, the breaker is the CAM system itself.

The Proposed Solution: Power-Up Delay Implementation

To mitigate the CAM brownout problem, the proposed solution is to introduce a carefully calibrated delay between the power-up sequences of the cameras and the VTX. This delay ensures that the inrush currents of these devices do not overlap, preventing the combined current demand from exceeding the capabilities of the onboard power supply or batteries. Think of it as staggering the start times of those power-hungry appliances to avoid tripping that breaker.

The specific order of activation – whether to power up the cameras before the VTX or vice versa – will be determined through rigorous testing. The goal is to identify the sequence that minimizes the peak current draw during startup. This might involve measuring the current profiles of each device during power-up to determine which one exhibits a more significant inrush.

This approach aims to reduce the instantaneous power demand, keeping the system within its operational limits and preventing the voltage drops that trigger the brownout. By strategically delaying the activation of one set of devices, we can effectively manage the overall current load and ensure stable system operation.

Software Changes for CAMON Command and State Restoration

The CAM brownout bug isn't just a one-off occurrence; it surfaces in multiple scenarios. Specifically, it happens when the system restores its previous state during startup and also when the board receives the CAMON command, which is designed to turn on all connected devices simultaneously. This means that the fix needs to be comprehensive and address all potential triggers of the issue.

Therefore, the proposed solution requires modifications to the software to handle both scenarios:

• State Restoration on Startup: When the system boots up, it often attempts to restore the devices to their previous states, as saved in the onboard EEPROM (Electrically Erasable Programmable Read-Only Memory). The software needs to be modified to incorporate the power-up delay during this restoration process. Instead of blindly activating all devices based on their stored states, it should intelligently sequence the power-up, introducing the necessary delay between the cameras and the VTX.
• CAMON Command Execution: The CAMON command, which is received from MIDAS (presumably a control system), explicitly instructs the CAM board to turn on all connected devices. The software handling this command must be updated to implement the power-up delay. Upon receiving the CAMON command, the system should not immediately activate all devices. Instead, it should follow a pre-determined sequence, activating either the cameras or the VTX first, followed by the other after the specified delay.

These software changes are critical for ensuring that the power-up delay is consistently applied, regardless of how the system is being initialized or controlled. Without these modifications, the brownout issue would persist, undermining the effectiveness of the hardware-level solution.

Key Functions Involved

The software modifications will primarily focus on two key functions within the CamBoard firmware. These functions are responsible for managing the state of the cameras and related devices, and therefore, are the logical places to implement the power-up delay.

1. update_desired_state

This function, located in src/hardware/main.cpp within the CamBoard firmware, plays a crucial role in restoring the CAM state from the onboard EEPROM. When the system starts up, update_desired_state is called to retrieve the previously saved states of the cameras and other connected devices. It then attempts to set these devices to their desired states. This is where the brownout issue can arise if the cameras and VTX are both set to the "on" state simultaneously, leading to the inrush current overload.

The proposed solution involves modifying the update_desired_state function to incorporate the power-up delay. Instead of directly activating the devices based on their stored states, the function should now implement a sequence. It would first power on either the cameras or the VTX, and then, after a pre-defined delay, power on the other device. This staggered approach would prevent the simultaneous inrush currents and mitigate the risk of a brownout.

The specific implementation within update_desired_state would likely involve using a timer or a delay function to pause execution between the activation of the two sets of devices. The duration of this delay would be a critical parameter that needs to be carefully calibrated through testing to ensure reliable operation without introducing excessive startup time.

Here's how you might think about the changes to this function:

1. Read Desired States: The function still starts by reading the desired states of all devices from the EEPROM.
2. Implement Delay: Instead of immediately setting all devices to their desired states, the function now checks if both the camera and VTX are supposed to be ON.
3. Stagger Power-Up: If both are ON, it powers up one (either camera or VTX), waits for the defined delay period, and then powers up the other.
4. Handle Individual States: If only one device is supposed to be ON, it powers that device up immediately, without any delay.

2. onReceive

The onReceive function, also located in src/hardware/main.cpp, is responsible for handling commands received from the MIDAS system. These commands can include instructions to change the state of the cameras and other connected devices. Notably, the CAMON command, which instructs the CamBoard to turn on all connected devices, is processed by this function.

Similar to update_desired_state, the onReceive function needs to be modified to incorporate the power-up delay. When the CAMON command is received, the function should not immediately activate all devices. Instead, it should follow the same staggered approach as described above, activating either the cameras or the VTX first, followed by the other after a specified delay.

The modifications to onReceive would mirror those made to update_desired_state, ensuring consistency in how the power-up delay is applied across different scenarios. This consistency is crucial for preventing the brownout issue, regardless of whether the system is being initialized from stored states or being controlled via external commands.

Here's a breakdown of how the onReceive function would be updated:

1. Receive and Parse Command: The function starts by receiving and parsing the command from MIDAS.
2. Check for CAMON: It then checks if the received command is the CAMON command.
3. Implement Delay for CAMON: If it is the CAMON command, the function implements the staggered power-up sequence, activating either the camera or VTX first, waiting for the defined delay period, and then activating the other.
4. Handle Other Commands: For other commands, the function executes them as normal, without any delay.

By modifying these two key functions, the CamBoard firmware can effectively mitigate the CAM brownout issue, ensuring stable and reliable operation of the system.

Conclusion

The CAM brownout issue, characterized by system resets or shutdowns during camera and VTX activation, stems from high inrush currents. The proposed solution, involving a power-up delay between device activation, promises to mitigate this problem. Software modifications to the update_desired_state and onReceive functions are crucial for ensuring consistent and reliable operation. By implementing these changes, the CAM system can avoid excessive current demands, preventing voltage drops and ensuring stable performance.

For more information on inrush current and power management, check out this resource: Power Management Basics