Meadville Space Center
Welcome, Guest. Please login or register.
October 24, 2020, 10:11:09 PM

Login with username, password and session length
Search:     Advanced search
Project Apollo - NASSP 6.4.3 released!
http://nassp.sf.net
25068 Posts in 2094 Topics by 2266 Members
Latest Member: twa517
* Home Help Search Login Register
+  Meadville Space Center
|-+  Project Apollo - NASSP
| |-+  Project Apollo - NASSP Development
| | |-+  Programming (Moderators: movieman, dseagrav, Swatch, lassombra)
| | | |-+  Virtual AGC P06 "Standby mode"
« previous next »
Pages: 1 [2] Print
Author Topic: Virtual AGC P06 "Standby mode"  (Read 12939 times)
irnenginer
Project Team Member
Sr. Member
****
Posts: 271



View Profile
« Reply #15 on: May 10, 2008, 11:23:35 PM »

I presume Apollo 13 used standby.

Perhaps, but then they pulled the breakers and shut it all the way down.

I guess it my turn for my two cents. From my understanding, this is the sequence of a standby. When P06 is entered and STBY initiated, the PRO button is keyed and held. the two signals (CH13B1 and PRO) are AND together off the PRO rising edge ( as it goes 0 to 1) and latched, suspending power to the processing unit. The system clock, which is used not only for the AGC but for all other clock timing on the CSM, keeps the TIME registers counting. This is until the PRO is then keyed and held again, those tripping the AND turning the processor back on.

Probably the easiest way to implement this is to monitor CH13B1 and the PRO key for standby condition. When the condition as above is met. yAGC shuts all the way down. The real killer of CPU usage is emulating that clock. so any shutdown would require stopping those cycles. At the other end we update the clock registers to when things start back up. This would probably not need any rewrite of the yAGC to do it. just some code on the PA side.
Logged
kneecaps
Project Team Member
Full Member
****
Posts: 217


36711000 kneecaps@shockpulse.co.uk
View Profile
« Reply #16 on: May 11, 2008, 05:32:13 AM »


I guess it my turn for my two cents. From my understanding, this is the sequence of a standby. When P06 is entered and STBY initiated, the PRO button is keyed and held. the two signals (CH13B1 and PRO) are AND together off the PRO rising edge ( as it goes 0 to 1) and latched, suspending power to the processing unit.

The latched 'STANDBY ALLOWED' causes the AGC to generate a switching signal to it's power supply. While this signal is present the psu B power supply is not generated and this shuts down the majority of the AGC (kill about 22 amps draw).

Quote

Probably the easiest way to implement this is to monitor CH13B1 and the PRO key for standby condition. When the condition as above is met. yAGC shuts all the way down. The real killer of CPU usage is emulating that clock. so any shutdown would require stopping those cycles. At the other end we update the clock registers to when things start back up. This would probably not need any rewrite of the yAGC to do it. just some code on the PA side.

