Custom Power Management Board for flight avionics

[NateLowrie]

Delving into a side project here. With our 2 stage flights coming up, accessing and arming av-bays that are positioned 10+ feet up on the airframe is not appealing. We have a few problems with our current setup that I would like to address and I think we can do it with one power management board that controls charging and power switching to components. This thread serves 2 purposes: it's a documentation thread for the project and a place to get feedback on the design coupled with testing to the point where I am confident it can 1) operate in a safe manner and 2) be able to meet Tripoli requirements for use at a launch. Feel free to tell me just how much of an idiot I am with the design as long as you propose an alternative that fixes the issue. Call me out in a constructive way because it's been about 10 years since I have done a non-trivial electronics project.

The inspiration for this is largely the Eggtimer WiFi switch. I love the concept and it solves a lot of problems but ends up being rather power hungry and it's cumbersome when you have to connect to 6 of them to turn things on. As with any well thought out project, here are the problems we are trying to solve and the main design goals.

The root problems:​

• When the av-bay is more than 5 feet in the air it is hard to climb up and arm the switches.
• Being on the ladder or hanging on the truss next to a sustainer with the igniter in arming avionics carries a non-zero amount of risk.
• It's impossible to know with the current system if the cameras are on. We want some feedback as to whether they are all on.
• We currently use Mag Switches. If we don't launch, they will drain the batteries enough over the next months and we will need to take the airframe apart to charge.

Design Goals:​

• Safety: NO Compromises
  • electrically isolated circuits and batteries for each altimeter for full stack redundancy.
  • separate switching hooking the battery into pyro channels (important when we are dealing with a sustainer igniter)
  • Be able to turn everything on wireless from the ground with an easily readable status
