Source:  http://cr4.globalspec.com/thread/29317#newcomments

Hello Members,

Please go through this BBC story of the Chinese built/launched communications satallite for the Nigerian government. Here http://newsvote.bbc.co.uk/2/hi/africa/7726951.stm

The satellite was launched about two years ago and it is confirmed packed up.

Apart from the indicated power problem, what could be other causes of the satellite failure?

Cheers,

ethobil

Observations

The BBC article stated that the Nigerian satellite

1. … was limited because the type of frequency it used was disturbed by clouds in the atmosphere, and did not work properly in Nigeria’s rainy season or during the Harmattan, when clouds of dust blow down from the Sahara, he said.
2. … also operated on frequencies already allocated to other companies and interfered with other providers’ equipment.
3. … controllers shut the satellite down because it was having problems with its power supply, the government announced.

The observations in #1 and #2 are items that I learned to look out for before I graduated with my Bachelors.

Background for Observation #2:  Operating a satellite on another satellite’s frequency is both extraordinarily rude and stupid.  Interference from the satellite assigned that frequency will make both satellites useless for significant portions of their design life.  Obviously this is to be avoided and there are agencies to regulate these frequencies.

Background for Observation #1:  This is amatuer hour stuff.  Anyone with satellite TV or satellite radio knows that weather interferes with transmissions.  The thing is, the impact of weather can be minimized if not eliminated if you pick the correct frequency.

You may be asking why I addressed #2 first and then #1.  The answer is this, Observaton #2 shows that the Nigerians didn’t do even the most basic homework and contact the proper authorities.  Observation #1 reinforces this notion through an ignorance of basic satellite operations and limitations.

Observations #1 & #2 demonstrate that on the Nigerian customer (at least those in charge) didn’t know the first thing about what they were buying.  Questions about operations, lifetime, and weather are pretty basic and I learned to ask those questions before graduating with my Bachelors.

The final Observation

Observation #3 is that the satellite was shut down for power problems.  This could be something like a battery failure, power subsystem failure, solar array failure, or ADCS failure (which could point the arrays or the whole satellite the wrong way).

Given that the Nigerians didn’t do their homework – to know which frequency to use for their communications satellite, nor did they do enough homework to contact the correct regulatory agencies – before buying an expensive piece of hardware it only makes sense that they didn’t do their homework regarding system testing.

My guess is that the Chinese bid cheap re-using a satellite they designed for someone else.  This is common practice to reduce cost and risk.  But there are always custom changes when requirements change or new, updated hardware is added to the design.  If you don’t test the integrated system properly the chances of failure are high.  The Nigerian satellite was probably a recycled telecom satellite from another customer and some component of power system (like bateries) or the ADCS system (like attitude sensors or thrusters) was replaced.

An example of what I’m thinking…

An ADCS sensor, lets use a gyro for now, is replaced.  The new sensor comes from the same manufactuerer with the same power, size, and mounting requirements.  However, this new sensor provides its output in a different coordinate system such that 2 of the 3 axes (X & Y) are identical to the previous sensor but the 3rd axis (Z) is -1 of the original.  Without thorough design effort and proper integrated system testing, this -1 is easy to miss.  Then the whole satellite ends up pointed away from the sun and runs out of power.

The Nigerians missed the easy stuff, why would we assume they got the hard stuff, like proper testing, correct?

What finally worked

I have a quad core machine at my desk so I run multiple MATLAB windows.  These multiple windows allowed me to test some distributed computing processes.  As a result I set up a script for allowing the multiple windows to run.  I was using Stateflow in the model which requires a compile before each run.  As a result the model had to be run from a temporary directory.

This temporary directory was the first sign that the function, when distributed, is working.  The second sign was when the output file is saved.

Long story short, the batch command worked.  The batch command works but only with the PathDependencies and FileDependencies properties set.  The function is something like this

jj = batch(‘monte_sim_loop’, ‘matlabpool’, 0, ‘PathDependencies’, {…}, ‘FileDependencies’, {…});

