Meadville Space Center
Welcome, Guest. Please login or register.
July 06, 2020, 04:12:47 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 (Moderators: movieman, Tschachim, Swatch, lassombra)
| | |-+  vAGC Moon Ephemeris Update
« previous next »
Pages: [1] 2 3 Print
Author Topic: vAGC Moon Ephemeris Update  (Read 9221 times)
irnenginer
Project Team Member
Sr. Member
****
Posts: 271



View Profile
« on: May 27, 2007, 11:44:59 PM »

Since somebody asked me last week where I was on the question of moon positioning in the AGC I figured I should let everyone know where its at, it isn't, and where its going. Admittedly I have not had a lot of time to work on it as much as I wanted. But I have made some progress.

One of the big roadblocks has been in getting the scaling correct so the polynomials I generate well produce the right number. To that end I have been pouring over the AGC source code and figuring it out. The closest modern equivalent is assembly language, which I took in college a good time ago. The code has revealed some good results at least in giving some information on PAD loaded variables We already know about:

TEPHEM: This is the time of launch. There is an issue with this number as it stands. At launch P11 takes TEPHEM, adds the CSM clock value and then stores the result back in TEPHEM. That means that TEPHEM needs to be loaded with a value of when the CSM clock was started on the ground during prelaunch.

TIMEMO: This number should be loaded as a negative number. This is because the vAGC only adds triple precision numbers.

The polynomials: This is where things are pretty slow. Until I am sure of the scaling and I can verify the result, I am shooting in the dark as to whether a set will work or not. I have found a better way of producing them with better accuracy. I have access to MATLAB (a very high end math program) at work. Unfortunately that means I can only use it when I have the time at work, which is not too often.
Logged
Christophe
Project Team Member
Hero Member
****
Posts: 1072


View Profile Email
« Reply #1 on: May 28, 2007, 11:22:02 AM »

Thanks for the informations irnenginer.
Keep up your work.  Thumbs Up
Logged
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #2 on: May 29, 2007, 08:10:11 AM »

Hi Irnenginer,

thanks a lot for the update!  Happy

TEPHEM: This is the time of launch. There is an issue with this number as it stands. At launch P11 takes TEPHEM, adds the CSM clock value and then stores the result back in TEPHEM. That means that TEPHEM needs to be loaded with a value of when the CSM clock was started on the ground during prelaunch.

Let's see if I understand that correctly: The current TEPHEM (a.k.a "Time of Launch", EMEM 1706-1710) is set in the Apollo 7 and 8 scenario with respect to the real liftoff time, that means the issue would be solved if the AGC clock (N36) is reading 0 at liftoff, which it doesn't currently but reads the time since the AGC was turned on, which is variable. Since the AGC clock value is stored in EMEMs (do you know the positions?) it would be possible (and quite easy) to change the Saturn so that it:

- sets the clock to zero just before setting the liftoff discrete
- sets the clock to a negative value (which seems to work) during AGC turn on so that the clock reaches zero at liftoff (assuming it's not turned off again normally)

Do you think that would work? I'd prefer the 2nd solution because we won't "cheat" by changing the memory after the AGC is turned on and we'd get a nice countdown.  Happy

TIMEMO: This number should be loaded as a negative number. This is because the vAGC only adds triple precision numbers.

Sorry, I don't understand that, what is TIMEMO?  Confused

Cheers
Tschachim
Logged

irnenginer
Project Team Member
Sr. Member
****
Posts: 271



View Profile
« Reply #3 on: May 29, 2007, 10:46:03 AM »

I am not sure how best to deal with setting TEPHEM. It can be as simple as some extra steps in the prelaunch checklist. I not too hot on setting the clock negative because I do not know how it would react to that, nor is it how it was done for real. I believe that during prelaunch there was some ground control updates that happened without Astronaut input that took care of this. There are also some routines for adjusting the clock. I still have to look into how best to implement this.

Since as you said TEPHEM is not a constant, the AGC needs a set common time reference for the polynomials. That time, set at the mission midpoint roughly, is TIMEMO. Think of it as the zero intercept point of the polynomial equation.

I also discovered that the scaling I have for both TEPHEM and TIMEMO are both off.
Logged
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #4 on: May 29, 2007, 11:30:30 AM »

I am not sure how best to deal with setting TEPHEM. It can be as simple as some extra steps in the prelaunch checklist.

Yeah, of course it could be done manually, but I would like to avoid to set the time manually. To avoid negative time we also could calculate TEPHEM to for example 6 hours before launch and set the clock during turn-on so it will be at +6h at launch or something like this.

Since as you said TEPHEM is not a constant, the AGC needs a set common time reference for the polynomials. That time, set at the mission midpoint roughly, is TIMEMO. Think of it as the zero intercept point of the polynomial equation.

Thanks for explaining!  Happy

I also discovered that the scaling I have for both TEPHEM and TIMEMO are both off.

Do you expect a huge error? I ask because the initial P52 REFSMMAT is within a few degrees usually and as far as I understand that the AGC needs TEPHEM to calculate star positions. Anyway, I'll wait for your results before changing anything in the code, please tell us if we can help!

Cheers
Tschachim
Logged

Christophe
Project Team Member
Hero Member
****
Posts: 1072


View Profile Email
« Reply #5 on: May 30, 2007, 07:27:20 AM »

Additionnally I noticed that the vAGC position goes wrong while doing a state vector update. Could this be related with a wrong tephem too?
Logged
irnenginer
Project Team Member
Sr. Member
****
Posts: 271



View Profile
« Reply #6 on: May 30, 2007, 11:20:03 PM »

I am not sure TEPHEM would impact the state vectors. Can you be more specific with the issue.

There is something you programmer types could do for me. I could really use the ability to do a yaAGC compliant core dump so I could do some debugging of the code with a solid orbiter based starting point. the makecoredump is there but I do not know enough about it or the rest of the code to get it to work when running in orbiter. Any insight would be greatly appreciated.
Logged
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #7 on: May 31, 2007, 04:44:09 AM »

There is something you programmer types could do for me. I could really use the ability to do a yaAGC compliant core dump so I could do some debugging of the code with a solid orbiter based starting point. the makecoredump is there but I do not know enough about it or the rest of the code to get it to work when running in orbiter. Any insight would be greatly appreciated.

I'm happy to help and will take a look at that.  Happy

Cheers
Tschachim
Logged

Christophe
Project Team Member
Hero Member
****
Posts: 1072


View Profile Email
« Reply #8 on: May 31, 2007, 05:49:40 AM »

Quote from: irnenginer
I am not sure TEPHEM would impact the state vectors. Can you be more specific with the issue.

I just wanted to point out the fact that the vAGC is pretty accurate right after orbit insertion as long as you don't update the state vector. However as soon as you make a P27 state vector update the vAGC seems to loose their accuracy gradually. Allthough it's a long time ago I did that experience in NASSP and may be the issue is not present anymore.
My doubt is that, when you do the P27, you enter the time you picked up in orbiter and I believe that the vAGC is not exactly at the same date.
May be i'm wrong I just want to try to understand why things sometime go wrong.
Logged
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #9 on: May 31, 2007, 09:53:10 AM »

OK, I introduced a core dump button on the ProjectApolloMFD. I'm going to commit this (and my other changes) as soon as possible, I'm still testing and reviewing my stuff. Meanwhile as a first test I attached a core dump file together with a scenario saved shortly after, it's Apollo 7 on the pad running P02. I hope "our" yaAGC and the real yaAGC are still compatible enough...

Cheers
Tschachim

* ProjectApollo CMC.zip (11.34 KB - downloaded 148 times.)
Logged

irnenginer
Project Team Member
Sr. Member
****
Posts: 271



View Profile
« Reply #10 on: May 31, 2007, 05:37:35 PM »

I checked your core dump with yaAGC. It works perfectly Thumbs Up

You rock!
Logged
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #11 on: May 31, 2007, 05:55:49 PM »

Cool, thanks!  Happy

I'll try to hurry with new beta modules...

EDIT: Beta modules released, button is explained in the wiki.
« Last Edit: June 07, 2007, 12:56:37 PM by Tschachim » Logged

irnenginer
Project Team Member
Sr. Member
****
Posts: 271



View Profile
« Reply #12 on: June 13, 2007, 03:56:44 PM »

A Possible Breakthrough. Very Happy

After banging my head against the wall Bangs Head for some time I think I have made good progress on the Moon Ephemeris. With Tschachim's help of adding a vAGC core dump I was able to follow the code as it calculated the moon state vectors. I was able to determine the proper scaling of all the data and used that to produce a new set of polynomials using MATLAB. At this point I can observe that the position vector generated by those polynomials match very well to the data.

The only problem at this point is that when used to point the optics towards the moon it does not point to the moon. This may or may not be a problem since my current thought is that since I also revamped TEPHEM (which currently improperly scaled) that my state vectors and orientation might of been off. I will try again after work by realigning and updating the state vectors before I try finding the moon and see how good it is then.

The good news is that at this point it is mostly an issue of getting the right data to base the moon position off of.

Stay tuned. Thumbs Up

Logged
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #13 on: June 13, 2007, 04:49:08 PM »

Cool, that sounds very promising!  Thumbs Up
Logged

irnenginer
Project Team Member
Sr. Member
****
Posts: 271



View Profile
« Reply #14 on: June 13, 2007, 08:09:18 PM »

OH MAN I AM SOOOOO CLOSE

After realigning and updating the state vector I tried again. The attachment shows the where the AGC thinks the moon is. As you can see the moon is in the optics FOV just barely. If you look closely the difference between were the AGC thinks the moon is and where the moon actually is the difference between the equatorial a and ecliptic planes!  Duh!



* MOON.jpg (100.56 KB, 683x691 - viewed 244 times.)
Logged
Pages: [1] 2 3 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!