• Charging:
  • Separate batteries for backup altimeter and cameras (power hogs, don't want to drain the GPS battery either).
  • Ability to plug in an umbilical from outside the rocket that supplies charging power to charge the batteries.
  • Needs to be modal: You're either charging or in a power supply state
• Power Management
  • Components to switch power on and off to: Primary altimeter (with separate pyro control), backup altimeter (with separate pyro control), GPS Tracker, Cameras
  • Altimeters MUST remain on if the power management control board loses power/browns out/is unresponsive/resets/etc.
  • When each component is off, it draws zero current from the batteries.
  • Single screw switch that is accessible from outside the rocket to power the management board on and put it in a state to receive control commands.

I'll have some more detail including circuits tonight.

 

[cerving]

Delving into a side project here. With our 2 stage flights coming up, accessing and arming av-bays that are positioned 10+ feet up on the airframe is not appealing.

That's why we make WiFi switches...you can power on your avionics from a considerable distance. They do draw some current, of course, but if you insist on a battery switch you can use a pull-pin for each battery and pull it out when you have the rocket horizontally on the rail.

How about making the sled out of a G10 circuit board, and etching the various power traces into it? Sounds like a good use for OshPark to me...

 

[NTP2]

That's why we make WiFi switches...you can power on your avionics from a considerable distance. They do draw some current, of course, but if you insist on a battery switch you can use a pull-pin for each battery and pull it out when you have the rocket horizontally on the rail.

How about making the sled out of a G10 circuit board, and etching the various power traces into it? Sounds like a good use for OshPark to me...

or get a company to make some PCBs for you.

 

[Art Upton]

This part: "We currently use Mag Switches. If we don't launch, they will drain the batteries enough over the next months and we will need to take the airframe apart to charge."

If you don't launch that day, you should be taking the av-bay apart, inspect , and charge. Things can happen. Also never leave it outside...

I remember one launch at New Mexico Space Port X-Prize Cup, that simply was left overnight on the rail launcher. Needless to say it didn't eject when launched in the morning

Someplace on the old white tower I have a video of that , and the aftermath...

A few old timers on this board will remember that flight as well

 

[NTP2]

This part: "We currently use Mag Switches. If we don't launch, they will drain the batteries enough over the next months and we will need to take the airframe apart to charge."

just put a charge port on the outside get a cheap USB C power control bored From adafruit.

 

[Art Upton]

just put a charge port on the outside get a cheap USB C power control bored From adafruit.

No, other things can also happen over time. You should have inspected your electronics a reasonable time before the flight

 

[NateLowrie]

I put a charge port on the outside get a cheap USB C power control bored From adafruit.

This is certainly a possibility. Right now the Ravens are in power perches which makes the charger wiring slightly tricky. Are you mainly flying 2S lipos with a separate balance out?

That's why we make WiFi switches...you can power on your avionics from a considerable distance. They do draw some current, of course, but if you insist on a battery switch you can use a pull-pin for each battery and pull it out when you have the rocket horizontally on the rail.

How about making the sled out of a G10 circuit board, and etching the various power traces into it? Sounds like a good use for OshPark to me...

I have certainly thought about going this route and will probably end up going down this path initially, It’s a bit cumbersome because each switch only controls 1 output and when you have 2 stages each requiring multiple switches. It can be a checklist nightmare at the pad.

I am not sure where you are going with OshPark suggestion. The altimeters are Ravens and the GPS is a featherweight. I was planning on having them mount directly to the board and for the board to serve as an IO expander like the power perch does.

 

[NateLowrie]

This part: "We currently use Mag Switches. If we don't launch, they will drain the batteries enough over the next months and we will need to take the airframe apart to charge."

If you don't launch that day, you should be taking the av-bay apart, inspect , and charge. Things can happen. Also never leave it outside...

I remember one launch at New Mexico Space Port X-Prize Cup, that simply was left overnight on the rail launcher. Needless to say it didn't eject when launched in the morning

Someplace on the old white tower I have a video of that , and the aftermath...

A few old timers on this board will remember that flight as well

I would never leave it outside on a rail overnight. That’s just asking for trouble.

I also agree that you need to verify the electronics pass their systems checks. However, I don’t necessarily agree with needing to open everything up to do physical inspection. Here is our process:

• The days before a launch we do a final button up that includes bench checklists for all electronics. For the Ravens, we verify settings, ematch continuity, calibrate accelerometers and verify battery voltages. For the GPS, we power on and verify battery voltages, connection with the ground station, and proper signal when oriented vertical and aligned against a launch rail.
• On the pad we have additional standard checklists. For each blue raven, we do a verification of voltages, ematch continuity and system status. For the GPS, we verify battery voltages, ematch continuity, and system status.

Why wouldn’t the above process be enough? If our system health checks are without issue a physical inspection will not yield any additional data.

 

[VernK]

Power Management

• Components to switch power on and off to: Primary altimeter (with separate pyro control), backup altimeter (with separate pyro control), GPS Tracker, Cameras
• Altimeters MUST remain on if the power management control board loses power/browns out/is unresponsive/resets/etc.

It is certainly handy to have the power management system (PMS) able to power-off everything in a rocket when a launch needs to be scrubbed. However, once you give it that capability, I contend independent redundancy has been lost. There is now a single point failure mode that can cause both the primary and backup altimeters to fail to function. That being the PMS firmware. That firmware could malfunction and accidently turn off everything while in flight. All kinds of hardware interlocks could be designed in, but at the end of the day, if the firmware has the capability (somehow) to turn everything off, all by itself, then I think you have to consider that as a possible failure mode.

One possible work around is to not give the PMS the ability to turn-off the altimeters all by itself. Perhaps require a second, totally independent system, that must concur with the decision to turn everything off. That could be another independent wireless system, or perhaps just a physical switch. But a person would have to go flip the switch to power down everything if the launch is scrubbed. Therefore, make the switch some form of umbilical that detaches at liftoff and once detached, the PMS firmware cannot power down the avionics because the hardware interlocks will not allow it. This scheme with the umbilical retains the ability to scrub a launch and power everything down via the PMS without having to go flip a switch.

 

[cerving]

I am not sure where you are going with OshPark suggestion. The altimeters are Ravens and the GPS is a featherweight. I was planning on having them mount directly to the board and for the board to serve as an IO expander like the power perch does.

OshPark is a collective that makes cheap small-run PC boards, three is their minimum. You could make a sled out of a PC board, mount the altimeters to it, and have all of the connections go directly to the PC board. So yeah, it's like the Power Perch in that it simplifies the wiring.

 

[Art Upton]

I would never leave it outside on a rail overnight. That’s just asking for trouble.

I also agree that you need to verify the electronics pass their systems checks. However, I don’t necessarily agree with needing to open everything up to do physical inspection. Here is our process:

• The days before a launch we do a final button up that includes bench checklists for all electronics. For the Ravens, we verify settings, ematch continuity, calibrate accelerometers and verify battery voltages. For the GPS, we power on and verify battery voltages, connection with the ground station, and proper signal when oriented vertical and aligned against a launch rail.
• On the pad we have additional standard checklists. For each blue raven, we do a verification of voltages, ematch continuity and system status. For the GPS, we verify battery voltages, ematch continuity, and system status.

Why wouldn’t the above process be enough? If our system health checks are without issue a physical inspection will not yield any additional data.

Just an Add-On, the one left on the rail passed the system checks , beeps etc.
We did not have WiFi altimeters to check further things back in 2007

If you store this for 'months' ready-to-go, environmental things might cause issues you may not be aware of without a visual check. A wire even could start squeaking out a terminal slightly that a physical check would see.

Or a power wire could start looking 'black' on the non-insulated part. Black wire disease plagued R/C planes left connected to power, even with the power off. I'm not sure of the prevalence of something similar in LiPo packs now, but it even happens on truck trailer wiring over the winter sometimes.

I would assume you take the un-used energetics out before storage, I assume you do but had to ask...

 

[NateLowrie]

Just an Add-On, the one left on the rail passed the system checks , beeps etc.
We did not have WiFi altimeters to check further things back in 2007

If you store this for 'months' ready-to-go, environmental things might cause issues you may not be aware of without a visual check. A wire even could start squeaking out a terminal slightly that a physical check would see.

Or a power wire could start looking 'black' on the non-insulated part. Black wire disease plagued R/C planes left connected to power, even with the power off. I'm not sure of the prevalence of something similar in LiPo packs now, but it even happens on truck trailer wiring over the winter sometimes.

I would assume you take the un-used energetics out before storage, I assume you do but had to ask...

We always remove unused energetics before storage. Did they ever determine a root cause for the altimeters not functioning as designed?

 

[NateLowrie]

It is certainly handy to have the power management system (PMS) able to power-off everything in a rocket when a launch needs to be scrubbed. However, once you give it that capability, I contend independent redundancy has been lost. There is now a single point failure mode that can cause both the primary and backup altimeters to fail to function. That being the PMS firmware. That firmware could malfunction and accidently turn off everything while in flight. All kinds of hardware interlocks could be designed in, but at the end of the day, if the firmware has the capability (somehow) to turn everything off, all by itself, then I think you have to consider that as a possible failure mode.

One possible work around is to not give the PMS the ability to turn-off the altimeters all by itself. Perhaps require a second, totally independent system, that must concur with the decision to turn everything off. That could be another independent wireless system, or perhaps just a physical switch. But a person would have to go flip the switch to power down everything if the launch is scrubbed. Therefore, make the switch some form of umbilical that detaches at liftoff and once detached, the PMS firmware cannot power down the avionics because the hardware interlocks will not allow it. This scheme with the umbilical retains the ability to scrub a launch and power everything down via the PMS without having to go flip a switch.

That is a valid point. I would trade the inconvenience of plugging in an umbilical on a scrubbed launch (a rare event) for assurance that things cannot be turned off. We could achieve this by latching the power supply on and having a separate reset.



This is the initial schematic for the power output circuitry. The goals for this part of the circuit:

• The PMS can turn on the power to an altimeter by setting a pin HIGH on a microcontroller but cannot turn it off.
• The PMS circuitry is electrically isolated from the Altimeter circuit.
• A separate reset pin is used to turn the stack off. This pin is not controlled by the PMS but rather the plugging in of an external umbilical.

It's a variation of a pretty standard low side soft latching Mosfet switch. How the circuit works:

• When the circuit is initially powered, all transistors are initially OFF. The Q1 P-Channel MOSFET controls the output to the altimeter by creating the current path from IN to OUT.
• The main controller component is the Q3 BJT transistor. When the ControlAltimeter1Pin from the PMS goes HIGH, it connects R8 to the base of Q3 through Optocoupler U1. Since R8 is a pull-up resistor tied to the input, this action turns ON the Q3 transistor. With Q3 ON, it activates the Q1 Mosfet by creating a path to ground from the gate of the Q1 MOSFET. Because Q1 is a P-channel MOSFET, grounding its gate turns it ON, enabling the output.
• The output remains latched ON even if the ControlAltimeter1Pin pin goes LOW. This happens because the circuit’s output is fed back to the base of Q3 via a 100kΩ resistor, keeping Q3 ON and sustaining the output. Once the circuit is turned ON, the state of ControlAltimeter1Pin doesn't have any effect on the circuit.
• To turn the circuit OFF, we use the Q4 BJT transistor. Activating Q4 connects the base of Q3 to ground, turning OFF Q3. This disables Q5, which removes the ground path from the gate of the P-MOSFET, turning OFF Q1 and the entire circuit.
• When the ResetAltimeter1Pin goes HIGH, it connects R12 to the base of Q4 through Optocoupler U1. This action turns ON Q4, which in turn shuts down the circuit by disabling Q3. The C3 capacitor provides a small delay to stabilize the ON/OFF transitions.

The 2 advantages to using the charge umblical to turn off the circuits: 1) the recovery team just needs to take a spare power bank and insert it into the umbilical port to turn off all the devices and 2) if the umbicial is inserted and charging this ensures all the devices are off when charging.

 

