SUNSAT Status - Day 0-45
(Launch to 9 April 1999)

Executive summary.

In the six weeks since SUNSAT was launched on 23 February 1999, nearly eighty satellite passes have been monitored from our ground station, amounting to about 800 minutes of communication time. In these thirteen hours we have verified that the majority of the satellite is in good health. We have made inaugural amateur radio contacts, and have begun supporting the NASA payload operations. Software fixes for problems discovered during initial testing have been uploaded to SUNSAT today, and we hope that the first high-resolution images from Sunsat will be obtained by the end of April.

Introduction

In the first six weeks in orbit, the ground station team at Stellenbosch has verified that most of the satellite is working well. Since Sunsat has many goals and clients, it is helpful to summarize what has been achieved so far for each of these 'clients'.

A detailed technical report on Sunsat's status is given on the following pages.

Detailed report on SUNSAT status - 8 April 1999 (Day 44).

Hardware Summary

SUNSAT hardware is performing well with only two known problems, neither of which affects the mission or main payloads. The apparent malfunctions are the live TV camera's S-band exciter and one of the UHF transmitters. We have only been using the OBC1 computer to date, but OBC2 has been booted successfully. OBC2 is a 386 processor. When it boots it 'speaks' a longish message via the UHF transmitter. It is a backup for OBC1, and is more power-hungry, so we hadn't brought its software up to the level of OBC1. This waits for later months.

Software summary

SUNSAT has extensive real-time software that was developed by a small team. They have done a great job and the critical packet communications software and the on board computer operating system software (for OBC1) appears to be faultless. Whole-earth orbit data (WOD) can be gathered and downloaded. Some is on http://sunsat.ee.sun.ac.za/news.htm. The RAM disk (64 Mbytes) hardware and software seem to work excellently, and are presently hosting a 4Mbyte RAMDISK.

GPS communications

The TurboRogue has been powered up and communicates well with Sunsat's OBC1 computer. Data from the GPS validates the GPS internal computer but status messages from the GPS are of a type not seen before in Stellenbosch. The data has been sent to JPL who are waiting for necessary people to return from leave.

Laser tracking

We have authorized NASA to proceed with laser tracking at their own schedule on an experimental basis since we can't presently report attitude angles.

Skymag communication

The serial communications to the tip mass, and the microphone and school experiments have also been checked and seem OK. We haven't done extensive data analysis yet.

OBC1 software update uploaded

Some software bugs have been found and had various effects on commissioning. Corrections have been made to the OBC1 software and a new binary image was uploaded to SUNSAT today (8 April) during two passes. OBC1 seems to be operating normally after the upload, but the next few days will show exactly how successful we have been. The successful upload of new executable code to OBC1 is in itself another milestone.

The main computer problems we have encountered are:

OBC1 code uploads

The necessary changes to OBC1 code have been made and carefully tested (also takes time) and have been uploaded to Sunsat. The new software is residing in OBC1's RAM, from which it booted. When we are satisfied that OBC1's operation with the new code is better than with the old code, the update will be transferred into OBC1's Flash memory, permanently replacing the existing operating code. This last process has been carried out on earth, but not yet in orbit.

Attitude control issues

We have been learning a lot about the attitude control on Sunsat in the last few weeks. We deployed the boom early to get out of an unfavorable sun attitude, and by good luck managed to become gravity-locked in the correct direction. Simulations indicated that we should be able to disable attitude control for about ten days before a pitch rotation would be induced. To give 'pass time' to other testing, we put the ADCS monitoring 'on hold' for a few days, and discovered (now verified three times) that we can only disable active magnetic control for less than two days before the pitching motion starts. We suspect that either a higher aero-drag moment than expected (we can check with Orsted) or a residual magnetic moment is the cause. The solution is to get the ADCS operating continuously as planned.

The effect on schedule has been that when a pitch tumble starts, we lose about three days damping the motion and getting a gravity lock, determining the orientation, and then possibly inverting the satellite with the reaction wheels. This whole process is complicated by the unreliable communications with a satellite at unknown angles, and by the OBC crashes described previously. However, in spite of all these challenges, we have managed to identify the causes of the problems and do the software fixes. We thus expect (hope?) that we will soon converge to a more controlled and stable situation.

ADCS polarity tests

We also realized there may be some incompatibility in polarity assumptions on some of the ADCS sensors, so have spent time validating the polarities of rough sun sensors, magnetometers, coils, reaction wheels, solar panels, and solar panel temperature sensors. Sign errors were found with X-axis coils, meaning that we will have to upload the ADCS software correction in some days time before we can expect to be able to de-librate Sunsat to less than a few degrees. . Updated ADCS code has been uploaded to the ADCS T800 transputer once and went smoothly so we don't expect difficulties.

