Meadville Space Center
Welcome, Guest. Please login or register.
December 15, 2019, 02:35:02 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 News & Discussion
| | |-+  Support & Bugs (Moderators: movieman, Tschachim, Swatch, lassombra)
| | | |-+  CSM hibernation?
« previous next »
Pages: 1 2 [3] 4 Print
Author Topic: CSM hibernation?  (Read 5071 times)
eddievhfan1984
Hero Member
*****
Posts: 737



View Profile
« Reply #30 on: January 11, 2017, 06:19:07 PM »

Sounds about right. I gotta look for the CMC power lanes, because I'd be interested in getting proper standby functionality.
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #31 on: January 11, 2017, 06:41:20 PM »

Sounds about right. I gotta look for the CMC power lanes, because I'd be interested in getting proper standby functionality.

I have already a mostly done Virtual AGC implementation of standby mode sitting in my Orbiter 2016 folder. The standalone Virtual AGC has been supporting standby mode for a few months now, so I just had to copy those changes over to our yaAGC. All that needs to be done is implement some things in the apolloguidance class. The AGC++ used to support standby mode, so those functions need to be hooked up with the Virtual AGC. I'll work on that some time again.
Logged
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #32 on: January 11, 2017, 07:02:20 PM »

I have experimented with CMC power cycles in the past (pulling the breaker to remove all power).
Each time the CMC is powered on again I found it to be very unstable. I had to do several combinations of V36 and V96 (Forced return to P00) to even be able to do a V37.

Could it be that something gets messed up the way the VirtualAGC engine is suspended when the breakers are pulled? Is the engine just killed, does it's state get saved or something else?

I do this often I will pull it and time warp, I have never had any issues bringing it back online.  Literally breakers in, clock update, SV update, and REFSMMAT update, DAP and P52.
Logged
eddievhfan1984
Hero Member
*****
Posts: 737



View Profile
« Reply #33 on: January 13, 2017, 04:29:23 PM »

What happens if you standby the AGC as is, then pull the CMC breakers? Does that make shutting it down more stable (since only the low-frequency clock is really running)?
Logged
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #34 on: January 13, 2017, 04:45:23 PM »

What happens if you standby the AGC as is, then pull the CMC breakers? Does that make shutting it down more stable (since only the low-frequency clock is really running)?

At least from my experience with it it has no effect with the restarting of the CMC, but then again I have not had stability issues with this even with shutting down and time warping for tens of hours at a time.  As far as the nitty gritty goes I do not know how it would effect things.  And shouldn't pulling the breakers regardless of the standby mode have the same net effect since the power is for all intensive purposes removed?
Logged
eddievhfan1984
Hero Member
*****
Posts: 737



View Profile
« Reply #35 on: January 13, 2017, 05:19:33 PM »

I don't think so. The mag-core memory is non-volatile, but reads are destructive IIRC, so when the CMC is in STBY, only the slowest counter is operating to increment the CMC clock and the memory read/write lines are de-powered. Then, when you pull the CMC breakers, only that STBY clock and the DSKY is de-energizes. This may have no bearing on the vAGC itself, but that's what's on my mind.
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #36 on: January 13, 2017, 05:26:15 PM »

I don't think so. The mag-core memory is non-volatile, but reads are destructive IIRC, so when the CMC is in STBY, only the slowest counter is operating to increment the CMC clock and the memory read/write lines are de-powered. Then, when you pull the CMC breakers, only that STBY clock and the DSKY is de-energizes. This may have no bearing on the vAGC itself, but that's what's on my mind.

The Virtual AGC has a fully implemented Standby mode. I can show you the relevant commits so that you can find e.g. what has to be changed to our DSKY. Do you want me to commit my AGC engine changes to the Orbiter2016 branch? That would include everything that was changed to the Virtual AGC itself and then it has to be wired together with our apolloguidance and DSKY classes.
Logged
eddievhfan1984
Hero Member
*****
Posts: 737



View Profile
« Reply #37 on: January 13, 2017, 05:35:54 PM »

