Meadville Space Center
Welcome, Guest. Please login or register.
December 01, 2020, 09:08:55 AM

Login with username, password and session length
Search:     Advanced search
Gemini 060615 released!
25068 Posts in 2094 Topics by 2267 Members
Latest Member: Apollo Next
* Home Help Search Login Register
  Show Posts
Pages: 1 [2] 3 4
16  Project Apollo - NASSP / Support & Bugs / Re: CTD when doing SV update on: August 07, 2012, 05:36:22 PM
The new module works fine on the SV update Thumbs Up

Having me look at computer code is like having a monkey look at a wristwatch, but at least I know how to break things...

thanks again!
17  Project Apollo - NASSP / Support & Bugs / Re: CTD when doing SV update on: August 05, 2012, 11:36:03 PM
In a way, I'm glad to know it's apparently not my fault Yes

18  Project Apollo - NASSP / Support & Bugs / CTD when doing SV update on: August 01, 2012, 11:26:01 PM
I'm just getting back into Project Apollo after being away for a while, and I'm running into a problem while running A7 (Virtual AGC)

When I use the PAMFD to do a SV update, Orbiter crashes when pressing the "SV" button the second time (which of course actually starts the update).

Running the current build of the beta modules.
Windows 7 64 bit.
Problem occurs in every Project Apollo scenario I've tried.
Also occurs whether I run "orbiter" or "orbiter_ng", in full screen or a window

I did some research and figured it might be a firewall issue, but disabling it didn't change anything.  Also, if I run the standalone telemetry client, I get data from Orbiter, and can send data to the spacecraft.

I've run out of ideas on how to fix it.  I've attached a scenario in case I've got something odd going on there.

19  Project Apollo - NASSP / Project Apollo - NASSP News & Discussion / Re: Glycol Loop Check problem on: October 29, 2011, 01:05:25 PM
I think I can answer the easy part Very Happy

Mechanical gauges often have a "peg" to stop the needle from moving past the highest reading on the scale.  When a gauge is "pegged", it means that whatever the gauge is measuring is higher than the maximum value the gauge can show.

Suppose you've got a temperature gauge that reads up to 100 degrees.  Any temperature reading above 100 would peg the gauge.

20  Project Apollo - NASSP / Project Apollo - NASSP News & Discussion / Re: A DSKY and AGC question! on: March 04, 2010, 03:55:36 AM

  I'll try to answer some of these--maybe others can take a shot at the other stuff


1.  Is there a way to fly to the moon and land without having to use the IMFD or the LunarTransfer plugins? These are great modules - don't get me wrong - but it just seems so "cheating" to use these.. Real Apollo missions didn't use these apps. Now I do realize real apollo astronauts had an entire mission control back in Houston, but can't we calculate the burn values and input them into the DSKY/AGC somehow and do it the more 'realistic' way?

  Well, there are a couple of programs that can do these sorts of calculations.  Probably the best known are GMAT and STK/Astrogator.  GMAT is free (and currently in beta), but as far as I can tell, hasn't been really well documented yet.  I've also found it to be a bit buggy.  STK is a "professional grade" tool (in fact, it's covered under ITAR regulations, so it can't be sold to someone who is not a US citizen without a State department waiver).  Unless you can swing an educational license, it's my understanding that it's really expensive--like new car expensive.  Nice new car expensive.

  Once you get one of those programs, it's a really steep learning curve.  Just as an example, to enter a lunar orbit at a particular day and time would seem pretty straighforward.  To enter orbit at the inclination you want, you may need to adjust your TLI time so you leave at the correct inclination, which then changes your launch time and azimuth in ways that may not be intuitive.  You'll have to know how to string things together so that something in step five can change the values used in step one.

  Add to that the fact that, at least for the moment, there isn't complete documentation available on exactly what was done on the flights, so you'll need to make some educated guesses, only to find six steps later that your educated guess wasn't quite right, and the only real way to fix it is to go back, guess again, and see what happens.

  What I'm getting at is that you can really calculate the burns without using an MFD, but you'll spend more time doing "flight controller" stuff than "astronaut stuff".  It's really not cheating to use them.


b) the DSKY commands seem confusing enough as it is, now certain commands (noun /verb combination) are not available in certain modes, and even in the advanced Virtual AGC mode there are still 'real' Apollo commands that won't work in the beta NASSP.. Anyone can clear up exactly what the current situation on this is?

Again, there is documentation that isn't available.  We have an AGC manual, but it's for the software that flew on Apollo 15.  That software could do things that simply weren't available in the version we're using, so you run across commands that act differently than documented, or just don't work at all

I'm trying to learn the capabilities of the NASSP DSKY&AGC and it makes it difficult when there are multiple AGCs depending on mode, and multiple version tutorials most of which are outdated, so when something doesn't work quite right I don't even know if its the manual is too old, or I'm in the wrong mode, or I'm doing something wrong, etc..

  You and me, both.  I don't really have an answer, other than to say if you run into a particular problem you can't get solved, post it here--there are people who can point you in the right direction.

