Meadville Space Center
Welcome, Guest. Please login or register.
December 14, 2019, 05:25:09 PM

Login with username, password and session length
Search:     Advanced search
Project Apollo Beta 7.0 released!
http://nassp.sf.net/wiki/Installation
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 5070 times)
macieksoft
Full Member
***
Posts: 80

RSO we are go we wanna blow!


View Profile
« Reply #15 on: January 09, 2017, 03:13:28 PM »

I managed to restart FC2 and all the systems of CSM.
Now i am preparing for deorbit burn.
Logged

macieksoft
Full Member
***
Posts: 80

RSO we are go we wanna blow!


View Profile
« Reply #16 on: January 10, 2017, 04:55:16 PM »

Had bunch of problems.
First is screwed TVC DAP for A9, full deflection of TVC forced me to use SCS over CMC.
But the biggest one is problem with P37. I did state vector and timer update after i powered on CMC. But this does not helped P37 to behave normally.
I inputted -1.3 degrees reentry angle manually.

Problems i had with P37:
-It gave me wrong landing coordinates, both the conic and precission were very unprecise. I landed in africa while conic gave me landing in pacifc and precise gave me landing in atlantic :-P
-Difference between conic and precission solution in latitude was more than 50* while normaly the difference do not exceeds few degrees.
-Delta T was crazy, way too long than it should be. 0.5G occured long before CMC calculated entry interface time.
-It gave me burn that was about 45* off plane.
-I was forced to do manual reentry because calculated reentry attitude was screwed all the way. It oriented thing heatshield upward instead of heatshield retrograde :-P Probably because of screwed delta T.

I have attached scenario. It requires DGIV and Hyperion launcher but they can probably be removed from scenario somehow. Not sure if it requires UMMU and UMMFA.
If you have some time to waste ;-) you can try doing P37 and see what happens.

* apollo to dg4 after eva 0002 0007.scn (116.77 KB - downloaded 74 times.)
Logged

eddievhfan1984
Hero Member
*****
Posts: 737



View Profile
« Reply #17 on: January 10, 2017, 08:10:33 PM »

How did your state vector check out prior to P37? Did you do any sightings with P22?
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #18 on: January 11, 2017, 07:30:50 AM »

Had bunch of problems.
First is screwed TVC DAP for A9, full deflection of TVC forced me to use SCS over CMC.

Looks like your DAP configuration is wrong. You have a 0 in the first digit, which deactivates the DAP. If you start up the DAP Configuration (Verb 48) your Noun 46 should be register 1: 11102 and Register 2: 01111. Your Register 1 was 01102. Noun 47 (CSM and LM weights) looks ok, but Noun 48 has very large trim angles for the engine gimbals. Those should be all zeros. If you are not 100% familiar with the Verb 48 procedures, look at the G&C Checklist under "\Doc\Project Apollo - NASSP\Word Checklists"

Your DAP configuration should also prevent attitude control. Did you maneuver with the SCS to the burn attitude?

Quote
But the biggest one is problem with P37. I did state vector and timer update after i powered on CMC. But this does not helped P37 to behave normally.
I inputted -1.3 degrees reentry angle manually.

Problems i had with P37:
-It gave me wrong landing coordinates, both the conic and precission were very unprecise. I landed in africa while conic gave me landing in pacifc and precise gave me landing in atlantic :-P
-Difference between conic and precission solution in latitude was more than 50* while normaly the difference do not exceeds few degrees.
-Delta T was crazy, way too long than it should be. 0.5G occured long before CMC calculated entry interface time.
-It gave me burn that was about 45* off plane.
-I was forced to do manual reentry because calculated reentry attitude was screwed all the way. It oriented thing heatshield upward instead of heatshield retrograde :-P Probably because of screwed delta T.

I have attached scenario. It requires DGIV and Hyperion launcher but they can probably be removed from scenario somehow. Not sure if it requires UMMU and UMMFA.
If you have some time to waste ;-) you can try doing P37 and see what happens.