Might as well, TBH. It'd be easier to do than the HGA or starting the tricky business of vehicle separation.
Logged
thewonderidiot
Full Member
***
Posts: 48



View Profile
« Reply #38 on: January 13, 2017, 05:41:07 PM »

Also, for the most part, you don't need to worry about the destructiveness of reads on erasable memory. The vast majority of resets are caused by the signal STRT1 (which is more-or-less an OR of the various hardware alarms and standby). STRT1 gracefully lets the current MCT run to completion before triggering a GOJAM. And as far as I know every MCT of every instruction sequence in the AGC takes care of writing read values back out to memory -- so in standard resets there isn't any danger to erasable values.

There are a couple of things, on the other hand, that can trigger a STRT2 signal. While I don't know exactly what they are (we're missing the schematics to module B8), I believe it to be something like an OR of a scaler failure and a bus voltage failure. Anyways, STRT2 is treated much more urgently, and GOJAM occurs right away instead of waiting for the MCT to finish. If that happens at the right point you can end up with memory that has been destroyed -- and the next time the AGC is turned on, it will take a STRT1 restart from a parity failure the first time it access that address. That will only ever be a single corrupted address.

As far as I know, once the erasable memory has been loaded at the factory, the above is the only way to actually destroy values in it.

As for what's powered in standby -- it's all of the scaler module (so every clock frequency), all of the timer module except for the 12-step timepulse counter (so timing leading leading into and including the first scaler stage, as well as the start/stop logic), half of the Alarms module (mostly B8 interfacing stuff like STRT2 -- STRT1-relating things are off), and a handful of things in the In-Out modules related to keeping clocks to peripherals going. And, of course, the gates that can get you back out of standby.  Happy
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #39 on: January 13, 2017, 05:50:11 PM »

I have commited the Standby stuff. It should include:

-Every change to the files agc_engine.h, agc_engine.c and agc_engine_init.c from this commit: https://github.com/virtualagc/virtualagc/commit/79bc374baf569240155a52627ac5bb8bd9b5ce49
-There are a few DSKY changes in this commit: https://github.com/virtualagc/virtualagc/commit/b58253b73dccee24043915b5a9a2cf07d616d7b8 that I have not implemented yet in our DSKY
-The beginning of changes to the apolloguidance class. Saving/Loading of a few more obscure AGC variables, like NightWatchman. This had been implemented before, but not the saving/loading.
-Incomplete change to the input channel handling for Standby and I might have done it wrong, because the Channel 30-33 being inversed confuses me.
-A debug string for the Standby flags

Good luck have fun, Eddie Very Happy
Logged
eddievhfan1984
Hero Member
*****
Posts: 737



View Profile
« Reply #40 on: January 13, 2017, 06:34:25 PM »

OK. Although you changed the branch name to Orbiter2015. Did you mean to do that?
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #41 on: January 13, 2017, 06:41:41 PM »

What was renamed? I only implemented those changes in the Orbiter2015 branch, they are not intended for master/NASSP 7.0. Or did I merge something in the wrong way? I'm always worried about that...
Logged
eddievhfan1984
Hero Member
*****
Posts: 737



View Profile
« Reply #42 on: January 13, 2017, 06:51:13 PM »

I thought the V8 Alpha stuff was supposed to go into Orbiter*2016*, not Orbiter2015.
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #43 on: January 13, 2017, 06:55:48 PM »

Was there a Orbiter2016 branch created? Doesn't look like it, so the branch is still called Orbiter2015.
Logged
eddievhfan1984
Hero Member
*****
Posts: 737



View Profile
« Reply #44 on: January 13, 2017, 07:03:28 PM »

NVM. I was a derp and created it as Orbiter2016 in my fork.

EDIT: I merged and cleaned it up. Now the "2016" fork is named Orbiter2015 for consistency.
« Last Edit: January 13, 2017, 08:04:51 PM by eddievhfan1984 » Logged
Pages: 1 2 [3] 4 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!