3) I read somewhere there should be an easy way to find out using the DSKY/vAGC/AGC/etc the exact "position" of the CSM in space (more like 'bearing' or 3d orientation is what I am referring too, current pitch, current roll, current yaw, etc..) When I attempt to do this to find my status the DSKY just gives me OPP ERROR. This happens in both the Simple and vAGC modes! I can't even find where I read this anymore, it was on some official looking NASSP tutorial page somewhere..

Make sure you're in P00, and key in V16N20E (Verb 16, Noun 20, then "Enter")  The three registers on the DSKY will show you pitch, roll and yaw to .01 degrees

4) I also want to learn how to use the DSKY/AGC to orient my CM and/or CSM by inputting the pitch/roll/yaw angles of my choosing.. I have the DAP turned on and CMRCS is all going good but when I try to get the DSKY to orient the spacecraft I get the OPP ERROR again.. Is this feature not implemented in the latest beta version yet or what am I doing wrong?

Again from P00, key in V62E.  This will set the needles on FDAI 1 (the one on the far left) to display how close you are to the attitude you're going to go to.  Then key in V49E.  This will bring up your roll, pitch and yaw angles.

Key in V25E.  This will let you set the attitude you want.  The first register should be blank.  Enter your roll angle, say +180.00.  Hit enter.  The second register blanks, and you can enter the pitch attitude the same way.  Hit enter, and enter in the yaw angle you want.  After you type in the yaw angle, hit "Enter", the "Pro".  You should see a flashing "50" in the verb field, and a flashing "18" in the noun field.  This is the AGC's way of telling you it's ready to maneuver.

Make sure the SC Cont switch is set to "CMC" your three BMAGs are set to "Rate 2", and the CMC Mode switch is "Auto".  Click "Pro" on the DSKY, and the SC should begin to maneuver.

One thing I wanted to clear up--you mentioned that the CM RCS is up and running.  That's normally only used after the CM separates from the SM.  You'll need to turn on the RCS control switchs to run the SM RCS.

5) I would like to do mid course corrections (minor course corrections) using ONLY the DSKY/AGC and not some cheesy IMFD or TransLunar plugin.. I can calculate the needed values in excel tables so all I really need to find out what to do is HOW to set the CM up properly so the vAGC/DSKY can let me input the values.. and HOW exactly to input the values in the DSKY to get the autopilot to do the course correction without using anything else.. This SHOULD be possible since in Apollo 13 they did that correction in the LEM without any computer at all!

Basically what I am asking is this, currently can the DSKY be used to make a correction at all without IMFD or any other module/plugin/add-on? And if the answer is YES, then can someone PLEASE teach me how to make a course correction (or basically just a burn) using ONLY the DSKY and vAGC and NOTHING ELSE?

If you've already got the burn values calculated (both time and XYZ velocity), it's quite easy.  Run P30 to input the information, and then you can use P40 to do the burn with the SPS, and P41 if you want to do the burn with the RCS.  Either way, the burn programs (P40 and P41) will orient the spacecraft so that it's pointing in the correct direction at ignition.

In your "doc" folder, one of the subfolders should have the documentation on exactly how to run the programs.  If you can't find it, just holler, and I'll send you the Word doc that I work from.

  take care,
21  Project Apollo - NASSP / Support & Bugs / Re: NASSP full screen crash on: March 02, 2010, 09:06:26 PM
I just tried it, and it doesn't crash (at least, it didn't on mine) if I moved away from the main panel.

Puma, try doing ctrl+up arrow so that you're looking at the hatch, and see if it still crashes.
22  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: No P32 in A7 vAGC? on: February 25, 2010, 07:39:00 PM
From the research I have done on that burn, it was uplinked from the ground and P30 used. I think there was something in the transcripts that confirmed it for me.

I have attempted to get at least get state vectors input from orbiter into GMAT, with the idea of using it to calculate this burn. But I could never get the SC to be in the right place with respect to the earth ground or in an orbit that looked right. Has anyone ever had success doing that?


  Are you ending up in a polar orbit when you input the SV?  I found by playing around that if I transposed the Y and Z terms in the SV (both position and velocity), and used the EarthMJ2000Eq coordinate system, I'd get the correct shape orbit.  I still haven't cracked the problem of getting the SC in the right place over the earth...
23  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: No P32 in A7 vAGC? on: February 24, 2010, 03:14:55 AM
There is no P32.

  Well, I'll stop trying to run it, then  Wink

24  Project Apollo - NASSP / Project Apollo - NASSP Development / Apollo 7: Calculating the CSI Burn (was "No P32 in A7 vAGC?") on: February 22, 2010, 04:49:39 PM
While attempting to run the Apollo 7 rendezvous sequence, I got to the point where it was time to set up the CSI burn.  I tried to call up P32, but all that happened was the "OPP ERR" light came on.  Am I correct in guessing that P32 wasn't available in Colussus 249? I've attached a scenario in case it's just something I'm doing wrong.