Very interesting, I get the same results. What I think is happening is P37s stupid Delta V optimization. And you happen to be in a trajectory where the DV optimal burn is very different with conic calculations than with the precision calculations. I'm not sure you can do much about it, it's just a quirk of P37. You can try shifting the ignition time (Noun 33) or give P37 a fixed DV. With a fixed DV you might get more consistent results. So instead of zero in register 2 of noun 60, maybe try 400 ft/s?! No idea, but that might help. Anywhere up to 600 ft/s would still be realistic for a LEO deorbit.
Logged
macieksoft
Full Member
***
Posts: 80

RSO we are go we wanna blow!


View Profile
« Reply #19 on: January 11, 2017, 10:17:11 AM »

How did your state vector check out prior to P37? Did you do any sightings with P22?

I didn't checked state vector using any CMC programs. I just uplinked SV using uplink from PAMFD.

And I know about DAP config. I just have a habit to keep it disabled until needed, so until I start P40s or P60s.
My usual config is 11103 so it's for CSM alone with low error deadband and about 4* rate. But until I need CMC DAP I keep first digit at 0 to disable it.

And TVC test (part of P40) works fine but as soon as it ends I am getting full deflection of gimbals. I can only switch to SCS and use EMS for DV + SCS for TVC.
« Last Edit: January 11, 2017, 10:23:21 AM by macieksoft » Logged

rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #20 on: January 11, 2017, 10:30:51 AM »

I didn't checked state vector using any CMC programs. I just uplinked SV using uplink from PAMFD.

Are you uplinking them correctly with PAMFD?  In other words do you have the correct ship/SOI/and slot selected for the intended uplinks?

And TVC test (part of P40) works fine but as soon as it ends I am getting full deflection of gimbals. I can only switch to SCS and use EMS for DV + SCS for TVC.

Is your THC centered?  Do you have zeros in your N48 DAP gimbal angles? Is this a docked burn?
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #21 on: January 11, 2017, 10:39:05 AM »

I have tested the scenario, state vector is ok and when I try a CSM alone burn the CSM spins out of control. So I am sure @macieksoft did everything right.

The way it looses control with the TVC DAP looks like a problem with one of the padloaded TVC parameters. I'll investigate, maybe when I created the Apollo 9 scenario I did a typo or something like that. I have tried docked burns for Apollo 9, so the TVC is not completely broken at least. Just one of the CSM alone parameters. Apollo 11 and later have very different TVC parameters for the CSM alone, and Apollo 8 and and earlier still have the parameters from before I did my research to make docked burns work. So this is probably a "CSM alone during Apollo 9" only problem.
Logged
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #22 on: January 11, 2017, 10:42:25 AM »

So this is probably a "CSM alone during Apollo 9" only problem.

Probably a good time to discover that as I have been working on the A9 procedures and checklists.  I have not done a CSM alone SPS burn in my scn yet though.
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #23 on: January 11, 2017, 10:54:08 AM »

Looking at @macieksoft's scenario, there are very weird TVC parameters loaded. Here the relevant parameters from the Apollo 9 launch scenario:

Code:
CMPAD3013 123
CMPAD3014 175
CMPAD3016 17433
CMPAD3017 4500
CMPAD3020 4
CMPAD3021 1130
CMPAD3022 10000
CMPAD3023 1000
CMPAD3024 232

and here the parameters in the scenario:

Code:
EMEM3014 5175
EMEM3015 4063
EMEM3016 5175
EMEM3017 4500
EMEM3020 5175
EMEM3021 4063
EMEM3022 5175
EMEM3024 5175

This is just garbage. What even is this repeating 5175? It looks like all parameters from at least EMEM3010 to EMEM3032 are overwritten with parameters that do and mean nothing. EMEM3033 and later are ok, those are some of the TVC DAP digital filter parameters.

You didn't edit around in your scenario to fix the TVC, did you @macieksoft?   Very Happy I have no idea what else would do this damage to the erasable memory. Maybe a bad exit out of P40 or something like that? A side effect of starting the CMC up again after hibernation?