The matlabpool set to 0 is important.  I tried to using a matlabpool of 3 for my initial runs.  It tied up 4 nodes but only run 1 instance of the sim.  Then I created a loop

for ii = 1:15

  jj = batch(…

end

The reason that a matlabpool of 3 tied up 4 nodes was that the matlabpool property is for how many additional nodes you want running.  It originally appeared to be an overhead function that was created.  A coworker discovered the matlabpool command already assumes 1 node and so anything higher than 0 ties up that many extra PCs for the 1 job task.  Since I just want my jobs distributed (not parallel) I set the property to 0.   When I ran the loop above, 15 computers were tied up and 15 nodes worth of results were produced.

If you know more, please share

I invite anyone and everyone who knows more about how to use the Parallel Computing Toolbox to share.  Use the comments to share.  Or if you like I welcome guest bloggers.

Thanks

Previous, related, posting

MATLAB’s Parallel Computing Toolbox First Impression

Monte Carlo Runs

For work I’ve been asked to run a Monte Carlo analysis.  The analysis is one where I vary a large set of parameters in a large Simulink simulation.  Any given simulation will take between 40 minutes and a few hours.  So obivously generating thousands of runs with a single computer would take months.

In the lead up to this analysis I asked a few questions.  First, I found a bank of parallel computing resources at work.  I asked them if it was possible and the answer was “Yes” with my take away being that it was doable and easy.  It may be doable, it is not easy.  Second, I went to Mathworks training (on modeling for aerospace system which had a session on parallel computing) and asked some questions about how to run parallel operations.  I also left this session thinking it would be easy.

The online help is worthless

When you are running a model of any complexity there are a lot of parameters to set.  If you are building models correctly you will be setting these parameters via variables not hard coding.  This means that the simulation workspace must have all those variables.

The Mathworks help with regard to the Parallel Toolbox and Simulink simulations is pretty meager.  One of the easiest means of distributing the simulation is through the use of the parfor keyword instead of the for keyword.  The meager help suggests that simulation must be run from within a function because parfor requires a static workspace and Simulink creates variables in whatever workspace it runs from.  So the help suggests using a dummy function as a wrapper for the sim command.

The help forgets to mention that running a simulation from a function’s workspace is simple – once you find that help but finding that help was a little buried.  (If you want to know how look up the simset function and the SrcWorkspace and DstWorkspace properties.)  I have run several simulations from within a function’s workspace on a single PC.  However, doing so from within a dummy function called from a parfor loop doesn’t work like it does from a single PC.  And the error messages are obtuse.

Obtuse Error Messages

I spent days attempting to get the simulations distributed to the various nodes.  The error messages provided at this stage were reasonably straight forward.  However, once the simulation was distributed to the nodes the error became far less useful.  The first couple of times there was no obvious error.  After digging through a long log file a cowroker found the errors and helped me fix them.  That said, I think they were listed as warnings in the log file not errors.

Next Post:  What finally appears to have worked

No one cares about nuclear power once it’s in space.  Only on it’s way to space.

Radioactive Contamination

Nuclear power in space comes from an RTG (Radioisotope Thermoelectric Generator).  The RTG is powered by a radioactive isotope.  The isotope decays and produces heat in its decay.  That heat produces electricity through the use of thermocouples.

For space harware, the main threat from an RTG is that explosive destruction of the hardware containing the radioactive material would spread radioactive material.  The RTG containers are designed to survive this type of event so the odds of contamination are small.

What happens when the container is destroyed…

If the container were to break up the estimated odds of contamination are 1 in 10.  The alpha radiation that the most common RTG fuel cannot penetrate the skin but if it were inhaled it would do serious damage to internal organs.

There were protests when Cassini launched…

People were scared that if the Cassini launch failed then the radioactive fuel would find its way into the atmosphere and people would inhale it.  While this shouldn’t be taken lightly the launches are generally conducted over the ocean.  The winds in the atmosphere may disperse the radioactive material.

Obviously if the launch vehicle travels through all of the atmosphere it is unlikely that we can wait for a launch window where all of the prevailing winds are blowing out to sea.  This dispersion shouldn’t be taken lightly but understand that the fuel most US satellites use is only a problem when inhaled or ingested.  If the particles fall in the sea or on the land then it poses no threat – to people.

Basics of an RTG

An RTG is a Radioisotope Thermoelectric Generator.  Essentially these radioactive isotopes decay to more stable atoms.  As the isotopes decay they give off heat and that heat is converted to electricity.  The conversion to electricity is done using thermocouples.

An RTG is used on space craft instead of solar panels when the mission is very long or to an outer planet where the light energy provided by the sun is too weak (low density).  The Voyager and Cassini missions used RTGs.

Benefits of an RTG

For space the benfits of an RTG are obvious.

1. Long term power (in the range of hundreds of watts)
2. No moving parts – like solar arrays that have open up after launch
3. Degradation of output power happens but much slower than with solar panels

These advantages lead to a stable power source capable of operating for decades in extreme environments.

Fuel Source

From Wikipedia:

Plutonium-238, curium-244 and strontium-90 are the most often cited candidate isotopes, but other isotopes such as polonium-210, promethium-147, caesium-137, cerium-144, ruthenium-106, cobalt-60, curium-242and thulium isotopes have also been studied. Of the above, ²³⁸Pu has the lowest shielding requirements and longest half-life. Only three candidate isotopes meet the last criterion (not all are listed above) and need less than 25 mm of lead shielding to control unwanted radiation. ²³⁸Pu (the best of these three) needs less than 2.5 mm, and in many cases no shielding is needed in a ²³⁸Pu RTG, as the casing itself is adequate.

²³⁸Pu has become the most widely used fuel for RTGs, in the form of plutonium(IV) oxide (PuO₂). ²³⁸Pu has a half-life of 87.7 years, reasonable energy density and exceptionally low gamma and neutron radiation levels.

The criteria leading these choices of fuels are

1. Must have a half-life short enough that its decay produces substantial heat
2. Must ahve a half-life long enough that the heat generated is relatively stable for decades
3. For space, the energy output per density must be high
4. The radiation produced should be high energy with low penetration – preferably alpha-radiation – so that shielding can be minimal

Next post: Why people are scared.

This time Phoenix stays dead…

Where the Phoenix lander is on Mars it’s winter.  Phoenix ran out of power recently.  The 2 rovers, Spirit and Opportunity, have to fight for their own survival every Martian winter.  Why?  Because they use solar arrays.  Solar arrays that degrade with time.  Solar arrays that degrade with the deposition of dust.  Solar arrays that don’t produce much power when the Sun isn’t very high in the sky.

Power constraints have hampered interplanetary probes in the past.  The problem is that once a probe gets out near Jupiter there just isn’t enough sun light to do much.  Even large arrays can’t entirely overcome the problem of “not enough light”.

We have $100 million missions that end because of power

We have missions to Mars and Jupiter and beyond.  Some like Cassini use nuclear power.  Others use solar power.  Some missions, like Phoenix, have ended not because of mechanical failure, communications failure, or a lack of good science that still needs doing but because they have too little power.

A lack of power has not stopped the Voyager missions decades after their launch.  A lack of power doesn’t need to kill or maim anymore Mars missions.  A Radioisotope Thermoelectric Generator (RTG) is the answer.

Next post: What is an RTG?

Next Next post: Why people are scared.

I’m sorry for not posting this week.  I’ve been buried at work and I’ve picked up so many little web projects lately that I’ve spread myself too thin.

With any luck I’ll get back to posting 2 or 3 times a week next week.

I could use some help so I’d welcome any guest posters out there who know their stuff in controls or engineering in general.  I welcome any industry or academic experience.  I’d like the site to reflect more than just my own experiences.

Thanks for your patience.