What do users want from a satellite     15/1/2006                                                                              GM1SXX

In many cases, the answer to that question is simply 'a communications transponder'.

This begs the question, why then put so many other systems on board? 

Many satellites carry a large number of onboard system other than what's actually required to maintain a communications transponder. Common among these are onboard computer systems, telemetry systems, power conditioning systems and the like.  As satellites have become more complex, the modes by which they can fail has also increased dramatically.  All communications satellites carry batteries, another common cause of  loss of a mission.

Since small, cheap, powerful, lightweight computers have become commonplace, it has been the  habit of designers at AMSAT and elsewhere to incorporate the technology into their satellites. Generally, these computers are pretty much 'one of a kind' prototypes, often running specialised languages such as IPS ( a variant of FORTH) and designed to fulfill a specific set of tasks. 

The computer can be your friend or your enemy.

As your friend, it can manage the onboard systems effectively, often under the control of an onboard electronic 'diary', something I first saw used on the SSTL UoSATs to very good effect.  On the UoSATs, the OBC (On-Board-Computer) managed the collection and transmission of telemetry, whole orbit data and other experiments.  A 'flying mailbox' became possible. Other uses include telemetry data collection and formatting, collection of whole orbit data and firing magnetorquers.  Soon, amateur birds will be using computers as a anti-alligator measure, employing DSP techniques to control the transponder passbands.

The computer can also be your enemy,  failure of a single critical item can leave a satellite crippled, either through in-service failures of the sort that happens to ground based equipment or by degradation by radiation in the space environment. 

For a satellite whose primary mission is communications between radio amateurs, its possible however to build a satellite that forgoes the use of computers completely.

Why would anyone want to do this when there is space and power enough on board to run a computer?

Well, computers break.  That's a fact of life.  Other things can break also... the transponder, the batteries, the Battery Charge Regulator, so why worry about the computer so much?

Well, the answer to that question could be summed up in a single word ... 'RADIATION'.  With Molniya 'Lightning' type orbits, the radiation dose is greater than in LEO and therefore even more of a risk.  

Very few computer chips or systems have been built with the problem of radiation in mind.  After all, virtually all the computers ever built are used on the ground.  Traditionally, the fix in the satellite industry for this issue has been to use 'radiation hardened' or RAD-HARD components.

RAD-HARD parts are expensive. VERY expensive, so a cheaper alternative was soon adopted. This is the COTS route.  Commercial-Off-The-Shelf  components or modules are selected on the basis of their suitability for the job and the testing process takes place 'in-house' thereby saving a large percentage of the costs of buying RAD-HARD or 'space-rated' components.

In general, this has worked very well with companies like Surrey Space Technology Limited (SSTL) adopting this system for their small spacecraft in low Earth orbit.  While this is a useful route to take for scientific satellites, I have to question whether amateur COMMUNICATIONS satellites need computers at all.

It's possible to do most of the meaningful tasks required of managing a satellite using nothing more than some ordinary CMOS logic components. Ordinary CMOS appears to work rather better in a space environment than its designers believed was possible.  CMOS also has the advantage of low power consumption.

After 30 years in a very hostile radiation environment, the CMOS telemetry system on board OSCAR-7 still works when the satellite has enough illumination.  In December 2003 when myself and John LA2QAA were actively monitoring it, this ancient bird was sending meaningful telemetry in many of the data frames.  In a conversation with Jan King who was responsible for many of the systems aboard  I discovered that the CMOS aboard Oscar7 is of the first generation unbuffered type.  It has served us very well in Oscar7 and the more recent (although now considered old)  buffered CMOS is even more durable in many applications.

Al.

GM1SXX