So the parameters in the launch scenarios are probably good. At least I am going to believe that until disproven.

EDIT: Tried it with my own Apollo 9 scenario.  The TVC behaves very well during a CSM alone burn. Docked burns of course, too. So there was no TVC problem before the EMEMs were somehow changed.
« Last Edit: January 11, 2017, 11:56:43 AM by indy91 » Logged
macieksoft
Full Member
***
Posts: 80

RSO we are go we wanna blow!


View Profile
« Reply #24 on: January 11, 2017, 02:06:10 PM »

Quote
Maybe a bad exit out of P40 or something like that? A side effect of starting the CMC up again after hibernation?
It could be. AFAIR i was trying P40 and i forced its termination by using V37E00E.
Also the CMC powerup was giving some troubles, its first time i am trying such thing so i had problems with starting it and i did a reset (open then close both CMC breakers) so many times. Maybe this scrambled the memory.

Is there any way to fix this save? Can i just copy EMEMs from valid one?

And could P37 troubles be caused by this scrambled memory?
« Last Edit: January 11, 2017, 02:08:10 PM by macieksoft » Logged

indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #25 on: January 11, 2017, 02:42:43 PM »

I have found the weird 4063 and 5175 numbers in that scenario in at least one other place, the task waitlist with the addresses of specific tasks. But there they seem to be normal, so maybe when the "mishap" occured in P40 instead of reading the TVC parameters parts of the waitlist was written over the TVC parameters?  ROTFL

Is there any way to fix this save? Can i just copy EMEMs from valid one?

At least Apollo 13 and later had exactly that in their checklists. Kind of a backup padload if the erasable memory gets overwritten, long tables of data like this for Apollo 16: http://history.nasa.gov/ap16fj/csmgc/9-4.gif

If only the TVC parameters were overwritten then you can simply take the parameters CMPAD3013 to CMPAD3042 and copy them over to your scenario and everything works again. As said above EMEM3033 and later should be good. Of course change the CMPAD to EMEM. If you want I can also work out a procedure like in the document above, so that you can do it in-game without scenario editing.

Quote
And could P37 troubles be caused by this scrambled memory?

Hmm, I think there is only one P37 specific pad load, the polynomial coefficient for the automatic reentry angle calculation, which we have talked about a while ago in the other thread. And that one still looks unchanged. There are a few variables that could have an effect on P37 though.
« Last Edit: January 11, 2017, 02:46:23 PM by indy91 » Logged
Thymo
Full Member
***
Posts: 113


View Profile WWW Email
« Reply #26 on: January 11, 2017, 03:16:39 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?
Logged
eddievhfan1984
Hero Member
*****
Posts: 737



View Profile
« Reply #27 on: January 11, 2017, 04:19:03 PM »

While magnetic-core memory is supposed to be non-volatile, I think you still have to reinitialize it with a fresh start to confirm it works properly. When you try to start a program (V37), do you get any error codes thrown?
Logged
macieksoft
Full Member
***
Posts: 80

RSO we are go we wanna blow!


View Profile
« Reply #28 on: January 11, 2017, 04:41:54 PM »

I never got any error codes during enteire flight.
Logged

Thymo
Full Member
***
Posts: 113


View Profile WWW Email
« Reply #29 on: January 11, 2017, 05:13:47 PM »

While magnetic-core memory is supposed to be non-volatile, I think you still have to reinitialize it with a fresh start to confirm it works properly. When you try to start a program (V37), do you get any error codes thrown?

Yes, I got a 1520 thrown at me because the COMP ACTY light was constantly on. Even if I would let it run for 10 minutes it wouldn't extinguish. I guess it was trying to integrate the state vector real hard.
Repeating the V36 and V69 V96 multiple times and immediately doing a state vector and clock update got it to calm down again.
« Last Edit: January 11, 2017, 05:56:38 PM by Thymo » 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!