Meadville Space Center
Welcome, Guest. Please login or register.
November 24, 2020, 04:35:08 PM

Login with username, password and session length
Search:     Advanced search
25068 Posts in 2094 Topics by 2267 Members
Latest Member: Apollo Next
* Home Help Search Login Register
  Show Posts
Pages: 1 [2] 3 4 ... 7
16  Project Apollo - NASSP / Programming / Re: LM status... on: July 04, 2017, 11:41:59 AM
Really puzzled by this one: perhaps I initialized the LGC wrong? Or maybe a broken pad load? I followed the LM Activation checklist for Apollo 12, omitting 1 step that seemed to involve setting a PIPA bias.  However every fresh state vector I get turns to garbage. My P30 for DOI has an HA and HP of -9372. TEPHEM is set and matches the command module. IMU is aligned and can point the AOT at a requested star. LGC clock is updated. I'm also getting a program alarm 21204 in P40 and P52 after which both program terminate. Any ideas?

I've tested your scenario a bit. It appears you have two LM batteries that are almost completely drained. The result is also some warning lights, DC BUS, and when you apply a heavy load like during RCS firings, then you even get a PRE AMPS light. So the issue could be intermittent power failures in the LGC. When I try your scenario I can sucessfully uplink state vectors with the RTCC MFD and go through P30. I get no program alarms in P40, but the RCS stopped working due to lack of power.

I believe your LM spent the entire translunar coast period powering it's own running systems, which isn't much, only stuff like standby heaters etc, but still enough to drain two of the batteries quite a bit. And now you get really low voltages on your DC Buses. This probably wasn't even a user error, you might have followed the checklist after TLI by the book. Maybe the checklist told you to start powering the LM from the CSM before the LM was separated from the S-IVB? That could be an issue, because technically the LM doesn't exist in Orbiter yet before it gets separated from the S-IVB.

You can try to fix this by searching for "DSC_BATTERY_A" in your scenario and give it 100% juice again, which is the value 44820000.0. Do this for both batteries A and D, those are the ones drained below 20% or so.

Independently from this I think we have some general power issues in the LM. Something draws too much power in general. You can barely fly a nominal mission with the LM without running into trouble with the batteries.

Well that did it! Thanks, perhaps it was restarting mid uplink? There must be a step omitted from the word checklists as I distinctly remember seeing "LM PWR - OFF/rset" after ejection and thinking it was a bit odd to have the breakers in but not power the LEM. So I guess I dutifully let the batteries power Intrepid the whole way out  ROTFL
17  Project Apollo - NASSP / Programming / Re: LM status... on: July 04, 2017, 09:26:59 AM
Really puzzled by this one: perhaps I initialized the LGC wrong? Or maybe a broken pad load? I followed the LM Activation checklist for Apollo 12, omitting 1 step that seemed to involve setting a PIPA bias.  However every fresh state vector I get turns to garbage. My P30 for DOI has an HA and HP of -9372. TEPHEM is set and matches the command module. IMU is aligned and can point the AOT at a requested star. LGC clock is updated. I'm also getting a program alarm 21204 in P40 and P52 after which both program terminate. Any ideas?
18  Project Apollo - NASSP / Support & Bugs / Re: LV GUID Light on: June 27, 2017, 11:01:08 AM
One other issue I had was that the RTCC uploads the TLI to the AGC as a P30 rather than to the IU when I press UPL. Is there a way to swap it to the IU?

Edit: Sorry found the answer elsewhere on the forum and that is no.
19  Project Apollo - NASSP / Support & Bugs / Re: LV GUID Light on: June 27, 2017, 07:46:53 AM
Only at T-1:00 I believe, I can run it all again later and see what happens, then send files at different parts of the ascent if I still have the same problem. The SII did not have an inboard engine cutoff as well if that is any clue as to what is going on. The trajectory around the time of the light suggested to me the booster was too heavy. I was well past the apoapsis and the booster had to burn an extra 45s or so to reach orbit.
20  Project Apollo - NASSP / Support & Bugs / LV GUID Light on: June 26, 2017, 10:40:54 PM
Flying Apollo 12 with the latest Alpha and ran into some minor issues so far. H-dot did not become positive as early as it should have on the third stage. Shortly before SECO (GET +10:00 roughly) I got an LV GUID lt on the LV display. I had to perform SECO manually using the keypad minus. Again with TLI I needed to manually shutdown the S-IVB. TB6 and ignition were all automatic. TD&E is next up, so far I'm on a less than perfect but usable translunar trajectory.

First I'm correct in assuming Apollo 11-14 all have a pad load? And the LVDC++ also somewhat good to go on these missions? Any idea what the cause of the issues with the S-IVB might be? Scenario attached.
21  Project Apollo - NASSP / Programming / Re: LM status... on: June 23, 2017, 12:19:26 PM
Nice work on the auto tracking! Thumbs Up Going to try and give a landing mission a whirl from launch to splashdown before too long. And I did not experience the issue with the CSM FDAIs
22  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: V8 Release Work Thread on: May 22, 2017, 12:14:17 PM
Saturn V seems to interact with the ground just fine.
23  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: V8 Release Work Thread on: May 22, 2017, 10:31:35 AM
With the new TD points from Fred18 is it possible to fly a complete mission with Orbiter 2016? Also the LM touchdown points are on the top of the landing pads for me, so the LM lands upside down and underground.
24  Project Apollo - NASSP / Programming / Re: LM status... on: April 21, 2017, 12:32:52 PM
I am trying to figure out the COAS calibration of the P52, but it seems the A12 instructions have different values for detents.  It looks like "5" is what I am using but where am I looking for the COAS diagram to input the az and el angles?  Also I know the line of sigh is probably screwy with the LM COAS.  Another question, for the simulation can we assume perfect calibration from the start?