Communications

We now get good communications with Sunsat on 80% of the passes. We use the 2m band for the uplink and the 70cm band for the downlink. During these we can download data at 9600 bits/s and have downloaded about 250kBytes in a pass. The signal strength varies from pass to pass, and is probably related to spacecraft attitude variations that we can't determine at present. We discovered that the fine horizon sensors' measurements which are gathered by the ADCS are passed to OBC1, but are not copied into the WOD (whole earth orbit data) file that can be downloaded to earth. This has also been fixed in the OBC1 code upload. We have used Sunsat for some voice message communication in a voice relay mode to communicate from Stellenbosch to Durban. See the web site and follow the multi-media link and play the 'First Bounce'. You need the RealAudio plug-in from a web browser to play this.

S-band checkout

Sunsat's S-band downlink is intended to handle the +- 40 Mbit/s data from the imager. To receive this we need the area of a 4.5m diameter dish antenna, and it has to track the satellite to better than 1 degree. We developed a conical scan tracker for the receiving system and can track the sun successfully, merely from its microwave noise. We tried receiving Sunsat's S-band transmitter on one occasion, and saw a flash of signal before the transmitter had to be turned off at the end of the pass. We subsequently mounted VHF and UHF Yagi and helical antennas on the side of the tracking dish to help the VHF/UHF communications. We have also had a problem with the dish's linear vertical actuator's position sensor and have had to replace this. Workshops have been on leave over the mid-term break and Easter, so we have had to delay further S-band tests to the start of next week. We hope that attitude control problems will be over by then too, giving us a satellite with known orientation.

L-band uplink

This is primarily for 'heavy' amateur experimentation and can serve as a last resort backup up-link if all other channels are blocked - heaven forbid. We do not plan commissioning this for some months since it is expected to be difficult to get operating since uplink antennas must be correctly aimed and high power is needed. It is also only a 'single string' system in the satellite

Ground Station teething problems

The Sunsat ground station had never been used to command spacecraft before, and some effort has been needed to get ground systems functioning satisfactorily. We had (and may still have some) interference from our uplink transmitter to our downlink receiver. This produces excessive re-tries on packet communications. We have separated the antennas and appear to have solved the problems, but need to verify that some of our poor communication passes are not traceable to this cause. Also, our ground station is in the EE building (where we work). This has good logistic motivation but results in us being in a very noise RF environment (a few hundred PC's networked with UTP's). So far we don't have hard evidence of EMC hampering our communications, but we are always concerned that this may be a problem. Another radio amateur about 3km from our ground station has however experienced similar signal conditions to us so we think our ground station is OK. Many cheap TV cameras and a PC whose keyboard is now six floors below its CPU are some of the measures that have enabled the minimum number of ground station people needed to support a pass to be reduced from about eight people to two people.

Scarcity of passes and personnel

Stellenbosch only gets two satisfactory passes per 12 h day, and sometimes only a single overhead pass. Because ground station personnel also have other roles in life (remember Sunsat has no full-time staff), we cannot regularly support nighttime passes. In the first few weeks after launch most night-passes were supported by extra-ordinary effort by many people, particularly the software team. Additional remote controlled ground stations at more favorable locations would help greatly, but would be an additional burden to manage, and would need software changes by our already pressured software team. We believe the OBC1 uploads will be a more productive use of the software team's time and will make our use of Stellenbosch passes more effective, achieving the desired end goal.

Combination of problems

Managing Sunsat has been complicated primarily by the 'crashes' on OBC1 and lack of a reliable diary, which has meant that we need to 'safe' Sunsat if communications ever appears risky. The new diary will hopefully solve this problem, enabling much greater efficiency to be obtained. We also expect that many of the ADCS errors have been found and will soon be corrected. This will (probably) produce more stable communications, which will help bootstrap the process.

Conclusion

SUNSAT seems to have survived launch and early orbit operations. Bugs in software on SUNSAT and our ground station, together with hardware problems in our ground station have slowed SUNSAT's commissioning, but we expect to get over these soon.

We would like to start scheduling some Amateur operations using the VHF up/UHF down repeater mode before the end of April. Since we need the day passes within range of Stellenbosch for continued commissioning we will probably only be able to activate the repeater over South Africa during the night and in day passes that are very low and East of Stellenbosch. We will probably also be able to activate the repeater over other continents at certain times, but will coordinate this via SA-AMSAT first.

The success in Sunsat results from significant effort by some academics and many young engineers working on the project, in addition to other academic responsibilities . They are to be congratulated on their success with the early orbit operations of Sunsat.

(Prof.) Garth W. Milne
SUNSAT project leader.


© Electronic Systems Laboratory 1999
by Buchan Milne
WWW:sunsat.ee.sun.ac.za