Meadville Space Center
Welcome, Guest. Please login or register.
September 23, 2020, 06:18:54 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 Development
| | |-+  Programming (Moderators: movieman, dseagrav, Swatch, lassombra)
| | | |-+  LM status...
« previous next »
Pages: 1 ... 62 63 [64] 65 66 67 Print
Author Topic: LM status...  (Read 159493 times)
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #945 on: May 22, 2017, 02:53:04 PM »

I have the files for Sundance.  Looks like the A digit in the DAP was literally CSM docked or undocked.  There was no ascent stage/descent stage setting.
« Last Edit: May 22, 2017, 06:05:41 PM by rcflyinghokie » Logged
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #946 on: May 22, 2017, 05:39:08 PM »

I can also report that I have successfully completed a LM active rendezvous with Luminary 069.  The burns were a bit sloppy as a result from my initial phasing and insertion burn calculations but the CSI/CDH/TPI all got me back to the CSM and braking phase was successful.  I will say that without the RR holding a lock it is very challenging to use the tapemeters for the braking gates! 

I will be going back through it again from undocking to see if my initial burns perturbed enough to give numbers that were different from the flight plan, but regardless after insertion, all maneuvers were calculated and performed with the LGC  Happy
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #947 on: May 23, 2017, 03:38:19 AM »

Thanks for getting us the documents! I guess the Sundance DAP simply used the weight as the parameter to achieve good control over the ascent stage. Luminary just does it in a more elaborate way, with a separate DAP configuration for the ascent stage.

jalexb88 requested two LM Systems Handbook and I am currently using that to finish up some work on the Explosive Devices Subsystem and the APS control logic. That is related, because the firing command for the APS is what causes staging. So pressing Abort Stage doesn't immediately cause stage separation. It just arms the Ascent engine and a firing command is coming from LGC or AGS. So during a nominal lunar liftoff the staging pyros are firing at T-0 and not when the Abort Stage button was pressed. The Stage Fire switch also can initiate staging, of course. The LM-1 Systems Handbook is already available, I might wait for the LM-8 one to be scanned before I push my ED/APS control logic update, just to cross check a few things and make sure it's not a LM-1 specific configuration.
Logged
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #948 on: May 23, 2017, 03:20:24 PM »

For the Apollo 9 SM RCS SEP burn, what is the best way without an MCC update to burn 5fps radially down?  Wouldn't that be burning towards the center of the earth?  I tried a P30 with dVZ -5fps and it faces me in the opposite direction.  Maybe I do not understand the reference frame for the burn vectors as well as I thought!
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #949 on: May 23, 2017, 03:23:30 PM »

For the Apollo 9 SM RCS SEP burn, what is the best way without an MCC update to burn 5fps radially down?  Wouldn't that be burning towards the center of the earth?  I tried a P30 with dVZ -5fps and it faces me in the opposite direction.  Maybe I do not understand the reference frame for the burn vectors as well as I thought!

Downwards is positive along the Z-axis. So the best way is to use the manual TIG/DV input on the Maneuver PAD page of the RTCC MFD, with the DV input "0 0 5" for 5 ft/s downwards.
Logged
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #950 on: May 23, 2017, 03:40:52 PM »

Downwards is positive along the Z-axis. So the best way is to use the manual TIG/DV input on the Maneuver PAD page of the RTCC MFD, with the DV input "0 0 5" for 5 ft/s downwards.

Perfect thanks!  I am just trying to polish up these maneuvers so I can have a cleaner rendezvous Happy

EDIT:  And a little cleaner it was this time.  Less time flipping from checklist to checklist and more time playing hurry up and wait.  I still get some weird TPI numbers, nothing as unusual this time (my first go I actually lit my APS again because of a 60fps burn) but still another successful rendezvous.  I did a LM active docking as well this time, and the orientation change is tricky at first to get used to when maneuvering for a dock, but still everything worked.  I am going to stop there checklist-wise for now and am going back to the very beginning now that I can launch with Orbiter 2016, and see if I can make these first SPS burns cleaner using the Maneuver PAD manual inserts instead of orbit adjustment page, and of course debug the checklist thus far.
« Last Edit: May 25, 2017, 06:11:22 PM by rcflyinghokie » Logged
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #951 on: May 26, 2017, 09:25:44 AM »

So I have noticed now whenever I load a quicksave in the LM, the event timer is counting up if it was running, even if it was counting down before.  I don't know if this was a problem before or after the power transient fixes but if someone wouldn't mind taking a look at it?  I imagine it would be a simple fix.
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #952 on: May 26, 2017, 10:55:00 AM »

So I have noticed now whenever I load a quicksave in the LM, the event timer is counting up if it was running, even if it was counting down before.  I don't know if this was a problem before or after the power transient fixes but if someone wouldn't mind taking a look at it?  I imagine it would be a simple fix.

The proper mission and event timer saving/loading functions weren't used yet in the LM, so only the time and the state (running or not running) were saved before, not if it was counting up or down. That can't really be fixed in old scenarios, but I will add the correct saving and loading in the LM.