I believe the value placed in R1 for the AOT detent. Did you use the A12 G&N dictionary? It's on page 39 (P52 step 7) https://history.nasa.gov/afj/ap12fj/pdf/a12_lm_g&n.pdf

It lists the COAS as the 7 detent and the azimuth/elevation are both +00000 for the forward COAS. The COAS on the CDR window of our panel is useless there. The 0 degrees LPD mark on the landing panel is what I use as an alternative for now, as I imagine a million other things are going to get priority in the LM. I never tried the overhead COAS but I imagine the yellow tick mark at 0 on the rendezvous window should work.
25  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: V8 Release Work Thread on: April 12, 2017, 07:55:52 PM
I had zero luck with the RR. I could not get it to keep a lock when I changed attitude. I was however able to complete the rendezvous with only 2 fresh state vectors and the LGC. Not an accurate procedure but it got the job done for now. I needed to zero the antenna and manually hold the CSM on the +X axis for the breaking phase.

 If you have better luck with it let me know. The RR and LGC interacted but it always pointed off in funny directions and would not hold a lock. That makes me suspect it was a pilot error.

Would you be able to give me a rough procedure of what you did?  I understand the LGC and the mechanics of the rendezvous but anything to fill in the blanks before I attempt it myself would be wonderful

The document indy91 posted is going to have all you need. If your phasing isn't perfect you can put a +00000 as your elevation angle in P34 (N55 R2) and the LGC will compute the angle at your desired TIG. V90 will give you any out of plane errors if TPI is going to send you into gimbal lock. Other than that TPI is pretty straight forward.

Just a word of warning: running P20 & any P30 simultaneously will cause the LGC to constantly interrupt you asking if it can reacquire the CSM - at least until the someone can implement the RR's inertial stab. It was historically done and P34 would be recycled to take as many RR marks as required, but I gave up on that step for now. Everytime a single lobe reacquires the CSM it will blank the DSKY and ask permission to acquire a full lock on.  It can get especially annoying while trying to enter data or burn TPI. It essentially turns the LGC into a dog that barks at every stranger passing your house.  ROTFL
26  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: V8 Release Work Thread on: April 10, 2017, 12:13:35 PM
I had zero luck with the RR. I could not get it to keep a lock when I changed attitude. I was however able to complete the rendezvous with only 2 fresh state vectors and the LGC. Not an accurate procedure but it got the job done for now. I needed to zero the antenna and manually hold the CSM on the +X axis for the breaking phase.

 If you have better luck with it let me know. The RR and LGC interacted but it always pointed off in funny directions and would not hold a lock. That makes me suspect it was a pilot error.
27  Project Apollo - NASSP / Programming / Re: LM status... on: April 02, 2017, 12:57:11 PM
Weird. Jalexb88 has been flying a few missions (at least Apollo 11 and 12) and I have been flying Apollo 15 from launch to at least the lunar landing, without getting this issue. I wonder if it is a AGC version dependant problem or a procedural one. I just remember looking at the scenario you posted and I never got rid of this alarm. But I never got it in my own scenarios. Maybe Alex and I just didn't thoroughly go through the LR checks in our missions and it's a bug in our LR implementation that happens during the tests.

I am following the Apollo 12 LM Activation Checklist at the moment.  I get PROG alarms when I switch the LR switch.  However, when I followed the procedure @abr35 posted (I think from Apollo 16?) and it works without that V60 added, I still get PROG alarms but the LR changes the R2 from 00001 to 00002 and back.

As far as I can tell the 522 alarm during the LR checkout is okay. Both the Apollo 16 LEM handbook and the Apollo 11 landing document indy91 posted a few pages back say to expect it during checkout. It was during Powered Descent that I believe it was an issue.
28  Project Apollo - NASSP / Programming / Learning C++ on: March 28, 2017, 10:08:04 PM
Trying to learn the Orbiter SDK so I can pitch in on programming in a few months time. Have some basic programming knowledge, but little in C. For the purposes of working on NASSP what should I be most familiar with in C++? Got VS2017 and I've been using tutorials from learncpp.com. I've gotten down the basics of the first 2 chapters.
29  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: V8 Release Work Thread on: March 21, 2017, 05:08:18 PM
Another LM bug I've been seeing in both NASSP7 & 8 now too in both 2010 and 2016 is that any coarse align of the IMU causes Orbiter to crash. So closing the LGC cb, IMU OPR cb, selecting IMU cage, P52, IMU CAGE - on, etc. Has this been reported before? Does not happen on my laptop running Windows 10. Happens with the post ejection scenario file and the old Apollo 11 - Before LM Activation.

Doesn't happen for me in a normal scenario. All old scenarios are broken. I have fixed the Apollo 7 and 8 Historical Missions scenarios and all the new scenarios I will post should be good, but that Apollo 11 scenario is probably broken. Also, just as rcflyinghokie, make sure you have completely REbuild the new Visual Studio 2017 solution at least once.

Happened during the NASSP7-RC stage, long before the move to VS2017. Just figured I'd wait until the LEM became more of a focus to mention it. ROTFL Is there anyway I can get info out of Orbiter as to what is causing the crash?
30  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: V8 Release Work Thread on: March 21, 2017, 10:27:53 AM
Another LM bug I've been seeing in both NASSP7 & 8 now too in both 2010 and 2016 is that any coarse align of the IMU causes Orbiter to crash. So closing the LGC cb, IMU OPR cb, selecting IMU cage, P52, IMU CAGE - on, etc. Has this been reported before? Does not happen on my laptop running Windows 10. Happens with the post ejection scenario file and the old Apollo 11 - Before LM Activation.
Pages: 1 [2] 3 4 ... 7
Powered by MySQL Powered by PHP Powered by SMF 1.1.10 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!