[Date Prev][Date Next][Thread Prev][Thread Next] - [Date Index][Thread Index][Author Index]

Re: Further analysis of the last telemetry from AO-40



Peter:

Thanks for the information.  As you can see from
my reply to Richard, we did figure this much
out but it took us too long to figure it out!

But unlike my message stated this does NOT
explain why the burn went on too long.  I shouldn't
write these when I am tired or preoccupied with
something else!  The valves from the propellant
and oxidizer are pneumatic valves which are
operated on a timer in the LIU right?   I
don't believe we have accelerometers for this
purpose on board!  I am assuming that the
critical data being gathered and that we do not
wish to lose if the data which might show WHY
this overburn occurred.    Is the timer involved strictly in
the  LIU and therefore not directly readable by
the computer?  I know it is programmable by
the IHU, but is it readable by the IHU?  If so,
can we do a "fake" firing which will allow us to
bound the reason for the timing failure?  Is
this the reason we did not want to lose this data
with a hardware reset?  Or are we only hoping that
the reason for the IHU problem would be 
obvious if the COMMAND_ASSIST timer fired?

I now believe that we will recover AO-40 with the
hardware reset, that an IHU crash of unknown
origin (to the rest of us) caused this and that we are
going to have a serious pucker factor in trying to use
the motor again but that we have no choice as the
command team will soon point out and constant
dread as to WHY the IHU crashed.   I would also
hazard a guess that the code uploaded turned out
not to behave on the IPS chain and did not leave
the "fake" stack neutral and blew it away since I
am also reasonably certain that IHU/IPS was not
meant to be downloaded onto the beacon.   This
stack pointer error would account for "telemetry"
being gathered from program space.  As usual,
all  of this stuff is guess work and we are
appreciative of the facts from an authoritative
source.

SEASONS GREETINGS to you and all.  May
we all have an AO-40 filled Happy New Year.

Bob

----- Original Message ----- 
From: "Peter Guelzow" <Peter.Guelzow@arcormail.de>
To: "Richard D. Burgan" <wc8j@raex.com>; <amsat-bb@AMSAT.Org>
Sent: Sunday, December 24, 2000 5:28 AM
Subject: Re: [amsat-bb] Further analysis of the last telemetry from AO-40


> Hi Richard,
> 
> The code did what it was supposed to do, which was cycling the
> He highpressure valve as part of the work on the propulsion system.
> After the first burn it was noted that a valve on the the high pressure 
> side did not fully opened, thus it took a long time until the fuel 
> tanks reached normal operating pressure and once the motor started, 
> the pressure was going dropping again. 
> 
> The error message you have seen simply means, that the definition
> for "MANY_ARMS" was already loaded into the computer. This is
> like trying to compile a program with two subroutines with the
> same name.. Thus IPS aborted this upload and complained, nothing
> happens.  The command station probably sent this block twice,
> but this is no harm.. 
> The blocks you saw were special telemetry when the program was
> executed.. not a crash..
> 
> Glad to see that more people now trying to understand how
> IPS works..   :)
> 
> I'm started working on a more detailed report, but handling all
> the eMail traffic isn't easy too.. and indeed I still hope that
> this report might get obsolete in the next 1-2 days..
> 
> 73s Peter
> 
> "Richard D. Burgan" wrote:
> > 
> > Hi all,
> > 
> > I was fortunate enough to get a copy of the IPS programming
> > manual.  With the aid of the manual I went back over the last
> > few minutes of AO-40 telemetry.  (The interpretation here is
> > very limited since I don't have access to the source code for
> > AO-40.  Nor am I any more than a novice with the IPS
> > language.)  Here is what I found:
> > 
> > All of this occurred Wed, Dec 13, 2000
> > 
> > 11:16:51 UTC I received a telemetry 0 block containing
> > "MANY_ARMS ... UNZUL. NAME !"
> >     MANY_ARMS is an IPS program (subroutine) that cycles power
> > for something.  UNZUL. NAME ! is an IPS error message meaning
> > DUPLICATE NAME !
> > 
> > 11:17:18 UTC an A block of standard telemetry.
> > 11:17:32 UTC an A block of standard telemetry
> > 
> > 11:21:03 UTC a 0 block containing PP2 <DE><A2>p     ...  this
> > repeats many times.
> > 11:21:15 UTC same as above
> > 11:21:28 UTC same as above
> > 11:21:40 UTC same as above
> > 11:21:53 UTC same as above
> > 11:22:06 UTC same as above
> > 11:22:18 UTC same as above
> > 11:22:31 UTC same as above   Note: this is the last block of
> > data from the satellite (that I received)
> > 
> > The numbers in < > brackets above are HEX numbers.  I have not
> > included all the contents of the telemetry blocks for
> > brevity.  You can get them from the AMSAT archives if you are
> > interested.
> > 
> > Did some bad code get uploaded?  As a programmer I have to
> > admit that I have seen some of my programs do similar things
> > when I goofed.  Especially on the old 8 bit machines with
> > primitive operating systems, I've seen the console start
> > scrolling more than once.  If that's what happened to AO-40
> > then I have great hope that a RESET will do the trick.
> > 
> > Good luck command team!  Thanks for all your hard work!
> > 
> > 73's de Rich Burgan, WC8J
> > 
> > ----
> > Via the amsat-bb mailing list at AMSAT.ORG courtesy of AMSAT-NA.
> > To unsubscribe, send "unsubscribe amsat-bb" to Majordomo@amsat.org
> 
> ----
> Via the amsat-bb mailing list at AMSAT.ORG courtesy of AMSAT-NA.
> To unsubscribe, send "unsubscribe amsat-bb" to Majordomo@amsat.org
> 

----
Via the amsat-bb mailing list at AMSAT.ORG courtesy of AMSAT-NA.
To unsubscribe, send "unsubscribe amsat-bb" to Majordomo@amsat.org



AMSAT Top AMSAT Home