I was fascinated by Lou's talk at the Symposium. His idea of a "parallel" power system is an excellent one if a few potential problems can be addressed.
The first and most obvious one is efficiency. Switching converters tend to be much less efficient at low voltages and high currents, though power MOSFETs have gotten very good of late. Every Pentium 4 motherboard has had a DC-DC converter that takes 12V and produces ~1V at up to 100A to power the CPU. The fact that there isn't a massive heat sink and fan for the supply as well as the CPU says that these converters can't be too terribly inefficient. I'll be interested in some actual figures for the "virtual battery" converters.
The second issue is robustness. Just as serial architectures are vulnerable to single-point open faults, parallel architectures are potentially vulnerable to single-point shorting faults, e.g., of the power transistors and diodes in the converter. I'm hoping a judicious application of fuses can take care of this.
Super caps look very promising thanks to their claimed long cycle lives, but I wonder about their radiation robustness. Imagine what a highly energetic, totally ionized particle might do as it rips through the Aerogel holding large numbers of electrons a few microns apart from large numbers of holes. Have any radiation tests been performed on these things?
Also, I would not take their cycle life claims as gospel without some tests to back them up. Electrolytic caps have become some of the most unreliable components in electronics today. They fail on a regular basis in computer power supplies and motherboards, often spectacularly.
While super caps aren't built quite the same way, both kinds of caps achieve their high capacities with lots of extremely thin dielectric material. Cycling the cap must place some pretty serious electrostatic compression stresses across this material. What happens, e.g., after many cycles at very low temperatures?
At a system level, I see a potential "gotcha" with multiple paralleled virtual battery units. You can never get multiple voltage references to exactly agree, so if the control loop gains are too high, then one virtual battery might think the bus voltage is a little too low when another might think it's too high. Then you'll have large amounts of current flowing from one virtual battery into another, obviously an undesirable situation.
The simplest fix I can think of is to program the control logic in each virtual battery to follow a specified current vs voltage characteristic. The slope of this curve must be gentle enough so that small differences in reference voltages across the units will not produce significantly different I/V curves. Bus regulation won't be quite as tight, but hopefully the loads won't mind.
Overall I think Lou's proposed architecture is an excellent idea, and with attention to a few details it should be a lot more reliable than the conventional power systems we've had in the past.
--Phil
Phil: Good comments.
One response: The situation you describe regarding load sharing between multiple parallel sources, without oscillations and circulating currents, is no different than the situation where there are multiple AC generators operating in parallel. In that case, the speed governor (which sets frequency) has a frequency vs load characteristic that is not flat. This forces stable real load sharing, even when generators of different capacity are paralleled. Similarly, the voltage regulator has a non-flat voltage vs. reactive load characteristic. This forces stable sharing of reactive load.
Bottom line: I think we can deal with this issue.
Thanks & 73, jim [email protected]
Phil Karn wrote:
I was fascinated by Lou's talk at the Symposium. His idea of a "parallel" power system is an excellent one if a few potential problems can be addressed.
The first and most obvious one is efficiency. Switching converters tend to be much less efficient at low voltages and high currents, though power MOSFETs have gotten very good of late. Every Pentium 4 motherboard has had a DC-DC converter that takes 12V and produces ~1V at up to 100A to power the CPU. The fact that there isn't a massive heat sink and fan for the supply as well as the CPU says that these converters can't be too terribly inefficient. I'll be interested in some actual figures for the "virtual battery" converters.
The second issue is robustness. Just as serial architectures are vulnerable to single-point open faults, parallel architectures are potentially vulnerable to single-point shorting faults, e.g., of the power transistors and diodes in the converter. I'm hoping a judicious application of fuses can take care of this.
Super caps look very promising thanks to their claimed long cycle lives, but I wonder about their radiation robustness. Imagine what a highly energetic, totally ionized particle might do as it rips through the Aerogel holding large numbers of electrons a few microns apart from large numbers of holes. Have any radiation tests been performed on these things?
Also, I would not take their cycle life claims as gospel without some tests to back them up. Electrolytic caps have become some of the most unreliable components in electronics today. They fail on a regular basis in computer power supplies and motherboards, often spectacularly.
While super caps aren't built quite the same way, both kinds of caps achieve their high capacities with lots of extremely thin dielectric material. Cycling the cap must place some pretty serious electrostatic compression stresses across this material. What happens, e.g., after many cycles at very low temperatures?
At a system level, I see a potential "gotcha" with multiple paralleled virtual battery units. You can never get multiple voltage references to exactly agree, so if the control loop gains are too high, then one virtual battery might think the bus voltage is a little too low when another might think it's too high. Then you'll have large amounts of current flowing from one virtual battery into another, obviously an undesirable situation.
The simplest fix I can think of is to program the control logic in each virtual battery to follow a specified current vs voltage characteristic. The slope of this curve must be gentle enough so that small differences in reference voltages across the units will not produce significantly different I/V curves. Bus regulation won't be quite as tight, but hopefully the loads won't mind.
Overall I think Lou's proposed architecture is an excellent idea, and with attention to a few details it should be a lot more reliable than the conventional power systems we've had in the past.
--Phil
Via the Eagle mailing list courtesy of AMSAT-NA [email protected] http://amsat.org/mailman/listinfo/eagle
Jim Sanford wrote:
The situation you describe regarding load sharing between multiple parallel sources, without oscillations and circulating currents, is no different than the situation where there are multiple AC generators operating in parallel. In that case, the speed governor (which sets frequency) has a frequency vs load characteristic that is not flat. This forces stable real load sharing, even when generators of different capacity are paralleled. Similarly, the voltage regulator has a non-flat voltage vs. reactive load characteristic. This forces stable sharing of reactive load.
I'm not sure this is the exact same situation. A generator is not a stored energy device (ignoring flywheel effects). It can't produce more electrical power out than the mechanical power going in. A battery or cap, on the other hand, can produce almost arbitrarily large powers until it is depleted.
I agree, this is all manageable.
My thoughts on this comes from experience with related problems in home photovoltaic power systems.
In the late 1990s, the Trace SW4048/5548 inverter models were very popular. These 4/5.5 kVA inverters are bidirectional; power can flow from the AC side to the 48V DC side as well as from the DC side to the AC side. This is useful in maintaining a battery bank at a constant voltage despite varying PV production and DC load, but it also led to problems in systems with more than one unit.
Two inverters are commonly used in larger (e.g., 5kW) grid-tied systems. They were typically wired in parallel on the DC side and connected to opposite 120V phases on the AC side.
Even if you set both inverters to the same "sell" voltage on their DC side, small differences in their internal voltage references often result in very different inverter power levels. You could even see one inverter "buying" (converting AC to DC) while the other "sold" (converting DC to AC), obviously a wasteful situation. This problem could have been easily avoided with a small dead band around the DC operating setpoint. This could also shut down the inverter at night, avoiding its idle power consumption.
Another problem comes from the use of a PV charge controller with this inverter. In a grid tied PV system, the charge controller is basically a safety device that protects the battery against an inverter or grid failure. Normally you always want maximum power from the PV array because the grid is an infinite energy sink and we can sell whatever we produce. During an outage or failure, though, we have to back off PV production to match local consumption. It does this whenever the battery bus voltage rises above a set point.
But the inverter is also trying to control the DC bus voltage. If you don't set them both up carefully, the charge controller could shut down the array unnecessarily. Again, an inverter dead band would have been very useful.
The bottom line is that all the devices on the DC bus must somehow coordinate their operation. If they communicate implicitly through DC bus voltage, then they need to agree on just what is meant by every possible value of bus voltage.
--Phil
Phil, You comments are excellent and are well taken. As you say this has to be managed. One of the ways we planned to manage the system is to have deadbands on the buss voltage. Another way is to have a simple way that the units can communicate to each other as to their state. I have also been thinking of using a common system such as the IHU to send out a number which is it's opinion as to the voltage of the bus. That way all units on the line would have a value to check against their measurement. That would provide a reference for all to use. Of course this needs to be discussed more to flush out various situations. I am planning to bring a small team together to put together an interface specification or protocol for this power system. Perhaps you could participate on that team and lend your valuable expertise and experience.
I will be traveling the rest of today.
Lou McFadin W5DID [email protected]
On Oct 11, 2006, at 9:19 AM, Phil Karn wrote:
Jim Sanford wrote:
The situation you describe regarding load sharing between multiple parallel sources, without oscillations and circulating currents, is no different than the situation where there are multiple AC generators operating in parallel. In that case, the speed governor (which sets frequency) has a frequency vs load characteristic that is not flat. This forces stable real load sharing, even when generators of different capacity are paralleled. Similarly, the voltage regulator has a non-flat voltage vs. reactive load characteristic. This forces stable sharing of reactive load.
I'm not sure this is the exact same situation. A generator is not a stored energy device (ignoring flywheel effects). It can't produce more electrical power out than the mechanical power going in. A battery or cap, on the other hand, can produce almost arbitrarily large powers until it is depleted.
I agree, this is all manageable.
My thoughts on this comes from experience with related problems in home photovoltaic power systems.
In the late 1990s, the Trace SW4048/5548 inverter models were very popular. These 4/5.5 kVA inverters are bidirectional; power can flow from the AC side to the 48V DC side as well as from the DC side to the AC side. This is useful in maintaining a battery bank at a constant voltage despite varying PV production and DC load, but it also led to problems in systems with more than one unit.
Two inverters are commonly used in larger (e.g., 5kW) grid-tied systems. They were typically wired in parallel on the DC side and connected to opposite 120V phases on the AC side.
Even if you set both inverters to the same "sell" voltage on their DC side, small differences in their internal voltage references often result in very different inverter power levels. You could even see one inverter "buying" (converting AC to DC) while the other "sold" (converting DC to AC), obviously a wasteful situation. This problem could have been easily avoided with a small dead band around the DC operating setpoint. This could also shut down the inverter at night, avoiding its idle power consumption.
Another problem comes from the use of a PV charge controller with this inverter. In a grid tied PV system, the charge controller is basically a safety device that protects the battery against an inverter or grid failure. Normally you always want maximum power from the PV array because the grid is an infinite energy sink and we can sell whatever we produce. During an outage or failure, though, we have to back off PV production to match local consumption. It does this whenever the battery bus voltage rises above a set point.
But the inverter is also trying to control the DC bus voltage. If you don't set them both up carefully, the charge controller could shut down the array unnecessarily. Again, an inverter dead band would have been very useful.
The bottom line is that all the devices on the DC bus must somehow coordinate their operation. If they communicate implicitly through DC bus voltage, then they need to agree on just what is meant by every possible value of bus voltage.
--Phil
Via the Eagle mailing list courtesy of AMSAT-NA [email protected] http://amsat.org/mailman/listinfo/eagle
On Wed, 2006-10-11 at 09:41 -0700, Louis McFadin wrote:
One of the ways we planned to manage the system is to have deadbands on the buss voltage. Another way is to have a simple way that the units can communicate to each other as to their state.
As we've discussed, this all needs to be designed very carefully, and deserves careful review by a broad team. Adding another bus of some type to pass state information around between the various power management devices seems attractive, but the more I've thought about it the more I think we should try to minimize the amount of shared state information and complexity. If we can do it all with voltages on the DC bus and suitable dead band definitions, that seems like a big win to me. I'm certainly open to being convinced otherwise, though!
I have also been thinking of using a common system such as the IHU to send out a number which is it's opinion as to the voltage of the bus.
That's an interesting thought. The immediate difficulty I see is how all these devices would be connected to the IHU... putting a CAN controller on each certainly seems to be driving the complexity equation the wrong way, and yet we really don't have any other communications path to/from the IHU. Perhaps some intermediate flavor where there's an overall power management controller coordinating all these little devices and interacting with the IHU makes sense, but keeping each of the little units completely independent may be lower risk overall?
Bdale
OK, I've been quiet. Now for my two cents worth.
If the individual power units need information from each other, then we loose the advantage of separate units and may as well do it the "old" way.
I think each unit needs a CAN-Do if for no other reason than to gather telemetry about what that unit is doing and the state of the batteries (or whatever the storage technology) it manages. The IHU could provide input over the CAN bus this way as well, but I very much dislike the idea of *any* computer being involved in the power management system.
I don't think we should carry this distributed system to an extreme (one cell per unit) but should have a smaller number of units each managing a string of batteries. Perhaps 4 to 8 units total.
Chuck
Bdale Garbee wrote:
On Wed, 2006-10-11 at 09:41 -0700, Louis McFadin wrote:
One of the ways we planned to manage the system is to have deadbands on the buss voltage. Another way is to have a simple way that the units can communicate to each other as to their state.
As we've discussed, this all needs to be designed very carefully, and deserves careful review by a broad team. Adding another bus of some type to pass state information around between the various power management devices seems attractive, but the more I've thought about it the more I think we should try to minimize the amount of shared state information and complexity. If we can do it all with voltages on the DC bus and suitable dead band definitions, that seems like a big win to me. I'm certainly open to being convinced otherwise, though!
I have also been thinking of using a common system such as the IHU to send out a number which is it's opinion as to the voltage of the bus.
That's an interesting thought. The immediate difficulty I see is how all these devices would be connected to the IHU... putting a CAN controller on each certainly seems to be driving the complexity equation the wrong way, and yet we really don't have any other communications path to/from the IHU. Perhaps some intermediate flavor where there's an overall power management controller coordinating all these little devices and interacting with the IHU makes sense, but keeping each of the little units completely independent may be lower risk overall?
Bdale
Via the Eagle mailing list courtesy of AMSAT-NA [email protected] http://amsat.org/mailman/listinfo/eagle
Louis McFadin wrote:
As you say this has to be managed. One of the ways we planned to manage the system is to have deadbands on the buss voltage. Another way is to have a simple way that the units can communicate to each other as to their state.
Right. The units have to communicate, and this can be done either explicitly, or implicitly through the DC bus voltage. I've gone back and forth on this myself, and I think the implicit scheme is preferable if it can be made to work reliably.
I have also been thinking of using a common system such as
the IHU to send out a number which is it's opinion as to the voltage of the bus. That way all units on the line would have a value to check against their measurement. That would provide a reference for all to use. Of course this needs to be discussed more to flush out various situations.
That's an interesting idea I hadn't thought of. But anything like this used for current control would have to be very fast to maintain bus regulation and avoid large transient currents when things change rapidly. Passive module monitoring for telemetry purposes wouldn't have to be nearly as fast.
--Phil
On Oct 11, 2006, at 3:28 PM, Bdale Garbee wrote:
On Wed, 2006-10-11 at 09:41 -0700, Louis McFadin wrote:
One of the ways we planned to manage the system is to have deadbands on the buss voltage. Another way is to have a simple way that the units can communicate to each other as to their state.
As we've discussed, this all needs to be designed very carefully, and deserves careful review by a broad team. Adding another bus of some type to pass state information around between the various power management devices seems attractive, but the more I've thought about it the more I think we should try to minimize the amount of shared state information and complexity. If we can do it all with voltages on the DC bus and suitable dead band definitions, that seems like a big win to me. I'm certainly open to being convinced otherwise, though!
I am with you on this. However I also believe it's good to have additional data exchanged between the units.
I have also been thinking of using a common system such as the IHU to send out a number which is it's opinion as to the voltage of the bus.
That's an interesting thought. The immediate difficulty I see is how all these devices would be connected to the IHU... putting a CAN controller on each certainly seems to be driving the complexity equation the wrong way, and yet we really don't have any other communications path to/from the IHU. Perhaps some intermediate flavor where there's an overall power management controller coordinating all these little devices and interacting with the IHU makes sense, but keeping each of the little units completely independent may be lower risk overall?
Bdale
I am thinking the we may need to have a power control module just for that purpose. There needs to be some way for the IHU to communicate with the power system even if we make it start up autonomously.
Lou: Is it time to write a strawman concept proposal & get people to review some specific proposals? Or do we need to wait on the results of your experiments?
73,JIm
Louis McFadin wrote:
On Oct 11, 2006, at 3:28 PM, Bdale Garbee wrote:
On Wed, 2006-10-11 at 09:41 -0700, Louis McFadin wrote:
One of the ways we planned to manage the system is to have deadbands on the buss voltage. Another way is to have a simple way that the units can communicate to each other as to their state.
As we've discussed, this all needs to be designed very carefully, and deserves careful review by a broad team. Adding another bus of some type to pass state information around between the various power management devices seems attractive, but the more I've thought about it the more I think we should try to minimize the amount of shared state information and complexity. If we can do it all with voltages on the DC bus and suitable dead band definitions, that seems like a big win to me. I'm certainly open to being convinced otherwise, though!
I am with you on this. However I also believe it's good to have additional data exchanged between the units.
I have also been thinking of using a common system such as the IHU to send out a number which is it's opinion as to the voltage of the bus.
That's an interesting thought. The immediate difficulty I see is how all these devices would be connected to the IHU... putting a CAN controller on each certainly seems to be driving the complexity equation the wrong way, and yet we really don't have any other communications path to/from the IHU. Perhaps some intermediate flavor where there's an overall power management controller coordinating all these little devices and interacting with the IHU makes sense, but keeping each of the little units completely independent may be lower risk overall?
Bdale
I am thinking the we may need to have a power control module just for that purpose. There needs to be some way for the IHU to communicate with the power system even if we make it start up autonomously.
Via the Eagle mailing list courtesy of AMSAT-NA [email protected] http://amsat.org/mailman/listinfo/eagle
Jim Sanford wrote:
Lou: Is it time to write a strawman concept proposal & get people to review some specific proposals? Or do we need to wait on the results of your experiments?
I'd like to see measurements of the accuracy and variability of the voltage references used in the various DC-DC converters. This knowledge is necessary to set the voltage dead-bands in the battery module controllers. We must be able to precisely control, over all possible temperatures and operating conditions, the allocation of load and charging currents to the individual battery modules.
This would provide maximum versatility and reliability in managing a variety of energy storage devices (Li-ion batteries, NiMH batteries, NiCd batteries, supercaps, etc). Here are some of the things we could do with this system:
1. Chemical batteries live longer (i.e., produce more amp-hours over their lifetimes) with shallow discharge. So if we have more than one battery of each type, we want to match their states of charge as much as possible.
2. Li-ion batteries live longest at about 50% charge, so we should try to maintain them at that level.
3. Because supercaps have (or are claimed to have) a much longer cycle life than chemical batteries, during eclipse we'd probably want to discharge them completely before we start to discharge any of our chemical batteries.
4. For test purposes, it would be useful to selectively cycle (discharge, recharge and equalize) a given battery module independently of the others and of the spacecraft's power balance. This might require a dummy load in some situations, e.g., when we want to test a battery under heavy discharge and there's no other place to dump the energy.
All these things require the ability to program arbitrary, accurate and stable I/V curves into each battery controller. All this may seem rather complex, but given that battery failure has ended most of our past missions I think the added complexity would be more than worth it.
--Phil
I agree, particularly given the redundancy we're discussing.
One thing we'll have to look hard at as design progresses -- common-mode failure.
73, Jim [email protected]
Phil Karn wrote:
Jim Sanford wrote:
Lou: Is it time to write a strawman concept proposal & get people to review some specific proposals? Or do we need to wait on the results of your experiments?
I'd like to see measurements of the accuracy and variability of the voltage references used in the various DC-DC converters. This knowledge is necessary to set the voltage dead-bands in the battery module controllers. We must be able to precisely control, over all possible temperatures and operating conditions, the allocation of load and charging currents to the individual battery modules.
This would provide maximum versatility and reliability in managing a variety of energy storage devices (Li-ion batteries, NiMH batteries, NiCd batteries, supercaps, etc). Here are some of the things we could do with this system:
- Chemical batteries live longer (i.e., produce more amp-hours over
their lifetimes) with shallow discharge. So if we have more than one battery of each type, we want to match their states of charge as much as possible.
- Li-ion batteries live longest at about 50% charge, so we should try
to maintain them at that level.
- Because supercaps have (or are claimed to have) a much longer cycle
life than chemical batteries, during eclipse we'd probably want to discharge them completely before we start to discharge any of our chemical batteries.
- For test purposes, it would be useful to selectively cycle
(discharge, recharge and equalize) a given battery module independently of the others and of the spacecraft's power balance. This might require a dummy load in some situations, e.g., when we want to test a battery under heavy discharge and there's no other place to dump the energy.
All these things require the ability to program arbitrary, accurate and stable I/V curves into each battery controller. All this may seem rather complex, but given that battery failure has ended most of our past missions I think the added complexity would be more than worth it.
--Phil
participants (5)
-
Bdale Garbee -
Chuck Green -
Jim Sanford -
Louis McFadin -
Phil Karn