Lost Russian Communications Satellite Found in Wrong Orbit

Lost Russian Communications Satellite Found in Wrong Orbit
By Peter B. de Selding, Space News Staff Writer
Updated at 4:15 p.m. EST

PONTE VEDRA, Fla. — A $300 million Russian telecommunications satellite launched Aug. 18 disappeared from the view of ground controllers and the U.S. space surveillance network along with the rocket upper stage that carried it into orbit, according to industry officials and the Russian space agency, Roscosmos.

More than 24 hours after the 5,800-kilogram Express-AM4 satellite separated from the Proton rocket's Breeze-M upper stage, neither object could be found, officials said. The U.S. Space Surveillance Network of ground radars was tracking a single object that one official said was neither the Breeze-M nor the Express-AM4, but rather an auxiliary propellant tank from the Proton rocket.

But by mid-day Eastern Daylight Time Aug. 19, the U.S. Space Surveillance Network had located the Express-AM4 satellite, saying it was in an orbit with an apogee of 20,317 kilometers, a perigee of 1,007 kilometers and an inclination relative to the equator of 51.3 degrees. One industry official said it would be difficult, from this position, to maneuver Express-AM4 into operational position in geostationary orbit with sufficient life remaining to make the effort worthwhile.

Yes, but not completely. We recovered the satellite into a controllable orbit... but commercially there were losses. A few of the transponders didn’t come back.

What I left out was that early in the days it took us to recover control of the bird, management was faced with a hard decision: Turn off the heaters for the electronics packages to conserve battery power... or bet that we could recover the bird fast enough to get the solar panels back online and producing bus power fast enough. If we took the latter choice and didn’t recover the orientation quickly... the batteries would have gone dead and we would likely never recover it.

After the first, oh, 8 hours... we reckoned from the telemetry that this was something that would take days, maybe weeks to recover from and keyed up the commands to shut down the heaters.

This put the electronics in the transponders at risk, and ultimately the internal temperatures got so low (like -80C and colder) it turned out that some of them didn’t come back at all, or (in at least one case) it came back with diminished sensitivity on the receiver.

So the bird was still compromised, and there was an insurable loss because traffic that was scheduled to go onto this satellite had to be re-routed to other birds and the future revenue on the rolled bird was reduced.

But the insurer thought they got away cheap. If the entire bird had been lost, as I recall the numbers went like this: $87 mil for the bird not achieving operational orbit, and something like $270 mil in foregone revenues expected over the operating lifetime. All of the first number was insured, and a large proportion of the second number was insured, but I don’t remember exactly how much.

Ultimately, it took one guy, his HP-41CV calculator (engineers don’t leave home without them), a legal pad, mechanical pencil and a non-stop pot of coffee to figure out what had happened. This lone engineer (who started as a EE, but became an expert on satellite orbital issues) took the scant data we had, asked for a little more data to be developed from the limited telemetry we were getting on bus voltages, the period of the signals coming across the antenna, the differential in voltages between the panels... and he produced some of the most awe-inspiring display of mathematics I’ve ever seen in my life.

He computed from the signal being swept across our ground antenna, the signal strength as we swept the box with our ground dish antenna, and the rise/fall in solar voltage:

- the orientation of the satellite
- the exact location of the bird in our “box” station (which back then was 2 degrees wide)
- how fast it was spinning
- which *way* it was spinning (this was one of the harder things to develop)
- and how much we had to fire a thruster, and which thruster to stop the spin.

All in one non-stop 27 hour session of grinding out the math by hand.

As I said, awe-inspiring, especially to a newbie engineer.

My job as a wet-behind-the-ears intern was to keep the insurance company rep occupied and out of the hair of the guys doing the heavy lifting. At night, I could park him in front of the Playboy Channel monitor. During the day, the Playboy Channel was replaced by one of the holy roller feeds - I don’t remember which televangelist had his own transponder back then. It might have been Swaggart - I remember that he was disgraced only a few years after this.

I won’t mention the insurance company, but you’d all know it in an instant if I did.

When the insurance guy was sleeping off his copious alcohol consumption (the insurance company wasn’t doing that well just then, and they were scared witless of taking these losses), I was writing on-the-fly custom telemetry processing s/w for assembling packages of commands to key in by hand or to process snatches of telemetry we’d get. The existing s/w expected nice, stable full frames of data... the ad-hoc stuff allowed a guy to key in snatches of a frame and get something meaningful decoded and encoded quickly. The bird was rotating so quickly that we were able to load up only one command (which would be, oh, the equivalent of six or eight bytes of information) at a time into the radio register and hit the “transmit” button - but we had to time the transmission to account for the delay over the distance to orbit. Early in the event, it took an old hand who had been there at the earliest days of NASA at Goddard SFC who had done this “in the old days” to teach us how to do this, because the satellite control engineers believed in leaving back doors to jump around all the automation. Usually, there were three HP-1000 minicomputers that were controlling and monitoring the birds - a telemetry processor, a stationkeeping computer and a command computer. They were all linked together with a custom bus interlink designed by HP. You could say they were loosely coupled multi-processors, but they came nowhere near the coupling of something like a VAX Cluster setup. When everything was working correctly, you never saw or programmed the raw commands to the birds (we were controlling six operational birds and this one ‘replacement’ bird that had not yet come online) and everything was presented in nice, clear information on the screens for operators to see for every satellite the company ran.

Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.