25  Project Apollo - NASSP / Project Apollo - NASSP Development / Apollo 7: Calculating the Corrective Combination Burn on: February 20, 2010, 07:54:07 AM
This is going to seem a bit rambling, so I apologize in advance Rolling Eyes

I've been playing around with STK (taking advantage of the 30 day trial of the Astrogator module), and after a week, finally got a Corrective Combination burn.  I'm going to try to do the same thing with GMAT, which has the advantage of being free (I'm afraid to ask what Astrogator costs Very Happy) but the disadvantage of being largely undocumented, AFAIK.  I'm hoping my knowledge of STK can transfer over...

A couple of things I've noticed--when inputting the state vector from Orbiter, I had to transpose the Y and Z values for both position and velocity to get the proper orbit.  This may be tied in to something I found when STK actually calculated the burn, which I'll go into in a moment.

Also, I found if I use the historic value of -5.7 fps for the phasing maneuver, I'm way too far ahead of the SIVB, which would require a significantly bigger burn to put the CSM in the correct position for CSI.  One of the wiki's mentioned that a -2.5 fps burn puts you in the correct position, so I used that, and it worked very well.

After running Astrogator, I got delta V's close to the historic values--about 6 fps off in X, 2 fps in Z, and within .5 fps in Y, but the signs are reversed for the Y and Z values.  My guess is that it has something to do with transposing the values from the state vector.  It's almost as if the two coordinate systems are mirror images of each other about the X axis.  Over the weekend, I'm going to try to do the actual rendezvous sequence, and see how it turns out.

The issue of the phasing burn value raises a question in my mind--as much as we want to fly "by the numbers", I suspect that there are going to be times when the "real world" numbers don't quite work in the Orbiter world.  Do we acknowledge that, and if so, how?
26  Project Apollo - NASSP / Support & Bugs / Re: No mission timer... on: November 12, 2009, 12:58:52 PM
Yes, there's a bug (related to the LM). I fixed it already in my local copy and will put it to CVS soon.


27  Project Apollo - NASSP / Support & Bugs / No mission timer... on: November 12, 2009, 02:57:42 AM
I've run into a problem trying to run the A7 vAGC scenario.  If I run the last released beta (09/19/2009), the mission timer works.  If I do a CVS update and rebuild the modules, no mission timer.  I'm not sure if I did something wrong in rebuilding, of if it's a bug somewhere...

If you need me to do some more testing, let me know what you want me to do.

28  Project Apollo - NASSP / Project Apollo - NASSP News & Discussion / Re: None on: October 16, 2009, 02:18:09 PM
Maybe it would be possible to somehow contact Eugene Cernan (Apollo 10 & 17 for those who don't know without asking Dr. Google). He is quite a chatty and nice guy and interested in lots of stuff I think. He even helped out estimating the Lunar Lander 3D simulator. So we might have a chance as well. But I don't know if he is available via emal/letter publicly. But he for sure still receives fan mail so we just would have to get an address. I'm sure he would be surprised about our detailed project and that somebody is working on a kind of memorial to keep the Apollo stuff and how it worked in peoples minds...

He's got a website:  It looks like Mark Larson is his agent.

Another possibility might be Dick Gordon at  Especially since he actually flew the CM...

29  Project Apollo - NASSP / Support & Bugs / Re: P54 0605 problem on: December 16, 2006, 12:01:01 PM
0634 R2 +00015 or +00030 pro
F 06 34 means: GET (not delta time) at wich you want the nominal att. So load R1: hrs; R2:min ; R3: centisec
0689 pro
You shouldn't pass through this noon while in nominal option!

Otherwise all you do seems good.

I use 1600x1200. Don't know if 1280 x1024 is good. It's not a 4/3 ratio but I don't know if it does matter something. May be you can try 1280x960?
Do you have some framerate issue, too?

  I run 1280X1024, and I don't have any problems getting the alignment down to .0000X.

  take care,
30  Project Apollo - NASSP / Project Apollo - NASSP News & Discussion / Re: Project Apollo's dead? on: November 08, 2006, 12:38:27 AM
And I'm still working on the "Apollo Familiarization Guide" (which will document which systems do what, and how they work together).  Within a week, I hope to have the electrical system and the ECS documented, at which point I'll upload what I've got, and keep working on the other systems.  You don't realize just how complicated Apollo actually was until you try and document it Happy

I'm another one of those people who, as dseagrav so eloquently put it, is getting his a$$ kicked by real life.  In just the past two months, I've supervised the move of the company that I work for, been flat on my back with the flu, and managed to dislocate a thumb Confused

Pages: 1 [2] 3 4
Powered by MySQL Powered by PHP Powered by SMF 1.1.10 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!