Agreed, we are not modelling the historical method but this would have the same 'net' result. So when we see CH 13 B 1 + the Pro key (probably best to ensure it's held for a few seconds), we snapshot the time registers and kill the yaAGC process. Once the pro key is pressed again we can set the registers to the current time and resume yaAGC processing?

To the outside user it will appear as if the P06 standby is working exactly as it did in reality!

There is a lot of info about safely resuming the AGC from stanby without destroying data in erasable  memory, however it would seem that most of this is due to hardware issues.

There is also code to recover the AGC timer and things after standby and this finishes with a TC to P00. Our method would cause the AGC to resume in P06..so we need some way once PRO is pressed to restart to throw the AGC into P00.

Logged

"Okay. As soon as we find the Earth, we will do it."
- Frank Borman, Apollo 8

Current Work: ?? What next??

Future Work:
I know the AGC pretty well so anything need doing there?

On Hold/Completed:
SPS TVC in P40 issues.
P11 FDAI Error Needles (98%) complete. Comitted. Working A7 scenario.
P06 AGC Standby. Concluded. It's done by the AGC PSU.
Got us a complete AOH Volume II
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
*****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #17 on: May 11, 2008, 10:13:50 AM »

Moderator notice: Topic moved to "Programming" and renamed since it looks like we're beginning to work on this.
Logged

lassombra
Moderator
Sr. Member
****
Posts: 410


View Profile Email
« Reply #18 on: May 13, 2008, 01:24:53 PM »

No, I think Apollo 13 had bigger issues and had a complete shutdown.  Then again, it is possible that they used it in the LEM, but I doubt we'll find any documentation defining which side of a very fine line they chose to go.
Logged

My current Project Apollo work:

Quickstart to the Moon initiative (Quickstart_to_the_Moon): Done through earth orbit.  Working on new method of calculating TLI.

Checklist Controller: 
  • MFD Interface 99%(Minor cleanup and future features remain)
  • Panel Interface 99%
  • Excel interface and logic 99%
  • LEM Event code.0%
  • DSKY Interface code. Framework complete, creating "buttons"
  Approximately 80% done. (Checklist Controller
kneecaps
Project Team Member
Full Member
****
Posts: 217


36711000 kneecaps@shockpulse.co.uk
View Profile
« Reply #19 on: May 13, 2008, 01:46:42 PM »

No, I think Apollo 13 had bigger issues and had a complete shutdown.  Then again, it is possible that they used it in the LEM, but I doubt we'll find any documentation defining which side of a very fine line they chose to go.

I recall reading in biographies and history that the astronauts did not like the idea of shutting down the IMU. I recall reading statements like "why shut it down when its working". I think there there was apprehension that it might not work after a standby. I've read most of the Apollo Flight journals and it was never mentioned as a procedure.

Logged

"Okay. As soon as we find the Earth, we will do it."
- Frank Borman, Apollo 8

Current Work: ?? What next??

Future Work:
I know the AGC pretty well so anything need doing there?

On Hold/Completed:
SPS TVC in P40 issues.
P11 FDAI Error Needles (98%) complete. Comitted. Working A7 scenario.
P06 AGC Standby. Concluded. It's done by the AGC PSU.
Got us a complete AOH Volume II
lassombra
Moderator
Sr. Member
****
Posts: 410


View Profile Email
« Reply #20 on: May 14, 2008, 01:38:38 PM »

Hmm... I don't think the IMU was ever shut down, but I KNOW the computer was at least put into standby.  Note however that the CM was completely 100% shut down, as one would expect of it after splashdown.
Logged

My current Project Apollo work:

Quickstart to the Moon initiative (Quickstart_to_the_Moon): Done through earth orbit.  Working on new method of calculating TLI.

Checklist Controller: 
  • MFD Interface 99%(Minor cleanup and future features remain)
  • Panel Interface 99%
  • Excel interface and logic 99%
  • LEM Event code.0%
  • DSKY Interface code. Framework complete, creating "buttons"
  Approximately 80% done. (Checklist Controller
bluespace88
Project Team Member
Full Member
****
Posts: 241



View Profile
« Reply #21 on: May 25, 2008, 04:30:12 PM »

sorry, was a bit busy with life, but back now.

Just started implementing the auto-clock update feature.  Found one tiny typo with sending up a '+' dsky command to the computer, but thats all squared away now, which was the main reason it wasn't finished earlier, which was sending up 372 instead of 272.  Will be continuing to work on it.
Logged
bluespace88
Project Team Member
Full Member
****
Posts: 241



View Profile
« Reply #22 on: May 26, 2008, 03:06:31 PM »

automatic Clock update done and committed.  Also moved the state vector calculations to just right before the values are uploaded to the agc.  Before, it was done during the switches check, so it should be a bit more accurate this time around.
Logged
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
*****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #23 on: May 27, 2008, 08:23:42 AM »

Good job, both updates are working fine as far as I can tell.  Thumbs Up
I still have the "V82 issue", but I still don't know if this is an issue actually...

Cheers
Tschachim
Logged

bluespace88
Project Team Member
Full Member
****
Posts: 241



View Profile
« Reply #24 on: May 27, 2008, 09:12:31 AM »

I'm wondering if updating the state vectors by real time instead of one time only would help or not.

EDIT: will continue it over at the state vector thread
« Last Edit: May 27, 2008, 09:32:24 AM by BlueDragon8144 » Logged
Pages: 1 [2] Print 
« previous next »
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.10 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!