[StreuB1]

An electronic latch has some issues with it in that you have the potential for your reset line to fail and now you have something latched that cannot be unlatched.

I would suggest what we do in machine safety circuits in that you have a mechanical NO contact held closed as the absolute failsafe. In all actuality, several NO contacts in series would be better to provide redundancy. The loss of voltage on the interlock line breaks the latch and then locks the latch out preventing a relatch without a reset.

Have used high quality 3-ring 1/8" phono plugs in the past to provide offline power and also act as the failsafe interlock as they can also act as a switch depending on the configuration of the barrel contacts in the jack. Once you provide a loss of offline power AND then the phono plug gets pulled, then you are reasonably assured that the rocket is armed and then away. If either is an XOR, then you have had a failure and then the latch drops out and then gets locked out by the phono jack; hardware interrupt holds MCU in reset.

I agree with Vern in that firmware can fail in the most bizarre ways at times so you always want a mechanical fallback OR parallel processors that all vote. The initial is much easier to implement.

 

[StreuB1]

Without going into too much detail. A project I am working on uses a phono plug that puts the rocket avionics in a standby mode. It allows power to make it to one of Adrians mag switches. This mag switch powers up one of Cris' mini wifi switches....or more. This then allows the remote power up of the avionics which then come online and can be configured and monitored remotely.