Also, this: https://github.com/dseagrav/NASSP/pull/92#issuecomment-304244421
Logged
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #953 on: May 26, 2017, 04:30:28 PM »


Regarding this, now I am getting a "merge conflict" and also when I fetch, I am seeing origin as an option instead of just upstreams.

Auto-merging Doc/Project Apollo - NASSP/Checklists/Apollo 9 LM Checklists.xls
CONFLICT (content): Merge conflict in Doc/Project Apollo - NASSP/Checklists/Apollo 9 LM Checklists.xls
Auto-merging Doc/Project Apollo - NASSP/Checklists/Apollo 7 Checklists.xls
CONFLICT (content): Merge conflict in Doc/Project Apollo - NASSP/Checklists/Apollo 7 Checklists.xls
Automatic merge failed; fix conflicts and then commit the result.
warning: Cannot merge binary files: Doc/Project Apollo - NASSP/Checklists/Apollo 9 LM Checklists.xls (HEAD vs. a6d66491af6611122e1ce8013fa296083d9eef2a)
warning: Cannot merge binary files: Doc/Project Apollo - NASSP/Checklists/Apollo 7 Checklists.xls (HEAD vs. a6d66491af6611122e1ce8013fa296083d9eef2a)

EDIT: I just reinitialized and set up my git and the problem was fixed.  No clues as to what happened, but all is well now.  The PR with the changes to all checklists has been made as well.

« Last Edit: May 27, 2017, 07:43:28 AM by rcflyinghokie » Logged
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #954 on: June 03, 2017, 11:40:12 AM »

@Indy91 I see you pushed some LM logic fixes, just wondering what this actually is doing to the LM?  And should I expect any differences when I make my burns?
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #955 on: June 03, 2017, 11:57:59 AM »

A few days ago I (kind of) accidentally pushed the big APS/DPS control logic update, during the process of renaming the Orbiter2015 branch. It wasn't 100% ready, so I knew about a few smaller issues. This fix today specifically fixes the case if the LGC sends neither Engine On or Engine Off signals. Sunburst120 is kind of lazy about that, it only sends an EngineOff signal during the burn programs (P4X), before and after the burn itself. The result was, in combination with the bugs, that setting the Engine Arm switch to ASC alone could cause the engine to start. So it would start without an actual engine on signal. The DPS had a similar bug, but instead of the engine staying on it would cycle on and off. Both of these issues should now be fixed. I think Luminary always sends an Engine Off signal whenever the engine isn't running, so these issues would never occur.

In any case, with these fixes the engine on/off logic should be pretty realistic now. The difference to before the big update is that some special cases work or work better now, like the Descent Engine Command Override switch and the Abort Stage button arming the ascent engine, even if the Engine Arm switch is still set to Descent. The wiring of the control logic is mostly based on the LM-1 Systems Handbook right now. An LM-8 Systems Handbook is currently being scanned and I will change the wiring to how it worked in LM-8. LM-1 didn't have a few circuit breakers of the later LMs.
Logged
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #956 on: June 06, 2017, 10:17:40 AM »

I don't know if any recent changes did this, but I just started the second LM powerup (I did the first LM powerup before the last few builds) and now closing the LGC breaker turns off the DKSY.  I have attached my recent checklist and the scn file where it is powered up again.

* Apollo 9 Day 4 0001 0001 0002 0001.scn (187.42 KB - downloaded 53 times.)
* Apollo 9 LM Checklists.xls (735 KB - downloaded 57 times.)
Logged
lotisully86
Full Member
***
Posts: 37


View Profile
« Reply #957 on: June 06, 2017, 02:50:29 PM »

Also have encountered this, the LGC warning lights work I believe but the numerical lights go blank once the breaker is closed. Also the standby light is not lit even tho the LGC hasn't been brought out of standby.

Somewhat related, after uplinking the LM state vector before the first dps burn, the comp activity stays lit and I can not get to P00 without a V96. Is this behavior expected?
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #958 on: June 06, 2017, 03:05:26 PM »

Also have encountered this, the LGC warning lights work I believe but the numerical lights go blank once the breaker is closed. Also the standby light is not lit even tho the LGC hasn't been brought out of standby.

The DSKY being on before it should have power and the DSKY being off with the circuit breaker closed are actually two unrelated issues. The AGC can command the DSKY to be off in standby mode, but this signal and the actual standby mode currently become desynced if you completely cut the power. Thymo is working on fixing that.

Quote
Somewhat related, after uplinking the LM state vector before the first dps burn, the comp activity stays lit and I can not get to P00 without a V96. Is this behavior expected?

First DPS burn? With which LGC version?
Logged
lotisully86
Full Member
***
Posts: 37


View Profile
« Reply #959 on: June 06, 2017, 03:58:10 PM »

When uplinking the state vector and target load for the first dps burn yes. If just the target load is uploaded, it does not cause this behavior. I believe it is luminary 069? I started from the Apollo 9 MCC launch scenario using the latest modules, so I'm just assuming 069 is the default setting
Logged
Pages: 1 ... 62 63 [64] 65 66 67 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!