The phono plug is inserted at the pad, once the rocket is ready and the rocket is ready to be left at the pad, the magnet is swiped to bring the wifi switch online. The wifi switch is checked via mobile device. The pad is then vacated. Once at distance, the wifi switch(s) output is toggled on which then powers up the avionics and the rest is history.

There is a PIC micro which has a CLC and that handles the simple combinational logic of lockout hierarchy. It could also be done with simple 7400 logic but a single PIC with its CLC does it all with a single component.

 

[VernK]

A separate reset pin is used to turn the stack off. This pin is not controlled by the PMS but rather the plugging in of an external umbilical.

I assume you realize this, but I will mention it just for completeness. You don’t want one pin to power down everything. Otherwise, a single point failure turns off both the primary and backup altimeters. Wouldn’t want that failure to occur during flight. Probably best to keep the resets completely seperate and totally independent with no shared connections.

 

[tfischer]

This is the initial schematic for the power output circuitry. The goals for this part of the circuit:

Good discusssion, watching this thread with interest.

Getting back to your root problem of high magnetic switch leakage (off state) power: what is your system's leakage power target, and does this switch circuit have significantly lower leakage than the magnetic switch?

 

[NateLowrie]

First, thanks for all the suggestions. This was the kind of thread I was hoping for when I started it. Keep them coming.

I will go with a mechanical lockout for now as it's simpler and less hardware-intensive to implement. Here's an update on the schematic. To turn off the latch, we'll put a screw switch in series with the battery connection. That will full cut power and upon power-up the latch will be reset. It actually made the schematic simpler because it doesn't require a second BJT.



The next step is to add the lockout circuitry for the pyro channels. Because we want to use this on a sustainer in a 2-stage, I want latching control circuitry to be able to keep the e-match connections open until the PMS signal comes, at which point they would latch closed.

The order of operations at the pad would be:

1. When the rocket is horizontal on the rail, turn on PMS via the screw switch.
2. Verify PMS operation is nominal and all peripherals control pins are held low.
3. For each alimeter, turn on the screw switch. At this point, no power should be flowing to the altimeter.
   1. If the altimeter powers up and starts going through it's startup cycle, power off immediately, abort the launch, and remove the rocket to troubleshoot.
4. Raise rail.
5. Turn on the altimeter through PMS.
6. Verify startup on the featherweight app.
7. Enable Pyro channels through the PMS. Verify connectivity and voltage through the featherweight app.

 

[VernK]

To turn off the latch, we'll put a screw switch in series with the battery connection.

The order of operations at the pad would be: …. 7. Enable Pyro channels through the PMS.

Won’t the screw switches make things more tricky to safely scrub a launch? Won’t you have to lower the rocket back down to horizontal with all the altimeters still powered-up to access the screw switches? Since you have this fancy PMS controller, it seems a shame not to be able to power things down with it to scrub a launch.

You mentioned “enable pyro channels through the PMS.” What is that all about? Just like with the power up situation, you would want to make sure the PMS cannot malfunction and disable all the pyro channels during flight.