Meadville Space Center

Project Apollo - NASSP => Programming => Topic started by: indy91 on February 24, 2015, 05:57:29 PM



Title: Apollo RTCC MFD
Post by: indy91 on February 24, 2015, 05:57:29 PM
The RTCC MFD is now part of Project Apollo - NASSP, so no need to download any version in this or other thread.

In this thread I will post the newest versions of my Apollo RTCC MFD. So far I have attached the newest file randomly to my posts, but I don't think that is a very good idea. So don't look any further, this is the place to download from now on.  :D

Currently the features of the MFD are:

-Calculating a Lambert-targeted Maneuver (Useable for the Apollo 7 phasing, NCC1 and TPI maneuvers)
-Calculating coelliptic maneuvers (Usable for the Apollo 7 NSR burn)
-Calculating Orbital Adjustment burns (Can be used for the Apollo 7 SPS burns no. 3-7)
-Calculating Deorbit and trans-earth Midcourse Correction burns (based on the P37 precision trajectory computations, also calculates the ignition time and splashdown coordinates.)
-Calculating the IMU transformation matrix (REFSMMAT) for the Alignment for Thrusting Maneuvers, Landing Site, Passive Thermal Control (PTC), Reentry Maneuvers and Alignment to Local Vertical at a specified time.
-Uplinking to the AGC the solutions for: CMC Desired REFSMMAT Update, CMC External Delta V Update, CMC Retrofire External Delta V Update, CMC Entry Update
-Displaying the Maneuver PAD and Entry PAD for a burn or reentry calculated with the MFD



Just a quick explanation of the newest as of right now quite outdated Reentry and REFSMMAT feature:

Open the "Apollo 7 at 4h09m GET.scn" file (or your own save around that time) and follow the Apollo 7 Preliminary Flightplan. At 04:45 GET there is a big Mission Control update. First let's do a state vector update with the Project Apollo MFD and then let the UPTLM CM switch in the Accept position. Open the Apollo Rendezvous MFD and go the the Entry screen. There you have to type in the desired landing coordinates and a predicted deorbit time. The landing site no. 4(?) has a longitude of about -162, which is 162W. The latitude number isn't currently used in any calculation, but if you know the actual desired splashdown coordinates, you can use that number as a reference.

The estimated 6-4 deorbit burn GETI is at 8:55 GET, but because the ignition time prediction is kind of tricky atm, a number larger than 009:00:00GET will predict a deorbit burn during the correct orbit and not an orbit too early.

Press CLC to calculate the burn and new landing coordinates. I get these numbers: DV components -619.4 +0.0 +155.8, displayed in the P30 format and in feet per second. The predicted splashdown coordinates. 27.38 N, 162W. Press UPL to start the P27 uplink program. Now that the AGC is busy with getting the new data, go back to the main menu and go to the REFSMMAT page. There you can calculate the reference matrix for the deorbit burn that gets used for the next few hours. Press OPT to change the option to "P30 retro" and press CLC to calculate the matrix. If the MFD has finished uplinking the reentry burn data you can then uplink the new REFSMMAT, too.

With the MCC Update finished, continue with the flight plan. The important parts are the P30 External Delta V and the P52 option 1 realignment. At about 7:30GET you get a No-Go for 17-1 (because of a malfunction, or Deke Slayton fired Wally Schirra on the fly or something like that) and you have to deorbit at the calculated time. Do the usual reentry preparations and hope, that my MFD did a good job with the deorbit burn. If the REFSMMAT is correct and the S/C Roll is at 180, P40 should come up with exactly 180, 180, 0 for the deorbit burn.


Title: Re: Apollo Rendezvous MFD
Post by: eddievhfan1984 on February 24, 2015, 07:31:57 PM
Coolness, although I think "Apollo RTCC MFD" might be a better title at this point. LOL


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on February 26, 2015, 09:50:15 AM
Haha, I guess that is true. It just seemed a little bold to me, to call it that :ashamed45523:

Also, I didn't want to rename it yet again. If it ends up being the Apollo Rendezvous MFD, Apollo RTCC MFD, or part of the Project Apollo MFD. I can do either of these things, but I don't feel it is up to me to decide that. I do whatever you guys think is the best way for a release. I'm good at the complicated math behind it all, but not so much making it user friendly. I personally don't like juggling with 20 different MFDs  :ROTFL3453:


Title: Re: Apollo Rendezvous MFD
Post by: eddievhfan1984 on February 26, 2015, 01:11:45 PM
I do have a Lambert targeting routine question I'd like to ask, though: is there a routine that can be written for doing minimum-dV targeting? I mean, it's relatively straightforward in NASSP, since the times and targets are historical, but just something I was thinking of...


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on February 26, 2015, 02:51:33 PM
Hmm, what kind of scenario do you have in mind?

Solving Lambert's problem is essentially the determination of an orbit from two position vectors and the time of flight. So there are a few parameters you can change to find a lower Delta V. In the optimal case, you usually end up with something like a Hohmann transfer (180 transfer) or something like the Stable Orbit Rendezvous technique (360 transfer), used for the Space Shuttle.


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on March 31, 2015, 06:35:09 AM
So I have implemented the P37 precision trajectory calculations and it's basically what P37 does, but it is all in a loop to find the correct time for the deorbit maneuver. That leads to a problem, because it is a lot of calculations that has to be done in an instance. So Orbiter often freezes for a second or two after pressing the calc button. I'm not experienced enough with Orbiter and C++ to know the perfect solution for this, but I guess I will have to modify the function so that it spreads the calculations out over a few steps.

I also looked at what is missing to get a complete P30 Maneuver PAD and relatively easy I could implement the sextant star check. It only works with the REFSMMAT and External DV calculated in my MFD so far, but I can take the REFSMMAT out of the equation, I guess. Usually all maneuvers are done heads-down (if possible), except the reentry burn, right? Of course if it is desired to calculate the IMU gimble angles, too, I would need to somehow get the REFSMMAT currently stored in the CMC. And if I manage to do that, then my MFD has become a proper RTCC MFD :D


Title: Re: Apollo Rendezvous MFD
Post by: eddievhfan1984 on March 31, 2015, 06:02:26 PM
Well, it should be possible to downlink the REFSMMAT coefficients from the AGC, or so I imagine (I'm assuming you're not using the "ground" reference to determine the gimbals, but the current IMU alignment + drift). As for the freeze-up, the problem may be that the steps performed in the MFD temporarily take priority over the other Orbiter functions. Off the top of my head, I figure if you could get it running in parallel or on a lower-priority task, it would solve the freeze, because Orbiter does the same thing during CSM/LV sep or an abort initiation.


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on April 02, 2015, 09:39:26 AM
I "solved" it by improving the coasting integration function. The accuracy parameter I used was kind of overkill, it was basically a modified coasting integration routine of the AGC, but with the accuracy 10x higher. I set that number a little bit lower without any real impact on accuracy. And each iteration to find the deorbit time and DV vector is now called on successive frames. I currently use a crappy netbook, so for most people it should be ok. I guess I will know, when people other than me have tested it.

Another result of the improvements of the coasting integration function is that it now works in cislunar flight, i.e. it takes the gravity of the Sun and Earth into account, when the CSM is on the edge of the Moon's sphere-of-influence. With that I can now calculate e.g. a LOI REFSMMAT long before the spacecraft reaches the moon. An accurate LOI-2 REFSMMAT would be a real challenge though, because there are two maneuvers (MCC-4 and LOI-1) between the historic time of uplinking that REFSMMAT and LOI-2. At this time I don't see the need to calculate all of that just to get it really, really accurate. What my MFD can currently calculate is perfectly fine to use with the ORDEAL, which needs an in-plane alignment.


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on April 07, 2015, 11:22:02 AM
Update: I have done significant modifications to the trajector propagation method of the MFD. It should now work in the whole Earth-Moon-System.

The reentry maneuver calculations do now include the precision part of P37, so it should be very accurate.

I have also added the sextant star check. And with that my MFD could basically calculate a whole Maneuver PAD?! I have been thinking about this a little bit, I think it would be pretty nice, if my MFD could output a finished Maneuver PAD and Entry PAD. I mean, I like the "going through extensive checklists" part of flight simulators and while a complete PAD is not really necessary to perform a maneuver with NASSP, it would be more realistic. Anyway, I hope for some feedback on the updated MFD :)


Title: Re: Apollo Rendezvous MFD
Post by: jalexb88 on April 08, 2015, 02:29:06 PM
Hey indy91, nice work!

About the maneuver pad, impressive work on the sextant star check, I guess the last thing for the pad would be to get the RPY gimbal angles for a given P30/40/41 maneuver so we could use V49 to manually enter the angles before using P30/40/41. Maybe something like a conversion page that shows what the RPY angles are for a given Vx,Vy,Vz.

Alex


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on April 08, 2015, 04:12:38 PM
Thanks! Yes, I think that would be possible. The IMU angles depend not only on the Delta V vector of the burn, but also the currently used REFSMMAT. A maneuver that uses one of the two types of maneuver REFSMMAT my MFD can currently calculate ("P30" and "P30 retro") has always the same RPY angles anyway: 0, 0, 0 and 180, 180, 0 respectively. But of course the platform is not always aligned with a burn attitude. During the entire Apollo 7 rendezvous it kept the same alignment. That alignment came from a P52 option 2 (nominal alignment), which was done at 23:05h GET with a T-Align (N34) of 23:24:08 GET.

My MFD can calculate a nominal REFSMMAT, too, it's the option "LVLH", alignment to the Local Vertical, Local Horizontal at a specified time. So what I could do without knowing the REFSMMAT currently stored in the CMC, is use that to reproduce the alignment in the CMC with my MFD. You would just need to do a P52 option 2 and then calculate the LVLH REFSMMAT at the exact same GET and then calculate the IMU angles from that. I will try that and report back.


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on April 09, 2015, 05:02:57 PM
Another Update to my MFD: I fixed a few bugs in the Entry Targeting and more importantly added a Maneuver PAD page. It's not very pretty yet, but it has most of the relevant information. To test the newest features I suggest trying this sequence:

1. Launch Orbiter with the "Apollo 7 at 23h GET" scenario from the zip file.
2. Open the Apollo Rendezvous MFD and calculate the Lambert-targeted NCC1 burn as usual (you'll find how to do this in the manual).
3. Then go to the REFSMMAT page, change the option to LVLH and calculate a nominal alignment for 023:24:08 GET (the historical alignment Apollo 7 had for the Rendezvous sequence). Now the MFD knows which alignment the CMC will have.
3. Do a P52 option 2 with the same T-Align.
4. Go to the Maneuver PAD page of the MFD and choose the option "Heads-Up" and press CLC to calculate the missing numbers of the Maneuver PAD.
5. Perform a Crew Defined Maneuver with V49 and use the RPY values on the bottom the Maneuver PAD page (don't forget that the fomat is XXX.XX).
6. Once you have reached the correct attitude and you see the flashing 50 18 press ENTR to clear the DSKY.
7. Now the sextant star check: Make sure the Optics are in CMC mode, key V41 N91E and then the two angles (shaft and trunnion) from the Maneuver PAD page. If everything went well you can now see the star in the sextant.

I will think about options to make the page look a little bit less cramped. And I guess the next update to my MFD will be the Entry PAD, which isn't that much more work, now that I know how to do that kind of stuff.  :ThumbsUp432:


Title: Re: Apollo Rendezvous MFD
Post by: jalexb88 on April 10, 2015, 03:10:54 PM
The PAD page is quite impressive, I've been waiting a while to see something like this! Your procedure worked flawlessly. About the REFSMMAT, and I think you mentioned this but would it  be possible for your MFD to read the current REFSMMAT stored in the CMC? Also, I noticed the REFSMMATs calculated in the MFD are not saved in the scenario files meaning that we always have to calculate a new one for the PAD (and do an P52 option 2) when reloading a saved mission, or is there another way to recover a REFSMMAT previously used by your MFD in an earlier session? I think this would be a non issue if the REFSMMAT is read straight from the CMC. Hope that all made sense.

Alex


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on April 10, 2015, 05:22:13 PM
The MFD can already uplink data to the CMC, so downlinking stuff like the REFSMMAT should be possible. I have just not found out how to do it properly. I'm not sure, if I have to do a whole downlink procedure like the GroundStation.exe, or if there is any easier way to access data stored in the computer. But recreating the REFSMMAT with my MFD, as described in my post above, is only the temporary solution.

As for saving the state of the MFD, that is something I am really not looking forward to do, even though I probably should implement that at some point. There are sooo many variables already in the MFD and I guess I would have to rewrite the code a lot to save it with the scenario.

And for anybody wanting to try the Entry Targeting functionality of the MFD: I have discovered a few problems with it. It will work in exactly 50% of all cases, but it also might freeze the simulation or produce nonsense. I haven't yet found the source of the problem though...


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on April 12, 2015, 03:05:43 AM
I've fixed the problem with the reentry calculation (I think) and added a very basic Entry PAD with only the numbers that were straightforward to calculate.

I haven't gotten around to add the whole Entry procedure with my MFD to the manual yet. You give it an estimate of the Deorbit Burn time of ignition and the desired splashdown longitude and reentry angle and it will give you the correct TIG, splashdown coordinates and deorbit burn numbers. Uplink the data and you will have the numbers for P30 and also Noun 61 (splashdown coordinates) in the CMC. Then calculate the Retrofire REFSMMAT with the option "P30 retro", uplink that too, and do your usual reentry stuff. In theory the calculations should be more accurate than P37, because P37 assumes an oblate Earth. I have gotten pretty good results so far.


Title: Re: Apollo Rendezvous MFD
Post by: jalexb88 on April 12, 2015, 04:55:55 PM
Good stuff, the entry targeting is working good on my end  :ThumbsUp432: It even seems to work on lunar return flights. I tested it at 103 hours in the Apollo 8 flight plan just before MCC-5 and it gave me good numbers and both the maneuver and entry pads looked good.
Would a page for manual Delta V entry be possible? IE. In Apollo 8 we can calculate a mid-course burn with LTMFD, then run the velocities through your MFD to get the PAD. I think that would be a winning combination. Once again nice work!

Alex


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on April 13, 2015, 04:12:02 AM
I'm surprised it works on lunar flights, because it changes the TIG to find the right splashdown longitude. For a Midcourse Maneuver it's better to have a fixed TIG and then change the Delta V of the burn until the splashdown longitude is correct. Calculating MCCs can be done with P37, too, so there isn't really much I have to change to implement that in my MFD. I guess the advantage over LTMFD or IMFD would then be, that my MFD can calculate the splashdown conditions and not only the Entry Interface. I haven't messed around with that too much, how do you find the correct values for the splashdown coordinates, if you are not using P37?

The Entry PAD looked actually a little bit different on lunar return flights. They usually got a preliminary version before the last MCC and the final Entry PAD after the burn. I would have added a Lunar Entry PAD option to my MFD anyway and I guess calculating it with manual Delta V data, instead of an internally calculated maneuver, is pretty easy.


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on April 16, 2015, 05:32:04 AM
I was thinking something, currently you have to do a lot of inputs as a user to use the MFD. But, if this becomes a proper RTCC MFD at some point, is that really a good thing? An user/astronaut doesn't have to know how the Apollo 7 NCC maneuver was calculated. Wouldn't it be more realistic, if the MFD just calculates the numbers for uplinked data and for PADs and all the user would see is the uplink button and the PAD?

Basically, the necessary inputs for calculating e.g. the NCC maneuver would already be stored in the MFD and, based on the current phase of the mission, it would do all the ground calculated stuff and ask the user "are you ready to receive a CMC update?" This would make the MFD easier, more realistic and it would give me as the developer more freedom to do complicated things, that the average user doesn't need to see. But it would also lead to less flexibility and possibilities for the user. What do you think?


Title: Re: Apollo Rendezvous MFD
Post by: jalexb88 on April 16, 2015, 12:39:24 PM
I have thought of that myself, I guess thats what we should be aiming for and I do think that less MFD interaction is more realistic. That being said for the other burns like Apollo 8 MCC's and LOI/TEI, we still need LTMFD and such so I maybe automate the Apollo 7 calculations, but add a page for manual Delta-V input for the burns the MFD cant yet do. Just a thought. Are you planning on adding Apollo 8 burn programs?

Alex


Title: Re: Apollo Rendezvous MFD
Post by: meik84 on April 17, 2015, 12:35:33 AM
My thoughts on that are quite ambivalent: sure, it is more realistic when we automate the 'ground work' to a simple push of a button. But on the other side I wouldn't like to loose the flexibility and possibilities to experiment the manual approach offers. Just imagine, you could fly a fictive Apollo mission that launches at your very birthday. Or fly Apollo 13 how it was supposed to fly. Or, or, or...
One of the advantages a simulator offers is that your imagination (and physics, in our case) is the limit. Self- imposed boundaries would thwart that. It's still about the fun, boys. :wink:


Title: Re: Apollo Rendezvous MFD
Post by: jalexb88 on April 17, 2015, 01:21:13 AM
How about something that combines less MFD interaction with flexibility. Say we put all those burn parameters in a separate config file, a script that can be read by Apollo rendezvous or an ''RTCC MFD''. The config file can be configured to whatever parameters we want but its all done before the mission is started. Opening an MFD in a CSM definitely does take away the immersion of simulating late sixties era space flight.

Alex


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on April 17, 2015, 04:45:19 AM
I guess I won't make any big changes for now. The MFD is still in "demonstrating that it can be done" mode, so no real need for an overhaul like that. Just a thought for later versions.

That being said for the other burns like Apollo 8 MCC's and LOI/TEI, we still need LTMFD and such so I maybe automate the Apollo 7 calculations, but add a page for manual Delta-V input for the burns the MFD cant yet do. Just a thought. Are you planning on adding Apollo 8 burn programs?

Alex

I can add a manual Delta-V input for the Maneuver PADs, sure. If my MFD would be integrated into Project Apollo MFD, then there even is the "request burn data" feature, which is pretty nice. But it only works with IMFD, so I can't send any data to the PAMFD with my MFD.

Maybe I will add the capability for LOI/TEI burns at some point, but right now IMFD or LTMFD are still way superior tools for that. The only thing that I want to do, that currently is done with IMFD, is calculating trans-earth MCCs. The reentry calculations in my MFD use routines from the GSOP documents for the CM reentry, so aiming precisely for a splashdown location from lunar entry will soon be possible (I hope).


Title: Re: Apollo Rendezvous MFD
Post by: jalexb88 on April 17, 2015, 02:53:16 PM
Yes LTMFD excellent for those burns. Your MFD is very complete as it is thanks again for the hard work. About the "request burn data", could that button be in your MFD, then it pulls the data straight from IMFD/LTMFD, instead of going through PAMFD first? Again just a thought.

Alex


Title: Re: Apollo Rendezvous MFD
Post by: pattersoncr on April 17, 2015, 08:29:41 PM
Indy91, I cannot thank you enough for producing your MFD. It perfectly fills what has been an insurmountable stumbling block we've had since I first started messing around with NASSP over six years ago!


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on April 18, 2015, 03:17:42 AM
You are most welcome! My hope is, now that this stumbling block isn't there anymore, that development on NASSP will increase again. Eventually I would run out of stuff to do as far as MCC calculated numbers are concerned, if I can only work on Apollo 7 and 8.  :ROTFL3453:


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on April 19, 2015, 12:12:32 PM
I guess the next update will be called the "Lunar Entry Update". The features will be:

-Calculating trans-earth Midcourse Correction maneuvers, precisely targeting the desired splashdown longitude.
-Calculating the Entry REFSMMAT (not to be confused with the Deorbit/Retrofire REFSMMAT). Even works just after TEI, but only if you manually change the gravity reference from Moon to Earth.
-Lunar Entry PAD. Not complete by far, but a few of the most important numbers are there. I also changed the Earth Entry PAD to the format used after Apollo 7. Most PADs are different in the Apollo 7 Flight Plan from all the other missions, so I chose not to use the Apollo 7 PADs just for this one mission.
-Manual TIG/DV input for the Maneuver PAD. Now you can calculate the PAD even without calculating the maneuver in my MFD. But without the REFSMMAT being the same as the one stored in the CMC, the IMU angles and sextant star check won't make any sense.

I want to finish my own Apollo 8 mission first before releasing the update, so I can test it a little bit more. I have flown a few lunar entries in the past months, but I always used quicksaves I downloaded from here. Flying a whole misison takes quite some time, but soon I will have finally flown the complete Apollo 7 and 8 missions.  :ThumbsUp432:

EDIT: And a few comments I have about certain figures from the PADs, I am not sure how to calculate yet:

Maneuver PAD

What is the guideline for using the SPS or the RCS for a maneuver? Because the SPS has an offset, that would be important for the IMU angles calculated for the maneuver. Should I let it automatically decide, that every burn above X ft/s will be with the SPS, or should I add this as an option?

Boresight Star Check: I know the geometry for this, but I am not sure, if the COAS would support this right now. I could calculate the star, that is closest to the boresight, but not the "BSS Pitch Angle" and "BSS X Position" from the PAD. It's not really important, so this has no priority.

Entry PAD

Entry Attitude Horizon Check: I guess this is just a bit of additional geometry, but I haven't thought about this too much. The 31.7 line is supposed to be aligned with the horizon, right?

0.2G Time, Blackout Times, Drogue Time etc. : Would be quite difficult to calculate I guess. Not really important though.


Title: Re: Apollo Rendezvous MFD
Post by: jalexb88 on April 19, 2015, 12:25:12 PM
Awesome!  :ThumbsUp432: About the REFSMMAT not being the same, from what I see your MFD does a pretty good job of replicating the required ones. If we calculate it with the MFD, then upload it though an option 1, we should be good, as long as we finish all required burns with that REFSMMAT in the current session without closing.   EDIT: Saw your question about the PAD and I may be able to chime in for the SPS/RCS criteria. I don't know if you've seen this chart its from the G & C checklist.

EDIT 2: In the State Vector page, maybe an option to update the S4B aswell?

Alex


Title: Re: Apollo Rendezvous MFD
Post by: eddievhfan1984 on April 20, 2015, 01:38:26 AM
Awesome-sauce for the lunar update. The 31.7 horizon line is really only used for Mode IV aborts and coarse entry pitch alignment. In Mode IV, it's the LV pitch attitude used for the SPS burn to boost to contingency orbit. For entry, it's just used as a default pitch attitude to ensure the capsule will stabilize blunt-end forward, even if the platform goes kaput. The IMU alignment is still referenced to EI time, regardless.


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on April 20, 2015, 01:16:42 PM
I uploaded the newest version. Here a short explanation of what is new.

REFSMMAT

The option to calculate the Entry REFSMMAT. Make sure the gravity reference is set to Earth on the Configuration page. The accuracy of this REFSMMAT calculated while still quite close to the Moon is not perfect though.

I also found out how to save data to the scenario and it is easier than I thought. Currently only the REFSMMAT (in decimal and octal) is being saved.

Entry Targeting

I added targeting for a Midcourse Correction maneuver. Type in the desired time of ignition, splashdown longitude and reentry angle at Entry Interface and it (hopefully) will come up with a solution. I still haven't really solved the problem of the freezing simulation while doing this, but it's a tradeoff between accuracy vs. speed without having to rewrite half of the code.

If you press "MOD" you will see the "Entry Update" page. This is based on the P27 CMC Entry Update. It will only calculate the splashdown coordinates for the current trajectory without a maneuver, so that the downrange and crossrange error at the beginning of P67 are close to zero. I added this before, but never explained it.

Maneuver PAD

I added an option for a maneuver with the SPS or the RCS (4 Jets).

Entry PAD

New is the Lunar Entry PAD. You have the option to calculate the PAD with a "direct" reentry or a reentry following a MCC calculated with the MFD. This is quite nice, because if you calculate the last MCC and it comes up with a really small burn, you can compare the "Direct" and "MCC" PADs and decide, whether a last MCC before reentry is even necessary. The Earth Orbit Entry PAD doesn't have this option, because a deorbit burn is an essential part of the entry procedure.

All in all, with the newest update there are also more possibilities to crash Orbiter by using the wrong inputs. I guess I should work on preventing that kind of stuff.

EDIT 2: In the State Vector page, maybe an option to update the S4B aswell?

I only added the state vector update to find out how accurate Project Apollo MFD can do this. It works perfectly fine, so no need to use my MFD for it. But I remember reading about state vectors uplinked for specific times, so maybe that's where my MFD will come in handy. But not for Apollo 7 or 8.


Title: Re: Apollo Rendezvous MFD
Post by: meik84 on April 20, 2015, 04:49:20 PM
Quote
In the State Vector page, maybe an option to update the S4B aswell?
That would assume that the LVDC++ has an SV update capability, which it hasn't yet. Shame on me, I'm not yet done with the load/save stuff -being the head of a (soon four-person) family is quite time consuming.
However, updating LVDC's SV would require a transformation matrix from orbiter to PACCS13, something I haven't figured out correctly yet. I think that I understand what is wrong with my matrix -but I don't know how it is done right. :(


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on April 20, 2015, 05:08:27 PM
I assumed he was talking about the general "other" state vector slot, which, in most cases for NASSP right now, is used for the S-IVB on Apollo 7.

transformation matrix from orbiter to PACCS13

That sounds kinda scary  :ROTFL3453:

Is there any document about that? Maybe I can come up with something about this transformation.


Title: Re: Apollo Rendezvous MFD
Post by: meik84 on April 20, 2015, 05:53:28 PM
See here, p.44. Note that PACSS13 relates to PACSS12 which relates to PACSS10. 'Reference ellipsoid' is, from my understanding, 1960 Fischer's ellipsoid.


Title: Re: Apollo Rendezvous MFD
Post by: jalexb88 on April 20, 2015, 06:19:12 PM
Yes the ''other'' SV update slot for S4B state vector updates but as you said PAMFD does the trick. I just tested a few burns out near the moon, looks like it works quite good.  :ThumbsUp432: I would just like to point out that sometimes the TIME entry on various pages, REFSMMAT, PAD, etc. does not enter correctly. For example I was calculating Apollo 8 MCC-1 and on the Maneuver Pad page I put 010:59:59 in TIG, it however displayed a value of +00019 +00051 +05900. Sometimes the REFSMMAT page would do the same thing.

Alex


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on April 21, 2015, 03:43:39 AM
I would just like to point out that sometimes the TIME entry on various pages, REFSMMAT, PAD, etc. does not enter correctly. For example I was calculating Apollo 8 MCC-1 and on the Maneuver Pad page I put 010:59:59 in TIG, it however displayed a value of +00019 +00051 +05900. Sometimes the REFSMMAT page would do the same thing.

I had it happen on the Lambert page, too, but not consistent enough to find the problem. I will look into it.

See here, p.44. Note that PACSS13 relates to PACSS12 which relates to PACSS10. 'Reference ellipsoid' is, from my understanding, 1960 Fischer's ellipsoid.


One transformation matrix? That is many transformation matrices  :ROTFL3453:

Actually I think it is four transformations:

1.Orbiter Ecliptic to Equatorial rotating (basically the oapiGetRotationMatrix at a specific time).
2. Left handed to right handed coordinate system (this just switches the y and z component of a vector)
3. Equatorial to local horizon (North-East) coordinate system
4. Local horizon to Earth Fixed Launch Site PACSS10 (a rotation around the x-axis so that the z-axis points into the direction of the aiming azimuth)

And PACSS10-13 all have the same rotation matrix, at least at the reference time.


Title: Re: Apollo Rendezvous MFD
Post by: jalexb88 on April 21, 2015, 08:56:58 AM
I had it happen on the Lambert page, too, but not consistent enough to find the problem. I will look into it.

If this can help pin point it, for the REFSMMAT page Ive notice when this happens, if I use the LEFT MFD the entry goes in fine, but not the RIGHT MFD.


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on April 21, 2015, 09:37:59 AM
Hmm, I am not really able to reproduce it, I get the problem sometimes, but there doesn't really seem to be a system behind it. I changed the input method for GET numbers to something a little bit more elegant and now I don't get the issue at all. Maybe that fixed it?


Title: Re: Apollo Rendezvous MFD
Post by: jalexb88 on April 21, 2015, 10:11:42 AM
Hmm, I am not really able to reproduce it, I get the problem sometimes, but there doesn't really seem to be a system behind it. I changed the input method for GET numbers to something a little bit more elegant and now I don't get the issue at all. Maybe that fixed it?

That fixed it  :ThumbsUp432: With this new tool I tell you, these days my daily routine is eat, sleep, Orbiter. Thankfully the NHL playoffs are there to distract me a bit lol.


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on April 21, 2015, 03:21:53 PM
Haha, if you run out of missions to fly, then you could try the Apollo 8 TLI+90 and TLI+4 hours abort maneuvers. You can basically already do that with the entry targeting, but it would take 24 hours longer to splashdown compared to the PAD data from Apollo 8, because the MFD tries to find the solution with the lowest DV. These two maneuvers (although you would have to calculate them after TLI) would require almost no additional work on the MFD.


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on April 23, 2015, 06:25:53 AM
Three small additions to the MFD:

1. I added the Launchpad REFSMMATs for Apollo 7 and 8 as the default REFSMMAT for those missions. So the Maneuver PAD can calculate IMU angles for a burn even without the need to uplink a REFSMMAT to the CMC. Apollo 7 kept the Launchpad REFSMMAT until 4:45 GET and Apollo 8 almost all the way to the moon.
2. The MFD can now internally calculate the reentry angle, if you leave it to 0 on the Entry page. This is based on the padload values for P37, so not necessarily the nominal ground calculated reentry angle.
3. An "Abort" option for the Entry targeting. This is basically the same calculations as a midcourse maneuver, but it will try to find the fastest return while on a translunar coast. If you want to try it, the Apollo 8 crew got Maneuver PADs for abort maneuvers at specific times after TLI cutoff: TLI+90 (mins), TLI+4 (hours), TLI+11, TLI+25, TLI+35, TLI+44. They all targeted the Mid-Pacific primary landing area (-165/165W). Only the TLI+90 burn targeted the Mid-Atlantic landing area (-30/30W). Because these are rather long burns, you will have to do additional Midcourse Corrections. Is this something P31 was supposed to do, to increase the accuracy?

Finding the best return Delta-V for an abort maneuver is kind of tricky, so please tell me, if it doesn't find a solution for you. Then I need to get a little more creative for that. Also, I had pretty good results in using the total Delta-V and TIG of a abort burn and let P37 find a solution with it. While my MFD already does that, too, we could use this to get the numbers for P37 Block Data, which is pretty nice I guess.


Title: Re: Apollo Rendezvous MFD
Post by: pattersoncr on April 23, 2015, 08:19:12 PM
Can the MFD calculate a Nominal REFSMMAT for a T-align in the past?


Title: Re: Apollo Rendezvous MFD
Post by: eddievhfan1984 on April 23, 2015, 10:35:43 PM
I imagine no, since that would mean entire storing a history of orbital elements, or reverse-propagating the osculating elements. Why would you need to, BTW?


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on April 24, 2015, 03:05:18 AM
It should be able to calculate a nominal REFSMMAT in the past. I don't think I have tried it, but at least the implementation of the coasting integration routine can find the state vector in the past. The AGC sometimes has to do that, too, every time you run P37.


Title: Re: Apollo Rendezvous MFD
Post by: pattersoncr on April 24, 2015, 06:50:13 AM
Having the MFD calculate a REFSMMAT based on a T-align in the past is extremely useful in order to have the MFD match your current REFSMMAT.
I think a very user friendly feature would be to have the MFD use the current REFSMMAT but in absence of that, it has the ability to generate all the normal REFSMMATs that were commonly used.  The only hole I see is if you are trying to match the MFD to your current REFSMMAT which happens to be a nominal with T-align in the past, hence my question.
I tried it the other day and when I entered the T-align it didn't accept it, I just got a beep when I hit ENTER.


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on April 24, 2015, 07:10:29 AM
Having the MFD calculate a REFSMMAT based on a T-align in the past is extremely useful in order to have the MFD match your current REFSMMAT.
I think a very user friendly feature would be to have the MFD use the current REFSMMAT but in absence of that, it has the ability to generate all the normal REFSMMATs that were commonly used.

Yeah, I tried that with the most recent version. It has the launch REFSMMAT as the default and from there, I think, basically all types of REFSMMAT can be either calculated with the MFD, or if a new REFSMMAT is calculated by P52, it can at least be replicated quite accurately so that it matches the one in the CMC.

The only hole I see is if you are trying to match the MFD to your current REFSMMAT which happens to be a nominal with T-align in the past, hence my question.
I tried it the other day and when I entered the T-align it didn't accept it, I just got a beep when I hit ENTER.

I haven't put anything in the MFD that would prevent a GET in the past from being entered, so I don't really know why it didn't accept it. The MFD used to only accept the format XXX:XX:XX, but now even that is a little bit more relaxed, so you don't have to type e.g. "004" for the hours, but only "4" also works.


Title: Re: Apollo Rendezvous MFD
Post by: pattersoncr on April 24, 2015, 07:27:52 AM
I'll try it again this evening.  Maybe I fat-fingered something.


Title: Re: Apollo Rendezvous MFD
Post by: jalexb88 on April 24, 2015, 01:43:55 PM
I've performed the TLI plus 11 very successfully. I'll try the PC plus 2 next. One suggestion for the lunar entry pad would be to add the sextant star check to it as its part of the entry pad on Apollo 8 and later.

Alex


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on April 24, 2015, 02:20:19 PM
I will add the sextant star check, but I'm not quite sure about something. Is it supposed to happen at the actual entry attitude or at RPY 0, 265, 0 as it says in the Apollo 15 Entry Checklist?

You will have trouble calculating the PC+2 maneuver with my MFD. The Entry Targeting does not work very well close to the Moon. The closest I came while testing was 4 hours after PC+2. An earlier burn will freeze Orbiter and even then it takes a long time to find the solution. Currently the earliest burn after leaving the Moon that can be calculated with good results is the MCC5 at 104:00 GET.


Title: Re: Apollo Rendezvous MFD
Post by: jalexb88 on April 24, 2015, 04:46:17 PM
I will add the sextant star check, but I'm not quite sure about something. Is it supposed to happen at the actual entry attitude or at RPY 0, 265, 0 as it says in the Apollo 15 Entry Checklist?

That's a good question. I checked the Apollo 8 flight journal and the re-entry pad read up by Ken Mattingly seems indicates 357, 152, 359, so I'd imagine the sxt, shft angles are for those gimbal angles.

As for the PC+2 I'm using LTMFD for the burn itself, then your MFD for the final course correction. That combination works very good, I can even manage both the high speed (with SPS) and low speed RCS version of that maneuver.


Title: Re: Apollo Rendezvous MFD
Post by: pattersoncr on April 24, 2015, 06:27:13 PM
I'll try it again this evening.  Maybe I fat-fingered something.
Never mind.  T-align in the past works fine.


Title: Re: Apollo Rendezvous MFD
Post by: pattersoncr on April 26, 2015, 07:43:25 AM
Is there a way to go back to the launch REFSMMAT in the MFD after you've changed to another REFSMMAT?


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on April 26, 2015, 07:52:04 AM
Not in the MFD itself, but I could easily add that. Right now, if you delete the three lines the MFD currently saves in the scenario file, it will revert back to the launch REFSMMAT.


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on April 27, 2015, 07:08:00 AM
The next update:

-I added the Terminal Phase Initiate (TPI) PAD for Apollo 7. I put it as a second option on the Maneuver PAD page, because essentially it's kind of a Maneuver PAD.
-Sextant star check on the Entry PAD
-An option to revert back to the launchpad REFSMMAT. Currently I have only saved the Apollo 7 and 8 launch REFSMMAT in the MFD.

To calculate the TPI maneuver you will have to find the right T1 (Maneuver Time) and T2 (Arrival time) on the Lambert page. Because there wasn't any space left for additional parameters on the Lambert page, I chose a different way. If you press T1 don't type in a GET, but instead "E=27.45". The MFD will now try to find the precise time, when the elevation angle of 27.45 relative to the target (S-IVB) is reached. Of course you first have to set the target, before it can calculate the T1 time. This way of calculating T1 might change in the future, because I'm not 100% happy with it.

I also added a convenient way to calculate T2. The arrival time is supposed to be 35 minutes after the TPI maneuver for Apollo 7. So press T2 and instead of a GET type "T1+35min" and it will set the correct time. The additional parameters for the Lambert targeted burn are N=0, Perturbed gravity and no offset. You can calculate the TPI at any time between the NSR and the TPI maneuver.

Next go back to the menu, then to the Maneuver PAD page and press "OPT" to switch to the TPI PAD page. Press "CLC" to calculate the missing parameters. The TPI PAD is pretty much complete, I think. The TPI PADs for the other missions look different, because they usually where done with the LEM. Also, please don't actually use the numbers from the TPI PAD, you will miss out on all the fun of doing the rendezvous with the AGC  :ROTFL3453:


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on April 29, 2015, 02:18:31 PM
What I currently try to implement are nonimpulsive burns. At the moment all maneuvers in the MFD are calculated impulsive, but of course quite a few burns are several minutes long. The only long, realistic burn that my MFD can really calculate is a trans-lunar coast abort. The Pre-Thrust Program being used with that is P30 and not P37, so the magical cross product steering constant c is 0, instead of 0.5 with P37. That's why any long maneuver solution in my MFD is not very precise. Maybe I can improve this, but it is rather challenging.

Mostly this new feature would be useful for the LOI-2 or Landing Site REFSMMAT of some missions. The coasting integration routine in my MFD combined with taking the nonimpuslvie LOI-1 into account can come up with the state vector at the time of LOI-2 and then calculate the LOI-2 REFSMMAT long before reaching the moon. I was even able to use the flight plan IMU angles for the PTC after MCC4 and it was exactly perpendicular to the sun  :shock:

Of course the last step to full historical accuracy would be calculating the REFSMMAT for LOI-2 BEFORE MCC4. This is not even much more difficult to calculate, but I have no idea what a user-friendly way of having 2 future maneuvers (MCC4 and LOI-1) would look like. And I don't think you can do this with IMFD!? So I guess the next update will be for the LOI-2 REFSMMAT, but you would have to calculate it after MCC4 and after you found the DV for LOI-1 with IMFD.


Title: Re: Apollo Rendezvous MFD
Post by: jalexb88 on April 29, 2015, 04:24:25 PM
What I have been doing for the LOI-2 REFSMMAT is using an LVLH time of 69:13:15.  That is with a lunar PET time of 69:10:38 and having the LVLH time a few minutes after PET simulates what the LOI-2 perilune position would be at ~73:30 GET. I can do all this before MCC 4 and my initial test gave me a near perfect LOI-2 Attitude (p: 180)


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on April 29, 2015, 04:42:48 PM
Yeah, I've been doing it in a similar way, although I can't say I got a result that was that close to the desired attitude. With the new system you would use the manual TIG and DV input for the LOI-1 maneuver and then set the actual time of LOI-2 on the REFSMMAT page and that's how you get a pretty good REFSMMAT. One reason for improving the calculation of the LOI-2 REFSMMAT is that LOI-1 is not necessarily in-plane, at least the historical number has a fairly large y component for that burn. But I guess I don't have to be too perfectionistic, if we can already calculate a good LOI-2 REFSMMAT with creative use of the tools existing in the MFD.


Title: Re: Apollo Rendezvous MFD
Post by: pattersoncr on April 30, 2015, 08:16:56 AM
It's been a while since I've gone through Apollo8 but what I remember doing in the past was maintaining the Launch REFSMMAT until after the last TLC MCC (MCC4) and then doing a Nominal P52 with T-align set to PC time.  If I recall both LOI1&2 buns ended up pretty close to actual attitude-wise.  This shifts the REFSMMAT change by several hours but can be done with existing tools.
Also, I dug through the flight plan and AFJ and most of the attitude references while in lunar orbit are LVLH/ORDEAL rather than inertial so even if the REFSMMAT is off a little, we can still accurately recreate the historical mission.
 


Title: Re: Apollo Rendezvous MFD
Post by: jalexb88 on April 30, 2015, 11:24:58 AM
Yeah, I've been doing it in a similar way, although I can't say I got a result that was that close to the desired attitude. With the new system you would use the manual TIG and DV input for the LOI-1 maneuver and then set the actual time of LOI-2 on the REFSMMAT page and that's how you get a pretty good REFSMMAT. One reason for improving the calculation of the LOI-2 REFSMMAT is that LOI-1 is not necessarily in-plane, at least the historical number has a fairly large y component for that burn. But I guess I don't have to be too perfectionistic, if we can already calculate a good LOI-2 REFSMMAT with creative use of the tools existing in the MFD.

I guess that would be a good way of doing it too. Mind you, according to the A8FJ the real attitude for LOI-2 was R: 0 P: 175 Y: 358. Here's an interesting fact: Frank Borman even questioned mission control if you look at the journal closely about the pitch being 5 degrees off as mission control had aimed for  0,180,0 for that maneuver. Mission control replied that inaccuracies in the trajectory from calculating the REFSMMAT way back before MCC-4 caused the final attitude to a bit off. What I am trying to say is they faced the same issue and a bit of inaccuracy there is actually more realistic than having a perfect 0,180,0 for the LOI-2.

Borman's query starts at 72:35 here: http://history.nasa.gov/ap08fj/13day4_orbits123.htm

Alex


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on April 30, 2015, 12:05:27 PM
Yeah, I read quite a bit about this topic before. See this thread: http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=2853.0 (http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=2853.0)

a bit of inaccuracy there is actually more realistic

That is never a reason for me to not calculate something as precise as possible.  :ROTFL3453:

But I guess it determines how much effort I should put into calculating these things. At least for the Landing Site REFSMMAT, which I have added for testing purposes, a prediction of what the orbit around the moon will look like is really necessary. They uplinked it on some missions, at the same time as the LOI-2 REFSMMAT on Apollo 8.


Title: Re: Apollo Rendezvous MFD
Post by: meik84 on April 30, 2015, 01:41:15 PM
Quote
Frank Borman even questioned mission control
Well, when you read the journal closely you'll end up quoting Jim Lovell: 'That's Frank!' :wink: One man has to be the commander (or nanny?) and keep tabs on a CMP that finally can play around with his CMC and a 'bored' LMP without an LM. He demonstrates this in on some occasions during the mission: he insists on a 'go' for every moon rev, sends the children (Jim & Bill) to bed before their big day... There had to be a reason they didn't made Jim (at that time the astronaut with the most hours in space in the corps) CDR, but Frank: there it is.


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on May 02, 2015, 06:29:17 AM
Another update:

-Added the option to calculate a REFSMMAT directly or with the parameters of an orbit after a maneuver.
-Landing Site REFSMMAT. Not really useful for Apollo 7 and 8, but I added it already for completion. Only the PTC REFSMMAT is left, I think.
-The Maneuver PAD page now displays Noun 44 instead of Noun 42. Noun 42 is the estimated apoapsis and periapsis after a burn calculated by P30 before the maneuver, Noun 44 is the actual apoapsis and periapsis calculated by Verb 82 after a maneuver. The Maneuver PADs for some mission seem to have N42 and others N44. N44 is more useful, I think, because it displays the actual orbit that will be reached. E.g., the Apollo 11 LOI-1 Maneuver PAD had Noun 44 (169.2 x 61.0 NM) but as an additional comment on the PAD the crew also got the numbers for N42 (431.3 x -128.2 NM).

a 'bored' LMP without an LM.

That LMP without his LM had time to take one of the most iconic photographs of all time, so, it kind of worked out in the end to have a third crewmember  :D


Title: Re: Apollo Rendezvous MFD
Post by: eddievhfan1984 on May 02, 2015, 05:51:36 PM
Plus the division of labor was usually that the CMP had propulsion and steering/computer, the CMP had computer/optics and the center panel environmental stuff, and the LMP had general systems including electrical/SPS/comms/etc. ;)


Title: Re: Apollo Rendezvous MFD
Post by: meik84 on May 03, 2015, 10:21:41 AM
That regimen was only valid during launch. On a normal mission, CDR and CMP would change positions some time before T&D, making the CMP a real CSM pilot. Apollo 8 was quite different, as Jim had to be busy with the CMC almost all the time. Normal missions would only do a handfull of P23s to get used to the different environment and P22s only for determining the actual position of the landed LM. Jim made numerous P23 under different light conditions and tracked almost a dozen control points/pseudo-landing sites -not much time left for other stuff.
However, this pushed Bill into his 'flight engineer' role (you'll see that he keeps track on all consumables -clearly not the responsibility of a normal LMP) and Frank into the pilot role.


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on May 03, 2015, 11:18:39 AM
Todays update of the MFD:

-PTC REFSMMAT. It is independent of the current state of the CSM, but one of the axis is defined by the Earth-Moon line at a specific time. Sometimes this time seems to have been at TLI and at other times at the planned time for TEI. Maybe for the TLC it was the TLI time and for TEC the TEI time? It doesn't make a huge difference though, if your pitch is 90 and the yaw 0 you will be in a good PTC attitude. Afaik all usually ground calculated REFSMMAT types can now be calculated with the MFD  :ThumbsUp432:


Title: Re: Apollo Rendezvous MFD
Post by: jalexb88 on May 04, 2015, 10:26:42 AM
Todays update of the MFD:

-PTC REFSMMAT. It is independent of the current state of the CSM, but one of the axis is defined by the Earth-Moon line at a specific time. Sometimes this time seems to have been at TLI and at other times at the planned time for TEI. Maybe for the TLC it was the TLI time and for TEC the TEI time? It doesn't make a huge difference though, if your pitch is 90 and the yaw 0 you will be in a good PTC attitude. Afaik all usually ground calculated REFSMMAT types can now be calculated with the MFD  :ThumbsUp432:

Awesome! Never thought we would have an easy solution for REFSMMATs and maneuver PADs but looks like you solved that. Now that I have a few days off I think Ill fly Apollo 8 form start to finish.


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on May 04, 2015, 11:54:02 AM
Now that I have a few days off I think Ill fly Apollo 8 form start to finish.

And while you are doing that, you could maybe make a few notes about how my MFD holds up when being used for a whole mission and what is still missing. That would be great!

The only thing that would be nice to have for Apollo 8 and is still missing are the acquisition times for the landmark tracking. I usually waited until the landmark came over the horizon, then I started the timer and at 5 minutes I initiated a 0.3/s pitchdown and started the marking process. The astronauts got the times for 0 elevation and 35 elevation (AOS), which is pretty useful I guess. This is one of the small things I could add to the MFD, but it's pretty fun to calculate. It would look like this (P22 Auto Optics), from the Apollo 11 flight plan: https://www.hq.nasa.gov/alsj/a11/a11fp65.gif (https://www.hq.nasa.gov/alsj/a11/a11fp65.gif) And then you could just follow the Apollo 8 flight plan or do the landmark tracking like the standardized profile of later missions: https://www.hq.nasa.gov/alsj/a11/a11fp70a.gif (https://www.hq.nasa.gov/alsj/a11/a11fp70a.gif) or https://www.hq.nasa.gov/alsj/a11/a11fp64a.gif (https://www.hq.nasa.gov/alsj/a11/a11fp64a.gif)


Title: Re: Apollo Rendezvous MFD
Post by: jalexb88 on May 04, 2015, 01:28:37 PM
Now that I have a few days off I think Ill fly Apollo 8 form start to finish.

And while you are doing that, you could maybe make a few notes about how my MFD holds up when being used for a whole mission and what is still missing. That would be great!

The only thing that would be nice to have for Apollo 8 and is still missing are the acquisition times for the landmark tracking. I usually waited until the landmark came over the horizon, then I started the timer and at 5 minutes I initiated a 0.3/s pitchdown and started the marking process. The astronauts got the times for 0 elevation and 35 elevation (AOS), which is pretty useful I guess. This is one of the small things I could add to the MFD, but it's pretty fun to calculate. It would look like this (P22 Auto Optics), from the Apollo 11 flight plan: https://www.hq.nasa.gov/alsj/a11/a11fp65.gif (https://www.hq.nasa.gov/alsj/a11/a11fp65.gif) And then you could just follow the Apollo 8 flight plan or do the landmark tracking like the standardized profile of later missions: https://www.hq.nasa.gov/alsj/a11/a11fp70a.gif (https://www.hq.nasa.gov/alsj/a11/a11fp70a.gif) or https://www.hq.nasa.gov/alsj/a11/a11fp64a.gif (https://www.hq.nasa.gov/alsj/a11/a11fp64a.gif)

Ok, Ill report back with my findings. One thing I was wondering is the orbit change program you had in a previous version, I found that really useful and I can see its place for the LOI-1 burn where we could have an accurate control of inclination as well, LTMFD unfortunately doesn't let one control inclination, only final PeA, ApA. The real mission aimed for 168.

As for the P22 navigation, last summer I had spent a fair bit of time practicing those with CP 1,2,3 and B-1. For the acquisition times I used the real Map updates from AP8FJ and filled out the MAP update forms, the real times actually work almost perfectly. I understand however that you like to calculate those in the MFD and that would also be pretty cool. Thanks for those gifs, I will use them on this next Apollo 8 attempt.


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on May 05, 2015, 03:30:55 PM
Hmm, even if I am able to fix the problems with the orbit change functionality, the LOI-1 burn would still be too long for my MFD to be accurate. All the longer burns (TLI, LOI, TEI) are better calculated with IMFD or LTMFD at the moment. Finding both the TIG and DV for nonimpulsive maneuvers is no easy task. I will look what I can do.

Instead I am adding a few missing items to the PADs, e.g. Entry Attitude Horizon Check for the Entry PAD and Backup GDC Alignment for the Maneuver PAD. Just in case you accidentally turn off your IMU shortly before a maneuver  :ROTFL3453:


Title: Re: Apollo Rendezvous MFD
Post by: jalexb88 on May 05, 2015, 04:42:56 PM
Hmm, even if I am able to fix the problems with the orbit change functionality, the LOI-1 burn would still be too long for my MFD to be accurate. All the longer burns (TLI, LOI, TEI) are better calculated with IMFD or LTMFD at the moment. Finding both the TIG and DV for nonimpulsive maneuvers is no easy task. I will look what I can do.

Instead I am adding a few missing items to the PADs, e.g. Entry Attitude Horizon Check for the Entry PAD and Backup GDC Alignment for the Maneuver PAD. Just in case you accidentally turn off your IMU shortly before a maneuver  :ROTFL3453:

Yeah its not any big deal with LTMFD either as I still get ~167.5 inc. which is close enough for now. I am looking forward to seeing the GDC Alignment / Entry check as I would love to try a GDC only maneuver, maybe even simulate a CMC failure and try to get home with the GDC / SCS and and the PAD gimbal angles.  :D that would be quite the challenge. I think we'll have a complete PAD now.  :ThumbsUp432:


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on May 06, 2015, 04:45:03 PM
I have a few questions about the Backup Alignment.

1. The AOH says the optics have to be set to 0 shaft and 352.5 trunnion for the alignment. But I don't think that's within the trunnion range?! Instead, and these numbers are mentioned in the Apollo 8 Flight Journal, too, it should be set to 180 shaft and 7.5 trunnion. Both set of angles align the optics with the z-axis of the spacecraft.

2. The alignment needs two stars. The primary star is positioned on the 0 mark and the secondary star on the "R line" (?), which I guess means below on the Scanning Telescope. The FOV of the SCT is 60, but the 2D panel obstructs the view, so you sometimes can't see both stars at the same time, when the primary star is centered. I had to increase the FOV to do the alignment in that case. A different technique seems to be used on Apollo 8 at 25:08 GET, as seen here: http://history.nasa.gov/ap08fj/06day2_green.htm (http://history.nasa.gov/ap08fj/06day2_green.htm) The secondary star is on the 50 line and the primary star close to 0. With that technique, the FOV wouldn't be a problem. The first technique seems to be the correct one though.

3. The alignment after a successful Backup GDC Alignment is supposed to be the same as before the IMU/CMC failed, right? If yes, then we could basically calculate the REFSMMAT in different mission phases from the GDC Align Angles, if we want to do that to compare the numbers with the REFSMMATs my MFD is calculating. Of course it would only be accurate to one degree.


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on May 11, 2015, 11:12:22 AM
To answer my own first question, I think the Scanning Telescope can be placed to the desired angles in Manual Optics Drive, where you completely manually turn the telescope to the desired angles and the G/N Optics Power switch is off. I don't think that works in NASSP though.

Anyway, while I'm still not quite sure about the best procedure for the Backup Alignment, I will release it anyway. Here the list of updates:

IMU/GDC Backup Alignment

This is part of the Maneuver PAD. If you loose the platform before a critical burn (yes, that is pretty unlikely in our simulation  :ROTFL3453:), you can use the following procedure:

1.Set the optics to +180.00 SA, +07.500 TA. You can do that manually while monitoring V16 N91 or automatically with V41 N91.

2. Set the ATT SET dials to the RPY angles from the PAD.

3. Maneuver to point the optics to the primary star, e.g. Vega. Then yaw until the secondary star, e.g. Deneb, is directly below Vega on the SCT. You might have to adjust the FOV to see the secondary star. If the primary star is on the 0 mark and the secondary star on the the line below (see http://history.nasa.gov/ap08fj/06day2_green.htm (http://history.nasa.gov/ap08fj/06day2_green.htm)) press GDC ALIGN. For reference look at the AOH procedure or the Apollo 15 G&C checklist.

I have added the three star sets from the Apollo 15 G&C checklist to the MFD, which are chosen so that you don't run into gimbal lock during the alignment. Especially for Apollo 7 it would probably be useful, that these stars are not behind the Earth during the alignment, but that will be another update.


A few updates to the Entry PAD:

Entry Attitude Horizon Check

In this (http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19700024999.pdf) document I found the (probably) correct attitude timeline for the entry. About an hour before reentry the CSM is maneuvered to the entry attitude from the Entry PAD, where you will do an sextant star check. At about EI-20 minutes you pitch up to the pitch attitude for the horizon check, which is usally done at EI-17 minutes. If the horizon is within 5 of the 31.7 window line then the IMU is GO for reentry. Then you yaw right 45 for the separation. After that you yaw back to 0 and manually track the horizon until you are happy with the numbers you see on the DSKY and give the control to the CMC. That's at least how I interpret the document.

MAX G

The predicted maximum reentry acceleration, based on the calculations the AGC does for the P61 displays. Might even be more accurate than the AGC, because of our good old spherical Orbiter Earth.

DO

Planned drag level during Constant G. I'm not even sure what exactly this is, but I think it is useful for a backup procedure. I found this in the Apollo 10 Crew Charts (http://history.nasa.gov/ap10fj/pdf/a10-crew-charts.pdf) document and it is just a simple approximation of that chart.

Lift Vector

Also in the A10 Crew Charts document was a chart with the lift vector orientation line. So in the rare case your reentry angle is too shallow, this will tell you to fly the first part of the reentry lift vector down, instead of the usual lift vector up.


State Vector Update

I expanded the state vector update to include the target slot. I don't let the user choose the vessel for the "this" slot though, I don't think it is a good idea to put the state vector of another spacecraft in that slot. You can also choose a GET for the state vector update. This was sometimes used to uplink a future state vector, for reasons I am not completely sure about. Maybe slightly better accuracy than the CMC? It will also prevent the usual state vector propagation in P00 at least until the time of the time tag. So if you want a realistic use for this, the very last state vector update before a lunar reentry was done with the time tag set to the time of Entry Interface, which you can get from the Entry PAD. If you set the time to 000:00:00 GET again, it will just use the time when CLC was pressed. Usually it should probably set to zero.


Title: Re: Apollo Rendezvous MFD
Post by: jalexb88 on May 11, 2015, 12:26:23 PM
Your GDC alignment procedure seems pretty accurate and works well on mys side  :ThumbsUp432: I cant confirm if that's the actual way of doing it but from what I understand the sequence you describe seems pretty logical. I have just finished my latest Apollo 8 attempt and all seems working perfectly the your MFD, my LOI-2 attitude was R: 000 P: 179 Y: 359  :ThumbsUp432:

One note I had about the shaft angle being displayed with a "-" on some occasions whereas the actual PAD form only accepts a "+", no big deal but I was curious on that. I have included a set of scenarios from my whole mission for you guys if you want to try various maneuvers at different times during the mission for testing I think this might help a lot.

EDIT: I also hit an unrelated snag having to do with state vector updating using cislunar navigation (P23). See this post: http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=2725.msg22655#msg22655


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on May 11, 2015, 03:11:54 PM
The newest update breaks the Entry PAD calculated with the "Direct" option, will fix asap.

EDIT: I fixed it, I think. I also changed literally a single character and now the shaft angle is always a positive number.

The set of scenarios is great, I also have a huge number of quicksaves, but never properly sorted them for easy use for testing. I did that for Apollo 7 though and now I have all the scenarios I'll ever need to test stuff for those two missions.

While trying a few things with the scenarios, I noticed why I am not a good software developer. Not only did I upload a broken version of the MFD, but I also noticed why I should test new features before releasing them. The horizon check doesn't make any sense, although I checked the numbers and they are similar or equal to historical figures from Entry PADs. But while the window with the COAS has the markings just like the real CSM, the 31.7 line is not actually angled 31.7 to the centerline. Instead it depends on the FOV and it is much less than the 31.7 in any case. So it sadly is a rather pointless feature on the Entry PAD. :sorry345: All I could do is deviate from the historical procedure and calculate the pitch angle, so that the center of the COAS is directly pointing to the horizon. This works perfectly fine, although the horizon isn't easy to see, when the sun has already set.


Title: Re: Apollo Rendezvous MFD
Post by: jalexb88 on May 11, 2015, 04:34:35 PM
The set of scenarios is great, I also have a huge number of quicksaves, but never properly sorted them for easy use for testing. I did that for Apollo 7 though and now I have all the scenarios I'll ever need to test stuff for those two missions.

I know what you mean lol those quicksave file names get incredibly long sometimes. BTW just for your info, the scenarios that start in PTC have all the AUTO RCS SELECT switches and ROT NORMAL AC/DC switches to OFF, I use 50x time accel so I did this in case I moved the joystick accidentally. Also, the correct Apollo Rendezvous MFD REFSMMAT is saved in each scenario according to the mission stage.


Title: Re: Apollo Rendezvous MFD
Post by: pattersoncr on May 12, 2015, 02:19:09 PM
The Apollo 10 crew charts you posted reminded me of something.  Included in them is a chart of SPS Tailoff thrust vs CSM weight.  Tailoff thrust is caused by the amount of thrust that happens after the signal has been given to shut down the engine.  I would assume this is caused by the finite amount of time it takes the SPS ball valves to roll shut plus the fuel and oxidizer that are already downstream of the ball valves when they go shut.  The CMC accounts for tailoff thrust but the EMS dV counter does not. This is responsible for the difference between Vt (total dV to be gained) and Vc (dV setting on the EMS).  I notice that the Maneuver PAD on your MFD shows Vt but it is labeled as Vc.
I suspect that tailloff thrust is a constant (force) value and that Vt - Vc = F/M  where "M" is CSM weight.

Does anyone know if NASSP accurately models tailoff thrust?

By the way, the A10 charts also include a handy chart showing whether or not an RCS ullage burn is required for SPS burns.  I've included it in the multitude of updates I want to make to the G&C Checklist.


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on May 12, 2015, 03:27:17 PM
It probably wouldn't be a constant force, but rather a constant impulse (force x time) from shutdown signal to zero thrust. I assumed that it is not simulated, so I simply put the total DV on the PAD. If it is simulated, then it wouldn't be difficult to implement for the Maneuver PAD.


Title: Re: Apollo Rendezvous MFD
Post by: pattersoncr on May 12, 2015, 04:28:13 PM
Impulse, that's what I meant.  But regardless, proportional to CSM "weight" (mass actually).

The only other factor I can think of that might affect it if it is a one vs two bank burn (whether or not both dv Thrust switches are used) with both, you'd have more propellants downstream of the ball valves.


Title: Re: Apollo Rendezvous MFD
Post by: eddievhfan1984 on May 13, 2015, 01:44:58 AM
Tail-off thrust is actually simulated: since the AGC accounts for it during burn operations, it would need to be modeled at least to a minimal extent. I've actually been wondering about the VC setting table myself, since I assumed it's not a constant 20.8 fps as the EMS dV TEST would have me believe (especially regarding minimum impulse burns)...


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on May 13, 2015, 05:00:48 AM
Tail-off thrust is actually simulated: since the AGC accounts for it during burn operations, it would need to be modeled at least to a minimal extent. I've actually been wondering about the VC setting table myself, since I assumed it's not a constant 20.8 fps as the EMS dV TEST would have me believe (especially regarding minimum impulse burns)...

20.8 ft/s seems about the maximum tailoff DV with an almost empty CSM.

I've been calculating a little bit and I can report, that I am able to replicate the EMS DV numbers quite accurately. So it will be part of the next update for the Maneuver PAD.


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on May 14, 2015, 06:54:16 AM
Update:

-Added the EMS DV setting and switched a few numbers around on the Maneuver PAD, so it is now more like the one used for Apollo 8 and later and not Apollo 7.

A few more comments about it. The EMS gets the numbers from an accelerometer, so, of course it will run into negative numbers during a SPS burn. When it reaches zero it sends a cutoff signal to the SCS, so everything that happens after that, should only come from the tailoff thrust, regardless which system controls the SPS. The DV value on the PAD is also compensated for the small offset of the SPS from the longitudinal axis of the CSM, which really is only significant during a very long burn. I am not 100% sure this difference is simulated, too, but I think it is. The best way to test it is probably a SCS controlled LOI maneuver and then we will see if the SPS shuts down too early.


Title: Re: Apollo Rendezvous MFD
Post by: eddievhfan1984 on May 19, 2015, 09:53:26 PM
Well, as I recall, the SPS is modeled as being on-axis, and CG shifts due to propellant expenditure aren't modeled either.


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on May 20, 2015, 09:13:48 AM
Our SPS is slightly offset, so that it matches the real one. Check this post for reference: http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=178.msg19193#msg19193 (http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=178.msg19193#msg19193)

The AGC assumes mechanical pitch and yaw trim angles, so the way it is done in NASSP is using these angles together with an off-center position of the SPS, so that it still points through the center of mass. That's why we don't need additional electrical trim pitch and yaw angles (these terms are from the GSOP), which you would set with V48. And you are right about CG shifts, I don't think CG shifts are even possible in Orbiter.

The EMS measures an acceleration through the longitudinal axis of the CSM, so it won't get exactly the correct DV, that the CSM actually experiences. E.g., for a LOI burn of 2974.8 fps the EMS would measure a DV 2.5 fps lower than the actual number. And my testing confirms, that our EMS does this, too. And while the tailoff DV doesn't exactly match the value taken from the chart, the displayed DVC on the Maneuver PAD is pretty close to what it should be.


Title: Re: Apollo Rendezvous MFD
Post by: eddievhfan1984 on May 20, 2015, 04:55:42 PM
You can model CG shifts, but you have to hard-code it in, rather than use the Orbiter API calls to do it for you, as I recall.


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on May 24, 2015, 07:27:36 AM
I found a nice document called "Apollo CSM and LM onboard navigation system constraints", which you can find here: http://ntrs.nasa.gov/search.jsp?R=19700026457 (http://ntrs.nasa.gov/search.jsp?R=19700026457)

It has a few information about the size of the occultation cones of the Earth and Moon and also the geometry of the COAS. I updated the MFD, so that it doesn't use stars that are behind the Earth/Moon or outisde of range (50 trunnion or more) for a sextant star check and the backup alignment. If there are no stars available, it will say N/A. There is one maneuver I know of that didn't have an available sextant star, which is the Apollo 7 NSR maneuver. The MFD finds an available star anyway, I guess that is caused by the trajectory which isn't 100% historically correct.

The information about the COAS would enable me to calculate the boresight star check for the Maneuver PAD, but we don't have an adjustable COAS, so I don't really see the point in adding it.


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on June 02, 2015, 01:50:11 PM
I didn't do much work on the MFD in the last time, it has pretty much all the features now that I wanted to implement. There are a few minor things that will be in the next update: better offset target with curvilinear coordinates, adjustable time for the sextant star check (it says N/A too often, more than would be realistic), improved implementation of the coasting integration routine, updated manual etc.

A few of the features, a complete RTCC MFD would have, require a major rework of the MFD, which I might do in the future. But for now, are there any things that really should be in the MFD? Any requests for new features? Or are there any other GNC problems that I can help with? I really would like to see the AGC working in the LM, but I am not a very good programmer, so I can only really help with stuff like padloads etc.


Title: Re: Apollo Rendezvous MFD
Post by: pattersoncr on June 02, 2015, 04:44:33 PM
Did it ever get implemented to have the MFD pull the current REFSMMAT from the AGC?


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on June 03, 2015, 05:11:11 AM
Sadly not. I never managed to fully understand how the GroudStation.exe does it, but it seems very complicated. Basically, if I can go through all the effort to implement a downlink functionality, then it's already halfway to a full blown MCC Simulator. Uplinking data is much easier.

But I did everything I could to make pulling the REFSMMAT directly from the AGC not necessary. If you are flyng a whole mission then it really shouldn't be an issue. The MFD saves the current REFSMMAT to the scenario file, you can replicate the REFSMMATs calculated by the AGC with the MFD and in all other cases you can uplink the REFSMMAT from the MFD. As long as you have some knowledge about the current REFSMMAT, you should be good. But of course, syncing the AGC and MFD REFSMMAT would be nicer...


Title: Re: Apollo Rendezvous MFD
Post by: pattersoncr on June 03, 2015, 06:16:29 AM
Does the MFD save the REFSMMAT?  When I reload a saved scenario, and look under REFSMMAT it always says "Launch"


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on June 03, 2015, 06:43:36 AM
Ah, in an earlier version the REFSMMAT page and the displayed REFSMMAT on the Manever PAD page were the same (because I was too lazy to introduce another variable) but now the displayed option on the REFSMMAT page and the actually saved REFSMMAT are different from each other. If you look at the Maneuver PAD page you will see the REFSMMAT type that is actually currently used. I guess it is a little bit confusing, because the REFSMMAT and the type of REFSMMAT are both saved in the scenario file, but not the page you last used on the MFD. Should I work on saving the complete state of the MFD to the scenario? That wouldn't be too difficult I think.


Title: Re: Apollo Rendezvous MFD
Post by: pattersoncr on June 03, 2015, 07:37:37 AM
That might eliminate confusion.


Title: Re: Apollo Rendezvous MFD
Post by: pattersoncr on June 03, 2015, 07:44:06 AM
One other type of info that was routinely read up to the astros was loss and acquisition of signal times. It would be nice to have that on an MFD. I suspect that this is completely unrelated to anything else in your MFD and if so, please feel free to ignore the request.


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on June 03, 2015, 08:19:13 AM
Most of the stuff in the MFD doesn't have much to do with "Apollo Rendezvous" anymore.  :ROTFL3453:

But you are right, that would be nice to have. I imagine something like the format of the Map Update from the Apollo 8 Flight Plan (http://www.ibiblio.org/apollo/Documents/FlightPlanApollo8-Martin-sects1-2.pdf) would be a good solution. Seems like a nice challenge to implement in the MFD.


Title: Re: Apollo Rendezvous MFD
Post by: pattersoncr on June 03, 2015, 10:29:55 AM
I put together a list of ground stations and lat/long for Apollo 7. I could put together a similar list for other missions (including whether or not they had large dishes). Let me know if you want to implement this and I'll post something.


Title: Re: Apollo Rendezvous MFD
Post by: eddievhfan1984 on June 03, 2015, 04:17:41 PM
Well, the LOS/AOS thing would require noting not only the ground coordinates/relative horizon angle of the spacecraft, but also the notching that occurs in some of the broadcast patterns, as you can see on the tracking network maps. That said, it's relatively straightforward. Though unless you want to put in code inhibiting data uplink when in LOS...


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on June 04, 2015, 09:31:45 AM
Actually I was more thinking about the sunrise/sunset and AOS/LOS for lunar missions and maybe the P22 update for the landmark tracking. I mean, calculating the AOS/LOS for tracking stations during Earth orbit missions is pretty similar, but I am not exactly sure what the purpose for that would be. Except, as Eddie mentions, inhibiting data uplinks during times without contact to the ground. That would be a great feature for some kind of MCC simulator, but my MFD currently isn't quite there yet. It certainly is worth thinking about...  :yes77:


Title: Re: Apollo Rendezvous MFD
Post by: pattersoncr on June 04, 2015, 10:34:55 AM
Last time I messed around with Apollo 7, I added the ground stations as VOR transmitters and used the default Orbiter COM MFD to see when they were in range. I was really struck by how much time the spacecraft spent without the ability to communicate with Mission Control. It gave the mission a whole different (and much more... Pioneering) feel.


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on June 04, 2015, 11:00:21 AM
Well, then help me out with the ground stations and coordinates. And where can I find the tracking network map that Eddie mentioned? Maybe I can even add some of the additional constraint he mentioned. As a first step I could inhibit uplinks during times of no coverage, or blank the MFD or so  :ROTFL3453:


Title: Re: Apollo Rendezvous MFD
Post by: eddievhfan1984 on June 06, 2015, 12:44:46 PM
Check out this sitehttp://www.honeysucklecreek.net/msfn_missions/MSFN/msfn.html

I can't link the picture directly, as the site server won't allow requests external to the webpage to complete.


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on June 08, 2015, 08:23:59 AM
Good news, the MFD can now predict the AOS and LOS with tracking stations. Currently this is only based on the line-of-sight and no additional constraints. I am using the first 10 stations that tracked Apollo 7 (from the flight plan), but it should be pretty easy to compile complete lists for all missions. All I need is the latitude and longitude of those stations. Somewhere deep hidden in the source code of NASSP I found a mcc.cpp file, which actually has a lot of those coordinates.

I will do some more testing and then the next update for the MFD should be ready. At the moment it will show you the tracking station with the closest AOS. I don't really know what the best way of displaying this would be, maybe showing the next three AOS/LOS times? Also, I will add an option that inhibits uplinks during LOS times, but I guess I will leave this option off by default.


Title: Re: Apollo Rendezvous MFD
Post by: pattersoncr on June 08, 2015, 07:16:45 PM
See attached for ground station locations.  Some explanation:
"USB" refers to Universal S-Band.  The number next to USB refers to the dish size (30 or 85 ft).
I pulled the equipment info from the communication plan section of the Apollo 9 flight plan.  The columns on the right refer to which stations were used on which missions.
The locations of the tracking ships (USNS) are the approximate positions listed in the Apollo 7 press kit.  I have not looked closely at other missions to see if they were in the same places.


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on June 09, 2015, 10:58:13 AM
Thank you for the list, I have implemented all tracking stations for Apollo 7 now.

I have now uploaded the update. Here my notes about it:

  • Improved orbit integration method. It can now switch between Earth and Moon as the main source of gravity during a calculation. This leads to a lot more potential Orbiter crashes caused by the MFD, if it outputs the wrong state vector, but I think it should work correctly in all cases.
  • Saving the state of the MFD to the scenario. Now all settings and numbers are saved, except those on PADs etc. Here you would just press CLC again to get the missing numbers. Everything else is saved, so I didn't feel it was worth it to save stuff, which is only a mouse click away.
  • P37 Block Data. Essentially this is an abort reentry maneuver calculated with the MFD so that the AGC can calculate it again... but P37 sets the steering variable to 0.5, which should make this maneuver a little bit more accurate.
  • Map Update and AOS/LOS prediction. I've included the map update for Apollo 8 with the numbers for sunset, sunrise, AOS and LOS with Earth and crossing of the 150W Prime Meridian.
    For Earth orbit more relevant are the "local" acquisition times, of course. At the moment it will display the next AOS/LOS time with a tracking station or ship, just as a demonstration. It would probably be useful, if more than one tracking station is displayed.
  • Configuration page. Here you now have the option to choose the time of the sextant star check before a maneuver. If it annoys you, tha you often get N/A for the sextant star check, then you can adjust this number to something else, e.g. from the flight plan. These times could vary a lot, because of the attitude of the spacecraft. E.g. for the Apollo 7 NCC1 maneuver the sextant star check was 30 minutes before the maneuver and for the NSR burn it was only 10 minutes.
  • Also in the settings now is inhibiting uplinks, while you are not in contact with any tracking station.


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on June 12, 2015, 12:14:51 PM
Small bugfix, Orbiter probably crashed every time it tried to load a scenario that had the saved state of the MFD. Note: pointers to variables that get destroyed are not very useful.


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on June 18, 2015, 10:23:44 AM
I was thinking about updating the manual for the Apollo Rendezvous MFD. Should I maybe instead write step by step instructions and update the Apollo 7 and 8 Excel Flightplan for the use with the MFD? Does that make sense to do at this point?


Title: Re: Apollo Rendezvous MFD
Post by: pattersoncr on June 18, 2015, 06:51:40 PM
I'm actually working on a flight plan update.
If you update the manual, I'll take care of the flight plan.


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on June 19, 2015, 03:54:02 AM
Then I'll update the manual. There won't be anything in it though, that I haven't described in this thread already.


Title: Re: Apollo Rendezvous MFD
Post by: Bunyap on June 19, 2015, 08:15:25 AM
pattersoncr, just so we are coordinated, I did a little work this week on a rendezvous checklist for Apollo 7 using your word doc format.  I was eventually going to transcribe it to the excel spreadsheet as well.  Does that overlap anything you are working on?

indy91, having all the info in one document would be awesome.  Thanks a lot! :)


Title: Re: Apollo Rendezvous MFD
Post by: pattersoncr on June 19, 2015, 01:26:20 PM
  ...Does that overlap anything you are working on?
It might.
This weekend, I'll post what I have both for the A7 Rvdz procedure and Flight Plan.
I'd love to get some feedback.


Title: Re: Apollo Rendezvous MFD
Post by: pattersoncr on June 19, 2015, 07:50:53 PM
Attached is what I'm working on for the Apollo 7 flight plan.  This was created using the preliminary flight plan (available from AFJ), the mission report, and the air-to-ground transcripts.  Wherever NASSP supports it, I've tried to include a way for the user to perform the DTO (Detailed Test Objectives) included in the real mission.
Included are places for the user to record data and PAD data, DTO results, etc.  I find that it really adds to the immersion to be writing stuff down, scribbling notes in the margin and what not.  My vision is for the user to print out a fresh copy each time they play the mission but as I went through and fleshed things out, section 1 (the mission timeline) grew and grew.  It's now at the point where I'm considering separating out the data tables from the non changing timeline portion.  Anyone have thoughts on it?

I'm not sure of the best way of conveying instructions for SPS burns.  There are actually a couple different approaches included if you scroll all the way to the end.

This is still a work in progress, especially after the start of day 8 or so.
Please take a look and tell me what you think.


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on June 20, 2015, 10:12:26 AM
Pretty awesome Flight Plan. A few comments on the use of my MFD:

Phasing Maneuver:

-I changed how the offset coordinates work to a curvilinear coordinate system, so the initial value for the z axis to find a completely retrograde maneuver is different now. For me it is 1.05 NM or 1944.6 m.
-The IMU angles are the nominal ones from the transcript, but are not necessarily exactly correct in the Orbiter scenario. You could calculate the actual attitude with the Maneuver PAD page or you have to use the thrusters a little bit more in P47 to get the maneuver right.
-In one of the more recent updates I added the option to calculate a Lambert targeted maneuver with spherical or non-spherical gravity. 15 orbits is too much to correct for the deviation created by the perturbed gravity, so it should be set to Spherical for the phasing maneuver(s) and to Perturbed for all other maneuvers.

Retro test:

I think a more realistic way for doing this is described in the first post of this thread. Calculate a deorbit burn for the orbit 6, landing target no. 4 (6-4) reentry opportunity, calculate a "P30 retrofire" REFSMMAT and uplink the numbers to the AGC. Then at 5:10 GET do a P52 option 1 with the new REFSMMAT and not an option 2.

NCC1 Maneuver:       

-I usually use the phase angle functionality with -1.32 to set the X offset, but it doesn't really make a difference.   
         
NSR Maneuver:      

-You should set an initial guess for the TIG at 28:00:00, or the MFD might not find a solution.

Separation Maneuver:

-Was there any target for doing this maneuver, or is it just getting away from the S-IVB? I never calculated this maneuver with the MFD, I always just did a 2.0 ft/s prograde burn.

Deorbit:

-This maneuver can be calculated with the MFD, too, but P37 works just as good. Just a little bit more work to do.


Title: Re: Apollo Rendezvous MFD
Post by: pattersoncr on June 20, 2015, 06:59:21 PM
Thanks for taking a look Indy!
For the Retro test, the goal was to orient the CSM for reentry manually using window marks & the horizon. Houston then read up the "correct" attitude. What I did in the flight plan was give the historical attitude in the data tables. (I figured that soon after insertion, the orbit would be similar enough to historical.)
I guess we could use the MFD to calculate the retro attitude instead of relying on historical. Can the MFD calculate a retro maneuver in the past? (I'd rather the user maneuver then calculate the correct attitude instead of giving them the "answer" beforehand.

I'll have some other responses later.


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on June 21, 2015, 05:13:05 AM
Oh, I think I didn't explain this right. I'm not talking about calculating the attitude for any of the retro tests. What they did at 4:45 GET is uplinking an actual deorbit burn for 8:59 GET and also uplinking a corresponding REFSMMAT that would lead to having 180, 180, 0 R,P,Y for the maneuver. This doesn't have too much to do with the retro tests directly, but it's still the REFSMMAT they used during that period. That was actually the reason why I started trying to implement REFSMMAT calculations in my MFD: http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=834.msg22472#msg22472 (http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=834.msg22472#msg22472)


Title: Re: Apollo Rendezvous MFD
Post by: pattersoncr on June 21, 2015, 08:06:40 AM
Ahh! I thought you were referring to the other retro test. I understand now and agree completely. I listed the actual PAD data read up at 4:45 but the MFD could be used to calculate both dv and REFSMMAT.


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on June 22, 2015, 08:53:24 AM
Update to the MFD:

  • Added the option to calculate a CDH maneuver with a fixed time. This should make this mode much more flexible, because so far it only really could calculate a Apollo 7 style CDH maneuver.
  • Updated manual. It's not very pretty, but at least it is now up to date with all features implemented so far.

EDIT: Oh, and I will add a few more examples for more complicated operations with the MFD, like LOI-2 REFSMMAT and direct-return aborts.


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on June 27, 2015, 05:54:43 AM
Yesterday I tried flying the Apollo 9 rendezvous with the CSM and an Apollo 15 launch scenario, because 1.) I wanted to figure out the numbers for the Apollo 9 phasing and insertion maneuver calculated with the Apollo Rendezvous MFD and 2.) I finally wanted to give P32 and P33 a try. And it went pretty well!

After insertion I performed two maneuvers to get into the 133x133NM orbit, that the CSM had during the procedure. It was quite tricky, because the CSM/LM stack didn't behave as I wanted it to. I guess the DAP is still not configured for this? At least not in the outdated scenario I used. I took over control with MTVC and it kind of work out. Next I adjusted my timeline with the Apollo 9 rendezvous, so that I could do all the maneuvers exactly 87 hours earlier than Apollo 9. Then I undocked and performed a 5 ft/s radially upwards separation burn. The manual TIG and DV input on the Maneuver PAD page of the MFD come in pretty handy for stuff like this.

Then the phasing maneuver. I had a look at the Apollo 9 flight plan and the relative motion plot. At 94:35:20 GET the LM is supposed to be about 47.5NM behind the CSM. So I used this offset with the Lambert targeting:

T1: 6:50:04 GET (93:50:04 GET for the actual Apollo 9 mission)
T2: 7:35:20 GET
N: 0
Precision: Perturbed
Target: Falcon
Offset: -47.5NM, 0NM, 0NM

I got a DV very close to the planned number from the A9 flight plan, so I was quite confident to do the maneuver with the calculated numbers. After the maneuver I targeted the relative position of the insertion maneuver (about 11NM above and 25NM behind the target) for a maneuver at 7:35:20 GET. This would have been a 2 ft/s maneuver, so I skipped it. For the insertion maneuver I used the CDH page and a fixed GET of 8:41:46 and got reasonable numbers again.

Now the fun part: P32 and P33 worked perfectly! I used the planned GET for the CSI and TPI maneuvers (9:22:00 and 11:00:15) and got a DH of 9.5NM instead of the 10NM of the planned profile. I didn't quite figure out how to properly use the P20 Universal Tracking of Artemis until after the CSI maneuver, but the deviations at that point were small and after the CDH maneuver the W-Matrix quickly converged while doing marks with the sextant. During the last pass through P34 I got a TIG about 2 minutes later than planned. The first real trouble I had was with the TPI maneuver. When I started P40 out of P34 it for some reasons had the wrong numbers for the maneuver, so I burned the numbers I wrote down in a last minute maneuver to the correct attitude. Also the ATIGINC wasn't padloaded so I messed up MCC1, too, and stopped the scenario. I'm sure it mostly comes down to user error, that the latter part of the rendezvous didn't work out.

All in all I call this a successful first attempt at the Apollo 9 rendezvous procedure and also using Artemis for the first time! I'm surprised I got so far despite the incomplete padload. I can post a few of my quicksaved scenarios, if anybody wants them. There is also an accompanying update to the MFD, so that it works with any mission and not only Apollo 7 and 8.


Title: Re: Apollo Rendezvous MFD
Post by: eddievhfan1984 on June 27, 2015, 08:17:21 AM
How did you manage to switch AGC versions? Was it part of the scenario configuration?


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on June 27, 2015, 08:21:34 AM
I launched with Apollo 15, I think it automatically uses Artemis for A15-17!?


Title: Re: Apollo Rendezvous MFD
Post by: eddievhfan1984 on June 27, 2015, 12:53:44 PM
Could you use the P32 and P33 CSI/CDH targeting routines, or the P70 series LM targeting programs?


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on June 27, 2015, 02:14:57 PM
I did a CSM active rendezvous, so I used programs P32-35. Aren't the P70 series programs used to calculate a maneuver for the LM with the CMC?

EDIT: I found something in this document: http://www.ibiblio.org/apollo/Documents/msc05225.pdf

"1.5.6(BC) P31 is the only rendezvous targeting program known to be inoperable in earth sphere, however, due to a lack of verification testing no rendezvous targeting program should be attempted in the earth sphere of influence. There is also a known problem with the aim-point transfer between P34/P35 and P40/P41 when in earth sphere."

So, if I interpret this correctly, neither Artemis nor Luminary 1E rendezvous programs work reliably in Earth orbit? This would explain the problem I described above. I guess I should fly to the moon and try this rendezvous thing again there :D


Title: Re: Apollo Rendezvous MFD
Post by: eddievhfan1984 on June 27, 2015, 10:37:30 PM
Possibly. P31, IIRC, is the Lambert targeting routine which you've implemented in RendezvousMFD, right? And that can only be used with uplinked target data, not through user input. As for the P34 stuff, that may make sense.


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on June 28, 2015, 06:14:16 AM
P31 in Artemis is actually a different program, Height Adjustment Maneuver (HAM) for the re-rendezvous after a late PDI abort or something like that. P31 in Colossus 249 is called Lambert Aimpoint Maneuver Guidance which was supposed to be used for maneuvers like LOI and TEI, but was never used during a mission iirc. It continuously calculates a Lambert solution during a maneuver. I guess this would lead to a more precise resulting orbit and consumes less propellant, but I guess it wasn't important enough to have that precision, I don't know. The Initial Velocity subroutine and the Lambert subroutine, which is an integral part of it, are used by the programs 31, 34 and 35 in Colossus. And that is basically what I implemented in my MFD.


Title: Re: Apollo Rendezvous MFD
Post by: eddievhfan1984 on June 28, 2015, 10:17:31 AM
Well, in retrospect, how would you manually input a target SV, time, and ECSTEER into an old-style P31 from the cockpit, anyways? LOL

I think the Earth-sphere issue may be due to the fact that the code was optimized for use in the Moon SOI, since after AP9, there would be no need for CSM/LM rendezvous in Earth orbit. So, for example, there might be an outer limit for apoapsis in the calculations that can easily be exceeded in LEO, or certain transit times between maneuvers may spit back garbage, or the Fischer ellipsoid for Earth vs. perfect sphere for Moon. At least IMO.


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on June 28, 2015, 02:27:42 PM
I mean, I know how to calculate and uplink the numbers for a CMC Lambert Target Update, with the exception of ECSTEER. Would be interesting to try that some time...  :wink:

And I agree about the second part, there wasn't really a need to make the rendezvous programs work in Earth orbit. P34 did calculate good numbets, but it just failed giving these numbers correctly to P40. Instead I got a wrong burn attitude and velocity. A workaround might be writing the TIG and DV down and squeezing a P30 between P34 and P40. Instead I put the CSM and LM in a lunar orbit and will try the Apollo 10 rendezvous profile. One result of this exercise is, that my MFD works just as good with Artemis as it does with Colossus 249. The Basic Reference Coordinate System for Artemis is slightly different from the BRCS used in Colossus, but this is only really a problem, if I try to use programs like P21, 22 and 23. Other than that, Desired REFSMMAT, External DV Update and stuff like have the same memory addresses as in Colossus. Only the directly uplinked REFSMMAT has a different address, but that update isn't currently used by my MFD.


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on June 30, 2015, 12:30:22 PM
The next update:

-Added the launch MJDs for all manned Apollo missions and also a manual input method for the launch MJD. Because most calculations in the MFD require the correct launch MJD as the basis for the ground elapsed time, the MFD can now be used with more missions than only Apollo 7 and 8. Mostly tested with the AGC version Colossus 249.
-Uplinks now also work in the LM. I stole most of the uplink code from the Project Apollo MFD, so it was very simple to implement this. I have tested state vector and REFSMMAT uplinks so far.
-Changed the font of the displays. I think it looks much nicer now, I will be playing around with this more often in the future.

EDIT: I don't think I have done this quite right. Can someone confirm these memory addresses for me?

XSMD (Desired REFSMMAT):
Colossus 249: 0306
Luminary 099: 3606

REFSMMAT:
Colossus 249: 1735
Luminary 099: 1733


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: indy91 on July 07, 2015, 05:33:10 AM
I guess I should have posted the question above in an extra post. :D

Anyway, here the newest update for the MFD:

-Changed the name to Apollo RTCC MFD. At this point it is the much more accurate name, but I was always hesitant to rename it. Make sure you choose the correct MFD on the Orbiter Launchpad. It's the last time I rename the MFD (Lambert -> Apollo Rendezvous -> Apollo RTCC), I promise! Except if I merge it with the Project Apollo MFD or make it an external application at some distant point in the future.
-Fixed the REFSMMAT memory addresses so that it works with Luminary (I think). I also added the option to either uplink the REFSMMAT or the desired REFSMMAT.
-Deleted the Offset page for the Lambert targeting. I always found it annoying that I have to change the page to set the offset values. Instead you can set it on the Lambert page now, although this is limiting the options you have. Let me know if you think this is a good change.

The features the MFD will have in the future are mostly additions for the LM. Although it probably isn't quite needed at this point of development, I will add DOI and PDI PADs and also calculations for the Abort PADs and the abort constant etc. Additionally, I think I finally found a way to access the erasable memory of the AGC, so the MFD will be able to "sync" its REFSMMAT with the one stored in the computer.


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: dseagrav on July 07, 2015, 07:47:02 AM
If your MFD is compiled with the PA source tree, you can friendclass it into the Saturn classes and access AGC erasable memory directly. See my last PAMFD update for an example. Mechanically you'd only have to share your class header, but I don't know what your legal obligations would be under the GPL.

Edit: I would not use this to WRITE into erasable, use the uplink for that.


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: indy91 on July 07, 2015, 09:40:54 AM
Yeah, I actually did look at the PAMFD update and saw that you can access the erasable memory that way. And I agree that I shouldn't use that way of accessing the memory instead of the uplink functionality.

About the legal obligations, I am certainly no expert on that and I have always just released the MFD with dll and complete source code and it's only usable with NASSP anyway. The only code used in my MFD not written by myself is the uplink stuff from PAMFD and the Multiple Buttons Pages library from the Launch MFD SDK by Enjo. It is licensed as LGPL.


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: dseagrav on July 07, 2015, 07:38:22 PM
Oh, I'm sorry, I thought you did not release source at all. Somehow I missed it.


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: indy91 on July 09, 2015, 10:56:29 AM
If your MFD is compiled with the PA source tree, you can friendclass it into the Saturn classes and access AGC erasable memory directly.

I'm trying around with this a little bit, but I get strange results. I added the ApolloRTCCMFD class as a friend class to the Saturn class. I can get it to compile, but when I try to use saturn->IsVirtualAGC() it says FALSE. The octal values I try to get from the erasables are also nonsense. I have tried compiling the ARTCCMFD independently and also tried adding it to the PA solution. Any ideas?


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: dseagrav on July 09, 2015, 04:13:04 PM
Does it pass all the gymnastics where you check the class name?

Also don't forget the call that turns the object handle into a vessel handle.

Edit: Are you trying to use the saturn class with a LM? That won't work.

Edit Edit: Also make sure that your release/debug selection matches between your MFD and PA builds.


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: indy91 on July 10, 2015, 04:46:02 AM
Thank you, it was your last point. I always tried to compile the ARTCCMFD in debug configuration, while I had compiled Project Apollo in release configuration. It does give me values from the erasable memory now, but not the correct ones. When I use e.g. saturn->agc.vagc.Erasable[0][01735] to get the REFSMMAT it instead gives me EMEM1645 and so on. It shouldn't do that, getting TEPHEM with the PAMFD works by using the values 1706, 1707 and 1710, but my MFD is currently incapable of doing that either.

Also, I was first confused by the format, the numbers are actually stored as decimal values in the simulation and not octal, I think. Shouldn't be too hard converting that back to a REFSMMAT then.


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: dseagrav on July 10, 2015, 12:19:04 PM
For reading directly from AGC memory, the first subscript is bank number.
The second subscript is address into the bank. The leading 0 of the address constant tells the compiler this is an octal address.
If there is a consistent offset, then the compiler is incorrectly setting the base address of the array. There must be some difference in interpretation of the header file between PA and MFD.

As for being stored decimal vs. octal, there is no such thing. The displayed radix is whatever you ask of printf and friends.
The binary information the computer uses is the same, only the number of bits change.

Code:
Binary 1111111100011010 equals
Octal  177432 (1 111 111 100 011 010)
Hex    FF1A   (1111 1111 0001 1010)
Decimal 65306

Note how the "spacing" (radix) changes but the pattern of one and zero stays the same.
If you use %d with printf you get decimal, %o gives you octal, %x gives you hex.
The binary data is the same.


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: indy91 on July 10, 2015, 02:00:06 PM
Yes, I think I understand now. I am using Visual Studio 2013, but I changed the platform toolset to Visual Studio 2010 and the "offset" is gone now. The conversion from the AGC format to the floating-point value of a REFSMMAT element is working now, too. Thanks for all the help.  :ThumbsUp432:


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: dseagrav on July 10, 2015, 09:34:07 PM
No problem, good to hear it worked out


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: indy91 on July 16, 2015, 03:38:51 AM
Just to conclude my little adventure with the Apollo 15 mission, I have successfully performed a rendezvous in lunar orbit using Program Artemis. I did a Apollo 10 style "No PDI" abort with the CSM and used the Apollo RTCC MFD for the DOI, Phasing and Insertion maneuvers. As I discovered earlier, P34 in Artemis only works in a retrograde and lunar orbit. Even without using the MINKEY functionality the rendezvous sequence is much more comfortable with Artemis, because you don't have to start P20 seperately. Also the W-Matrix converges more quickly in lunar orbit than in Earth orbit. The initial orbit wasn't perfect so P32 ended up with a DH of 11NM instead of 15NM, but the TPI maneuver was still 19 minutes late. Everything from there was very accurate, MCC1 had a DV of 4 ft/s and MCC2 slightly less than 1 ft/s. You also aren't under time pressure as much, because a 130 transfer takes longer in the 2 hour lunar orbit compared to the 90 minutes around Earth. All in all, I very much prefer Artemis to Colossus.  :D


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: vrouleau on July 16, 2015, 01:31:47 PM
Shouldn't this be added to the CVS repo! Keep the name, but align it with the location of the other stuff maybe, something like

Orbitersdk\samples\ProjectApollo\src_rtccmfd

instead of

Orbitersdk\samples\ApolloRTCCMFD


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: indy91 on July 17, 2015, 01:08:42 PM
Well, I don't have a lot of experience with this stuff, but I think it would require Sourceforge to work, me being able to create an account and having access to the CVS. :D


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: vrouleau on July 17, 2015, 01:49:23 PM
Yes, of course, a Sourceforge outage the same week as we start doing commits after a year.

I guess the first question is where you planning to integrate this into PAM, you did you want to leave it as a separate module. Tschachim was not been around for a while, but desgrav has admin access to add you. I could add it for you if you don't want to get into that. It's just that I feel your stuff is very good and needs to be under source control.


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: indy91 on July 17, 2015, 04:39:04 PM
I've been thinking about the topic quite a bit. Integrating it into the Project Apollo MFD would have a few advantages: one less MFD to use, uplink functionality already implemented, burn data for TLI/LOI/TEI from IMFD could be directly used to generate a Maneuver PAD or for the calculation of a LOI-2 REFSMMAT etc. etc.

But I have done a few things with the Apollo RTCC MFD that makes a integration more complicated, e.g. an instance of the MFD is bound to a vessel, so if you open the MFD in the LM you will have different numbers than on the MFD you opened in the CSM. You can also only have one instance of the MFD opened in a vessel, a second MFD just shows the same screen. I will take a look at the PAMFD and find out if that would be a problem.


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: jalexb88 on July 24, 2015, 03:09:29 PM
Hello, exciting to see more activity around here and work being done on the LM  :ThumbsUp432: I am however having an issue with the latest version of RTCC MFD. When I do a manual DV/TIG entry on the maneuver pad page, the CLC button does not spit out the data anymore. The only way to get a maneuver pad is through the auto tig/dv loading from the lambert page, that still works. However the auto loading of the maneuver pad from the ENTRY page or MANUAL loading does not work anymore for some odd reason. Here is a scenario which demonstrates this. There is a manual 100 fps burn at 005:00:00. The CLC button however doesnt work? (If you calculate a burn from the lambert page that however DOES work?)


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: indy91 on July 24, 2015, 03:41:31 PM
I've quickly looked at the code. For some dumb reason I have added the necessity to have a set target to calculate the Maneuver PAD. Will fix it in the next update. Just set any target for now. Does that also solve the problem with the  Maneuver PAD for the entry burn?


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: jalexb88 on July 24, 2015, 05:09:40 PM
I've quickly looked at the code. For some dumb reason I have added the necessity to have a set target to calculate the Maneuver PAD. Will fix it in the next update. Just set any target for now. Does that also solve the problem with the  Maneuver PAD for the entry burn?

Yes, seting a target works on my side  :ThumbsUp432: It also works for the entry burn. For that matter I have to have midcourse option on the entry page, deorbit option does not work, even in earth orbit. Not a big issue because it seems to give good numbers with the midcourse option, but found that a bit odd. Thanks.


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: indy91 on July 25, 2015, 05:28:01 AM
On the entry page, the abort option is only for Trans-Lunar Coast, the MCC option is only for Trans-Earth coast and the deorbit option is for Earth orbit. The deorbit option mostly works for me. I had very rare crashes that I couldn't track down yet though. I dread working on the entry targeting again, it's a complicated mess of implemented GSOP equations and my own creations :D


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: jalexb88 on July 25, 2015, 12:46:31 PM
On the entry page, the abort option is only for Trans-Lunar Coast, the MCC option is only for Trans-Earth coast and the deorbit option is for Earth orbit. The deorbit option mostly works for me. I had very rare crashes that I couldn't track down yet though. I dread working on the entry targeting again, it's a complicated mess of implemented GSOP equations and my own creations :D

Its good as is  :ThumbsUp432: I guess the LM is the focus now, I am eager to get that thing flying. Wish I was a programmer to help you guys out.  :sorry345:


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: dseagrav on July 25, 2015, 04:24:37 PM
I guess the LM is the focus now
Not quite, it's time to start thinking about it, but we have to get Apollo 7/8 out first.


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: indy91 on July 28, 2015, 09:58:42 AM
Update:

-A few boring internal reorganizations and bug fixes
-Added the option to get the current REFSMMAT from the AGC. Only works with the CSM for now. It also might only work correctly with NASSP compiled in Visual Studio 2015, I am not sure.
-Finally fixed the Orbit Adjustment functionality. It also should work in lunar orbit, so it is usable for the LOI-2 maneuver. Let me know if it still calculates completely unrealistic maneuvers, then I have to do more work on it.

I am using Visual Studio 2015 now, please let me know if there are any new issues with the MFD which might be caused by that.


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: jalexb88 on July 29, 2015, 01:45:41 PM
Update:

-A few boring internal reorganizations and bug fixes
-Added the option to get the current REFSMMAT from the AGC. Only works with the CSM for now. It also might only work correctly with NASSP compiled in Visual Studio 2015, I am not sure.
-Finally fixed the Orbit Adjustment functionality. It also should work in lunar orbit, so it is usable for the LOI-2 maneuver. Let me know if it still calculates completely unrealistic maneuvers, then I have to do more work on it.

I am using Visual Studio 2015 now, please let me know if there are any new issues with the MFD which might be caused by that.

Nice update! The orbit adjustment works good on my side from the few tests I've done, I will continue looking to see if I find anything unusual, but looks good so far. As far as the REFSMMAT download, it does not work on my end, but my last compile was on 2010 so that must be the reason. I will update to 2015 and report back. Thanks again!


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: indy91 on July 30, 2015, 05:44:44 AM
As far as the REFSMMAT download, it does not work on my end, but my last compile was on 2010 so that must be the reason.

No, of course it can't work, my MFD does not have access to the REFSMMAT of the CSM, because I only added it as a friend class in my local copy.  :Duh!39835:

So the MFD is only ready for that feature, but it can't work yet. If you really want to try it, search the line "friend class ProjectApolloMFD" in the file saturn.h and add the line "friend class ApolloRTCCMFD;" below it.


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: dseagrav on July 30, 2015, 05:57:33 AM
I'm not sure but I think class restrictions really just tell the compiler it's OK to emit code that does X from Y. I don't think it results in any actual access control once the code is compiled.
I'd have to try it and see.



Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: indy91 on August 12, 2015, 04:52:45 AM
The MFD is now part of NASSP. There is one major update included compared to the old version at the top of this thread:

-Non-impulsive maneuver compensation

On the basis of Space Shuttle ascent guidance equations, the DV vector and time of ignition of a maneuver are corrected to reach the desired trajectory. The desired trajectory is simply calculated by adding the DV at the original time of ignition (impulsive maneuver). The rule of thumb is, if you have an 8 second burn just start it half of the maneuver time (4 seconds) early, to get a better result. That's exactly what the MFD can now calculate with more accuracy. I have tried it with the Apollo 7 NCC1 and NSR maneuvers and the resulting coelliptic trajectory is spot on. I think that's actually the way they did it, too. The "baseline" TIG for the NCC1 maneuver was 026:25 GET, but the actual TIG the astronauts got with the Maneuver PAD was about 026:24:55 GET.

There are a few things I don't quite understand yet though. The DV vector is modified by the routine, but not in the way i expected it to. The CMC does an internal finite burn compensation by rotating the DV vector for half the central angle traveled during the maneuver. I thought I would have to rotate the resulting DV back, so to speak, so that the AGC gets the right vector, but that is not the case. So that leads to some inaccuracies for the maneuver I hoped to be able to calculate now: the LOI-1 maneuver. I used the Orbital Adjustment maneuver page of the MFD with the time of periapsis, 60NM x 170NM orbit, and the desired equatorial inclination. The resulting numbers for the apocynthion and pericynthion on the Maneuver PAD were 61.5NM x 167.5NM and that's exactly the orbit the CSM had after the maneuver. So the MFD is better at predicting maneuvers than calculating them.  :ROTFL3453:

Anyway, all types of maneuvers calculated with the MFD now have an adjusted TIG and should be more accurate. And maybe one of these days I understand why the new functionality isn't quite behaving as I expect it.


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: indy91 on August 15, 2015, 04:12:37 AM
I pushed an update to github.

-Fixed finite maneuver compensation: I have solved the issues I described in the post above. Nonimpulsive maneuvers are now calculated very accurately, I was even able to fly a good LOI-1 with it, although it was not the most efficient maneuver and there is no control over true anomaly, which makes LTMFD still the vastly superior tool for this burn. The functionality is mostly meant to solve issues with TLC aborts. These maneuvers can be so long, that the assumption of an impulsive burn is very inaccurate and leads to MCCs of a magnitude of 100 ft/s. Now there almost is no need for another MCC at all.

-Entry range adjustments: on the "Entry Update" subpage, which you find if you click MOD once on the Entry page, there now is the option to adjust the desired range from 0.05G to spalshdown. If the value is set to zero, the nominal range will be calculated and used. A good practice to use this is to first calculate the nominal splashdown coordinates and range. E.g., in my scenario with a very high speed reentry the nominal range is about 1490 NM. If I set the desired range to 1250 NM I got very unhappy astronauts that had to endure 9G. If you set the range longer than nominal, you might be able to practice using P65 and P66. Don't forget to uplink the splashdown coordinates from that page.


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: indy91 on August 20, 2015, 07:52:08 AM
Another small update, mostly for the Apollo 7 phasing maneuver:

-LVLH X-axis maneuver: The Lambert page has now the option to calculate a "normal" multi-axis maneuver or enforce a purely horizontal maneuver (no component in the z-axis) by varying the offset position in the z-axis. Up to now, the user had to find the correct value for ZOFF by trial and error, so that the phasing maneuver only had a component in the x-axis. Now the option "x-axis" does this automatically, which will be needed for the MCC functionality. So the usual inputs for the maneuver are :

TIM = GET
T1 = 03:20:00 GET
T2 = 26:25:00 GET
N = 15
AXI = X-Axis
SPH = Spherical (The X-axis calculation only works with this option set to spherical !)
TGT = AS-205-S4BSTG
XOFF: 80 NM (or 76.5 NM? I still haven't seen the correct number for this. Set by typing X=80 )
YOFF and ZOFF = 0 (ZOFF will be calculated by the MFD).

Should be about an -1.9 to -1.7 ft/s maneuver.

-RCS -X maneuver. When we talked about the phasing maneuver in the other thread, I noticed that the RPY angles are way off compared to them being calculated on the Maneuver PAD page. Actually, the pitch was exactly 180 off. They used the -X thrusters for the maneuver and not the forward (backwards of course) directed +X thrusters. So I added the option for a RCS -X maneuver. Just press ENG on the Maneuver PAD page twice to set the option to "RCS -X". Also make sure it is set to "Heads Down" and then I get RPY angles only 1 off from the historical Maneuver PAD.


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: indy91 on August 26, 2015, 04:19:43 AM
I pushed another update ot github.

-Some minor internal reorganizations.

-Improved reentry calculations. I have fixed two long term bugs in the Earth deorbit calculations. Calculating a deorbit is actually more difficult than a Translunar Coast abort, because it doesn't have a unique solution, but instead two possible (local) minimum DVs. Anyway, problems with the reentry calculations should be much rarer now.

I also added another option for the deorbit, so now you can choose between a minimum DV deorbit burn or a "nominal" deorbit. While P37 is calculating a minimum DV maneuver, if you don't provide a desired DV magnitude, that's not actually how the nominal deorbit maneuver happened on Apollo 7 and 9. Instead, the attitude of those burns was so chosen, that the 31.7 line could be placed on the horizon, which would have made a manual burn much easier for the astronauts. This new calculation method will also come in handy for the Apollo 7 Block Data calculations, although I haven't researched if that is how they calculated the Block Data.


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: pattersoncr on August 28, 2015, 09:27:11 PM
Where do I need to go to get the latest version?  I don't understand how to get it off github.


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: indy91 on August 29, 2015, 11:46:04 AM
Well, it's now part of NASSP, so you build the newest version of the MFD by building NASSP. I'll update the dll in the top post with the newest version, the only problem is that the the RTCC MFD build in Visual Studio 2015 is not 100% compatible with the latest Beta release. Specifically, the REFSMMAT downlink won't work. Other than that, it should be good.

EDIT: Hmm, the file size of the DLL is smaller than it was before, maybe it doesn't work as a standalone? Anyway, I don't want to break the working MFD version at the top post, so here the newest version of the MFD. Please report if it is working.

EDIT2: No real need for this anymore, there are now up-to-date releases on github.


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: indy91 on September 06, 2015, 11:23:06 AM
Update: The reentry targeting has been completely reorganized and (again) some long-term bugs have been fixed. This might have created some new issues with midcourse corrections and TLC aborts, but at least the Earth orbit reentry can now be calculated more reliably and (probably more important) without crashing Orbiter too often. It's still a horrible mess (mostly because P37 of the AGC is a horrible mess!), but the newest update makes things better. Hopefully it's stable enough to be included in the automatic MCC-H calculations.


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: indy91 on September 11, 2015, 05:51:39 AM
One more thing about the entry targeting. Just like P37, it uses a conic phase and a precision phase. There is a problem with the nominal deorbit attitude function in combination with the precision phase. The precision phase imposes additional constraints on the resulting flight path angle after the deorbit burn to ensure convergence. For time and fuel critical returns this isn't a problem, of course, or else P37 wouldn't work. But unfortunately this means, that the desired deorbit attitude (31.7 line on horizon) can't always be reached. It does calculate proper deorbits without crashing Orbiter, but not in the intended attitude. This issue can't really be solved because its roots lie at the heart of P37.

We don't currently have a view out of the window with the 31.7 line that actually is at 31.7, but I still don't find it acceptable to not calculate the proper attitude for the deorbit. The only way this can be solved at the moment, is disabling the precision phase, when the calculations run into the precision phase constraints. The resulting differences in the 15-30 minutes coasting trajectory after the deorbit burn to Entry Interface are not too bad. Our spherical Earth in Orbiter 2010 causes worse deviances to the reentry. So, should I go ahead and implement this? It does not affect TLC aborts or TEC MCCs.


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: indy91 on October 17, 2015, 10:02:00 AM
Update:
-I moved the Lambert calculations to the RTCC class, so if anything is broken there, please let me know.
-The range-to-go calculations for the Entry PADs now use the P61 method instead of the P37 method. P61 displays the range as a backup value for the EMS initialization, which should be more accurate than the estimate used in the reentry maneuver calculations of P37.
-Changed a few things regarding the splashdown coordinates. I had too many versions of those in the MFD and that caused a lot of confusion for my part. Basically, there where coordinates as a result of a reentry maneuver calculation, then the predicted coordinates from the Entry Update page, where you can adjust the range, and then the PAD values, which in the case of a Lunar Entry PAD without a MCC were simply the coordinates where the CM would splash down following a nominal reentry. Of course numbers like the EMS range have to correspond to the splashdown coordinates stored in the CMC, or else they might be off a few NM. That's why I added the option to "downlink" those values from the CMC on the Entry PAD page. Nominally though the PAD will take the values from the Entry page.


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: eddievhfan1984 on October 17, 2015, 11:14:18 AM
Will you retain the code for the non-spherical Earth for the Orbiter beta, since it's now implemented there?


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: indy91 on October 17, 2015, 11:57:15 AM
I'm not sure I understand your question. I have done basically no work with the correctly shaped Earth in Orbiter 2015. Whenever I implemented some AGC routines that needed the actual altitude above ground (e.g. calculations for reentry maneuvers and Entry PADs) I just skipped these part of the routines. To make it compatible with Orbiter 2015 I will have to revisit everything involving the reentry. It shouldn't be too much work, but it does make a few things more complicated.


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: eddievhfan1984 on October 17, 2015, 10:23:31 PM
Oh, I thought you started everything with the non-spherical Earth, and then had to convert the routines back to spherical Earth. :P


Title: Re: Apollo Rendezvous MFD
Post by: indy91 on October 24, 2015, 01:46:29 PM
The Apollo 10 crew charts you posted reminded me of something.  Included in them is a chart of SPS Tailoff thrust vs CSM weight.  Tailoff thrust is caused by the amount of thrust that happens after the signal has been given to shut down the engine.  I would assume this is caused by the finite amount of time it takes the SPS ball valves to roll shut plus the fuel and oxidizer that are already downstream of the ball valves when they go shut.  The CMC accounts for tailoff thrust but the EMS dV counter does not. This is responsible for the difference between Vt (total dV to be gained) and Vc (dV setting on the EMS).  I notice that the Maneuver PAD on your MFD shows Vt but it is labeled as Vc.
I suspect that tailloff thrust is a constant (force) value and that Vt - Vc = F/M  where "M" is CSM weight.

Does anyone know if NASSP accurately models tailoff thrust?

By the way, the A10 charts also include a handy chart showing whether or not an RCS ullage burn is required for SPS burns.  I've included it in the multitude of updates I want to make to the G&C Checklist.

I've finally figured out the correct answer to this. Tailoff thrust is currently not modelled. However, in Colossus 249 the tailoff thrust is the padloaded value ETDECAY (EMEM3015), which we don't use i.e. is set to zero. What do we do with this knowledge? There is not exactly a need for modelling tailoff thrust, except having a correct EMS DV value on the Maneuver PAD and Earth Orbit Entry PAD and maybe a few other things I am missing.

If we want to use it, I'll guess we should decide on a constant impulse caused by the SPS tailoff for all missions. The reason for changing it to a padload instead of a fixed constant (some time pre C237, at least in the GSOP it's still fixed) is that the different SPS engines used in each missions had a little varying performance and tailoff characteristics. We probably don't know the correct value for every mission, so choosing a value that is e.g. consistent with the Apollo 10 crew chart would be sufficient.

Oh, I thought you started everything with the non-spherical Earth, and then had to convert the routines back to spherical Earth. :P

Of course not, the calculations with a spherical Earth are easier, so I went the lazy way.  :ROTFL3453:


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: indy91 on November 06, 2015, 03:42:51 PM
I've done some work while the forum was down, but I didn't want to upload it, because I like to let BuildBot check if I screwed something up.

Ok, here is what is new:

-Thread for iterations. Basically the calculations of the MFD are now done in an external thread and not in Orbiter. This means that (just like the same calculations with the MCC) Orbiter doesn't freeze now for a few seconds when e.g. an abort or midcourse correction maneuver is being calculated.
-More boring reorganization of the RTCC class, mostly pushing stuff over from the MFD.
-At this point almost obligatory entry targeting fix
-Lunar Orbit Insertion mode. This mode allows the calculation of MCC3, MCC4, LOI-1 and LOI-2 for Apollo 8. I've added this mainly to test if the Lambert Targeting can calculate a TLCC and indeed it can (which some small modifications)!

From an Apollo Experience Report and an Apollo Mission Technique document I know that the last two TLCC (MCC3 and MCC4) were targeted with the so called nodal (XYZ and T) mode. This means that a specific position at a specific time is the target. That is basically what LTMFD is currently doing, I think. A good target is the pericynthion, for tests with MCC4 I have used these numbers:
Latitude: -8.6?
Longitude: -172?
Altitude: 65.82NM
Pericynthion time: 69:10:39 GET
MCC4 time (LOI-8) : 61:10:39 GET

The LOI-1 mode has the one advantage over LTMFD that you can choose an selenographic inclination, the inputs I have used are:
ApA: 170NM
PeA: 60NM
Inc: 168?
Impulsive maneuver time: 69:10:39 GET

A small disadvantage is that currently only thrust integrals are used for the LOI-1 calculations, which is of course less precise than a numerical method as used by LTMFD. The difference is small though, the resulting orbit has the parameters: 60.4NM x 169.6NM.

For LOI-2 the only input is 60NM as the circular orbit.

We will see how useful this stuff actually is in the future, if jarmonik does a LTMFD 2.0 with even better compatibility with NASSP, but at least the LOI-2 REFSMMAT (and in the future the LS REFSMMAT which was also uplinked before the last MCC) could now be properly calculated in the MFD. I haven't added this yet though.


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: indy91 on November 17, 2015, 09:08:02 AM
A few updates:

-LOI-2 REFSMMAT option: The procedure for this is calculating on the LOI page first the last TLCC, then the LOI-1 (with MCC) and then on the REFSMMAT page verifying the numbers for the maneuver and then calculating and uplinking the numbers for the REFSMMAT.
-TECC improvements: I've modified the entry targeting slightly to aid the iteration in finding a solution close to the moon. With these changes the MFD can now calculate a TECC in the lunar SOI as early as PC+4 hours, instead of about PC+10 as before. Sadly this isn't quite good enough yet for the PC+2 abort PAD the astronauts got at about 60h GET, but PC+4 or later does work even that early in the flight. Orbiter doesn't freeze anymore if the iteration becomes stuck, but interrupting it doesn't work yet and the MFD becomes useless and crashes Orbiter when closing Orbiter. Also, make sure to specifiy a reentry angle (-6.5 or so), the internal calculation does not work very good for an early TECC.
-Entry range adjustment: Basically, there is no need for using the exact P37 numbers anymore, which lead to an abnormally high entry range for a lunar entry. Now the entry range will be much closer to a ground targeted reentry. The numbers need some more tweaking I guess, but it should be closer to a nominal reentry now. Actually using P37 is the backup procedure, while the RTCC should calculate a normal reentry.

One more note about the targeting for the LOI-1 maneuver. Sadly I can't recommend using it for a precise orbit insertion at the moment. During my testing I had strange, varying results. Sometimes the resulting orbit was close to the desired one, sometimes it was rather off (65NM x 165NM) which is not an acceptable accuracy. I'm not sure if it is a bug or a deficiency of the rather simple non-impulsive burn correction. Anyway, the solution is certainly good enough for the LOI-2 REFSMMAT calculation. You can test the LOI-1 with the solution of the RTCC MFD, or to be sure that you get the correct apoapsis and periapsis with LTMFD.


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: jalexb88 on November 20, 2015, 12:01:53 PM
I've flown the whole Apollo 8 mission again with your latest updates Indy. I managed to fly the whole thing with only your MFD save TLI and TEI.

-Trans-Lunar MCC's: Wow! Awesome job on this! All the MCCs going to the moon worked, even as early as MCC-1. The only thing is that the TLC MCC's with your MFD seem to give out only moon SOI velocities. In MCC 1 to 3, we are still in Earth SOI so the the moon centered DV's dont work in P30. My workaround for this was to burn in SCS with the PAD calculated gimbal angles for MCC1 and it works like a charm. RTCC seems to do as good a job as LTMFD as my orbit insertion position and altitude were identical to my earlier flights.

-LOI-1/2 and LOI REFSMMAT: This all works perfect on my side. I had a final LOI-2 attitude of 000,181,359. LOI-1 was right on the money, off by .2 NM at most. One thing I did was to set the TIG to 69:10:30 so the non-impulsive time would be set to the real 69:08:20

-Lunar SOI TECC's:  I tried a PC+4 abort. It got me in the ballpark and only required a +/- 50 fps burn later on to get me home.  :ThumbsUp432: If we are doing a TECC in lunar SOI, how do we set the REF in the config page? Earth or Moon? Also, would this count as an Abort or a midcourse option in the ENTRY page as  I find that both options yield different velocities.


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: indy91 on November 20, 2015, 03:32:15 PM
I've flown the whole Apollo 8 mission again with your latest updates Indy. I managed to fly the whole thing with only your MFD save TLI and TEI.

-Trans-Lunar MCC's: Wow! Awesome job on this! All the MCCs going to the moon worked, even as early as MCC-1. The only thing is that the TLC MCC's with your MFD seem to give out only moon SOI velocities. In MCC 1 to 3, we are still in Earth SOI so the the moon centered DV's dont work in P30. My workaround for this was to burn in SCS with the PAD calculated gimbal angles for MCC1 and it works like a charm. RTCC seems to do as good a job as LTMFD as my orbit insertion position and altitude were identical to my earlier flights.

The gravity reference/SOI stuff makes me quite a bit of trouble, as the programmer of the MFD and as a user. In the future I might get rid of the manual setting on the configuration page completely, because it just complicates things. The trajectory propagation method of the MFD can choose the SOI on it's own, so that should result in a flexible SOI for the DeltaV vector. So any maneuver would simply be calculated in the SOI in which the maneuver occurs.

If MCC-3 is in the Earth SOI, then of course that functionality needs to be added to the MFD. I think currently the SOI has to be set to Moon, if it is supposed to work for a TLCC. How big were the MCC3 and MCC4 maneuvers for you?

Quote
-LOI-1/2 and LOI REFSMMAT: This all works perfect on my side. I had a final LOI-2 attitude of 000,181,359. LOI-1 was right on the money, off by .2 NM at most. One thing I did was to set the TIG to 69:10:30 so the non-impulsive time would be set to the real 69:08:20

I am happy that the LOI-1 targeting worked for you. I've tested it twice and had differing results I couldn't quite explain. Might have been a procedural error on my part.

Quote
-Lunar SOI TECC's:  I tried a PC+4 abort. It got me in the ballpark and only required a +/- 50 fps burn later on to get me home.  :ThumbsUp432: If we are doing a TECC in lunar SOI, how do we set the REF in the config page? Earth or Moon? Also, would this count as an Abort or a midcourse option in the ENTRY page as  I find that both options yield different velocities.

I'v pretty much replaced any use of the manual SOI setting from the reentry targeting. Reentry on the moon wouldn't make much sense of course. I'm not sure if it still has to be set to Earth for a TECC, it used to be like that. I think it can now be safely used with the actual SOI (Moon or Earth).

For an early TECC/free return course correction both the abort and midcourse option should work. The main difference is the initial guess for the resulting trajectory. The abort option uses the steepest/fastest possible return within the DV budget (fixed to 10k ft/s at the moment). The midcourse option uses the current trajectory as the initial guess. So for a TLC abort and a TECC far away from the Earth the resulting EI time might have a ca. 24/48 hour difference. This is realistic, Apollo 13 did a PC-2 burn that speed up the return by about 24 hours. At the moment there isn't any control over this difference though, so the abort option might result in quite long burns. The Entry PAD also still has problems with those burns, so the midcourse option should be used for a "nominal" PC+2 or PC+4 or whatever works right now. Also, the targeted PC+2 splashdown longitude for Apollo 8 was -25, not sure if I had mentioned that anywhere.


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: jalexb88 on November 21, 2015, 10:38:22 AM
If MCC-3 is in the Earth SOI, then of course that functionality needs to be added to the MFD. I think currently the SOI has to be set to Moon, if it is supposed to work for a TLCC. How big were the MCC3 and MCC4 maneuvers for you?

I believe that MCC-3 being at the 47 hour mark, would be in Earth SOI. On my last attempt, I only performed MCC-1 at 11:00:00 being about 25 fps with your MFD, then MCC-4 at 61:00:00 being about 2 fps. So MCC-3 is most probably in Earth SOI, but MCC-1 and 2 are definitely in Earth SOI so I think it would be appropriate to have an option for Earth SOI DV values as the early TLCC's seem to be very accurate with your MFD, although right now we have to use SCS using the PAD angles for the burns in Earth SOI.


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: indy91 on November 21, 2015, 12:36:51 PM
The TLCCs can now be calculated in the Earth SOI, too. I tested it by performing a MCC at 8h(!) GET, seems to work just fine. The nominal use of this kind of targeting only applies to MCC-3 and MCC-4 though, because it does not leave the spacecraft on a perfect free return trajectory.

I also changed the EMS setting on the Maneuver PAD slightly. The SPS of our CSM currently doesn't have tailoff thrust, so I removed the tailoff impulse from the calculations and the EMS setting only accounts for the SPS engine being off-axis now. Even for long maneuvers this should only be a few feet per second and if you really want to do a LOI or TEI maneuver with the SCS, shutdown now occurs at the correct DV.


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: jalexb88 on November 22, 2015, 01:10:59 PM
Awesome, thank you! I guess all that's left as far as MCC targeting is LVDC++ TLI functionality and TEI.  :ThumbsUp432:


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: indy91 on December 03, 2015, 07:35:46 AM
I've added a quite preliminary version of the TLI PAD as the 3rd option on the Maneuver PAD page. To easily get the numbers for it into the MFD, I've also added a "request burn parameters" button similar to the Project Apollo MFD. So now you can calculate the burn with LTMFD and then load the numbers into the RTCC MFD to get the PAD and into PAMFD to execute the burn. Of course loading the numbers from LTMFD also works for other maneuvers (TEI, LOI or MCCs). This was possible before by using the manual TIG and DV input methods, but now it is more comfortable. I've tested a TLI with the PAD, the PAD values for the EMS DVC and the inertial velocity at cutoff seem to agree quite well with the actual cutoff conditions. The non-LVDC TLI steering doesn't force a heads-down attitude, so the roll angle on the PAD might be off right now. No idea how the separation attitude is handled, so it isn't calculated right now.

While looking at the IMFD/LTMFD interface, I noticed that among the generated burn data there also are the cutoff position and velocity. This will be helpful for the LVDC, because it should be quite possible to convert the cutoff state vector to the LVDC targeting parameters.


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: indy91 on December 05, 2015, 12:30:30 PM
I've added the gimbal trim angles to the Maneuver PAD displayed on the MFD. For the CSM alone case they will always be 0 in our current configuration, in the CSM/LM case they can be up to about 1. Maneuvers with the LM attached are currently a problem, because the TVC DAP doesn't work for it and the SCS keeps it stable, but introduces a small steady state error. I think I can improve the SCS Auto TVC, we'll see. But for a short maneuver the trim angles at ignition work fine. For a CSM/LM maneuver now also the LM weight is displayed and the rest of the Maneuver PAD (burn time etc.) also takes the LM into account.

The Maneuver PADs displayed by the MCC functionality are the ones used for Apollo 7, the one displayed on the MFD is Apollo 8 and later. Not sure how to deal with differences of the PADs for different missions. The Maneuver PAD in the MFD is now almost complete, only the boresight star check is missing. We don't have an adjustable COAS in NASSP, but if available, a COAS star should be calculated. I will add that next, just for the sake of having the full Maneuver PAD.


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: indy91 on December 10, 2015, 01:47:09 PM
Two updates concerning the MFD:

-The finite burntime compensation now includes a short numerical computation based on the Average G routine. I tested it for the LOI-1 maneuver and the resulting trajectory was perfect. As good as LTMFD anyway.  :cool7777:
-COAS star check: I have simplified this by using a very small cone angle, so it should be rarely the case that a boresight star is actually available. But if it is available, then it should be actually visible in the left rendezvous window. I'm not 100% about the geometry of this yet though.


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: indy91 on January 24, 2016, 06:31:14 AM
The MFD does the finite maneuver compensation for CSM/LM maneuvers now. This only applies to Lambert Targeting, TLCC, LOI and Orbital Adjustment maneuvers. I have tested it with a LOI-1 manuever, as I said in the Virtual AGC thread, seems to work very well. The setting for the vehicle on the Maneuver PAD page has been removed; instead there are now four options on the configuration page:

-CSM
-CSM/LM for docked, CSM powered maneuvers
-LM: currently not used for any maneuvers yet, of course, but this setting is necessary for uplinks like state vector or REFSMMAT during the LM Activation Checklist
-LM/CSM for docked, LM powered maneuvers

Once the LM is capable of it, this option would change e.g. the Maneuver PAD to the LM Maneuver PAD.


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: indy91 on January 26, 2016, 07:02:00 AM
TEI capability:

This is a very limited capability right now. All it really does is tweak a TEI burn solution calculated with LTMFD so that it is compatible with the RTCC reentry targeting and precisely targets the splashdown coordinates. It needs an initial guess from LTMFD for the TIG and DV vector. It then also uses that initial guess to calculate the heading at EI. Additionally the burntime calculated by LTMFD is used to approximate the TIG a little bit better. There is also no kind of DV optimization happening, so it kind of relies on the LTMFD TIG being good.

Here is how the nominal procedure for the Apollo 8 TEI would look like:

-Calculate the TEI with LTMFD. Parameters are: Mod: Reentry, TIg: Auto, ReT: 146:50:00, ReA: 6.5, Hed: 121.57,TIg: should be about 89:16:00 with auto, then press EXE.
-open RTCC MFD press ENT and MOD three times to access the TEI targeting on the fourth page of the entry targeting.
-press REQ to import the maneuver solution from LTMFD as the initial guess. The TIG and DV should be displayed now.
-press TIG to set the Entry Interface GET (146:50:00) as an initial guess. The actual time will be adjusted so that the correct reentry angle for the reentry velocity is attained.
-Set the splashdown longitude to manual and -165 or simply choose the Mid Pacific landing zone.
-Press CLC and the MFD should come up with a maneuver solution not too far away from the initial guess.

This procedure allows a TEI consistent with the RTCC Trans-Earth Midcourse Correction targeting. The first MCC would have been <1 ft/s for me during testing. So in theory one very short TECC should be enough.

In the future I might add to this functionality, if it has any use:
-targeting splashdown latitude.
-letting the user choose the EI GET and judge themselves, if the reentry angle is good enough.
-calculating the initial guess. I'm not sure how good the targeting can deal with initial guesses that are less accurate than the LTMFD solution. This might be the most difficult point, but the RTCC MFD wouldn't rely on the LTMFD solution then.


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: jalexb88 on January 27, 2016, 10:55:06 AM
Awesome stuff, looks like you're getting closer to a complete RTCC solution! Will it be easy to also compute the aborts such as PC+2 and TEI 1 to 11?


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: indy91 on January 28, 2016, 06:16:35 AM
Awesome stuff, looks like you're getting closer to a complete RTCC solution! Will it be easy to also compute the aborts such as PC+2 and TEI 1 to 11?

I already discovered some smaller bugs, but yes, it can calculate Flyby and PC+2 maneuvers, because you can calculate them with LTMFD, too. I get much larger DVs with LTMFD (and RTCC MFD) than the historical Maneuver PADs, I guess you have to do a lot of trial-and-error with the heading angle to get a nicer maneuver solution!? I honestly don't have much experience doing these things with IMFD or LTMFD.


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: indy91 on February 18, 2016, 09:52:22 AM
Update for the MFD: Landmark Tracking PAD

The necessary inputs are:

-Initial guess for T1 (time when the CSM is at 0 elevation from the landmark)
-Actual latitude and longitude

Currently displayed are:

-T1 (see above)
-T2 (spacecraft at 35 elevation. Depending on the tracking profile, at this time a 0.3/s pitch down is initiated)
-Distance north or south of groundtrack
-Noun 89, the latitude, longitude and altitude for P22. For the moon these are identical to the input lat and long, for the Earth you have to trick the AGC, because it assumes an ellipsoid Earth, while the Orbiter 2010 Earth is a sphere. So the N89 latitude and altitude are different.

The landmark tracking PAD was often changed from mission to mission, so I used the one from the Apollo 11 flight plan. These are the most useful numbers I guess. I could also add the gimbal angles and the sextant angles at acquisition (T2), the Apollo 10 flight plan has those values, too. And much later there will also be the P24 Ldmk Tracking PAD, but only Apollo 14 and later had that program.


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: pattersoncr on February 19, 2016, 08:11:57 AM
What locations did you use for landmarks?  I put a partial list in my A7 flight plan but I don't know if the ones I picked were actually used. I just flew the mission to that point and picked a city marker that seemed to be in a good position at the right time. I wasn't able to find an actual landmark list for A7 (there is one for the A8 lunar landmarks).


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: indy91 on February 19, 2016, 08:53:23 AM
I am currently flying the whole Apollo 7 mission to test the MCC functionality and I am in the middle of the second landmark tracking period (144h GET). So far I have used the landmarks from your flight plan. Some of them were quite far away from the ground track, but usually it's possible to do the tracking. And a list of landmarks would indeed be nice, they probably had a lot more to choose from and wouldn't have used those who are so far from the ground track, I imagine. Maybe looking through the transcript will help with finding out which landmarks were used.

Landmark tracking in LEO isn't an easy task. I am still not quite sure about the best technique. If the landmark is quite out-of-plane, then an initial roll angle is helpful. At T2 (35 elevation) I am beginning a ca. 0.5/s pitch down rate and then perform marks every 15 seconds. Even then it's a tight schedule. Also, I think the W-Matrix is confusing me again. Noun 49 (DR and DV) is always all zeroes, but the final Noun 89 (Lat, Long/2, Alt) is not the same as the input coordinates. I think I've had that problem before, but reinitializing the W-Matrix with V67 somehow doesn't help. I can't imagine I am that good.  :ROTFL3453:

EDIT: During the second landmark DR and DV were now greater than zero, so it all seems to be working.


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: indy91 on April 10, 2016, 11:27:26 AM
A pretty big update incoming, standalone TEI/TLI targeting plus the implementation of these maneuvers in the MCC functionality for Apollo 8. Just a little bit of code cleaning and testing to do and it will be commited. I have some time to write my notes about it down, so here is how it works.

TEI:

In the MFD the TEI targeting is on the fourth page of the Entry targeting. The options are similar to the normal Entry (outside of the lunar SOI) targeting: Initial guess for the time of ignition and landing area/splashdown longitude. Additionally there are the three TEI modes: Trans Earth Injection, Flyby, PC+2. Trans Earth Injection is obviously a maneuver from the lunar orbit after LOI. Flyby and Pericynthion + 2 hours (PC+2) are two abort maneuvers. The flyby maneuver is basically a course correction for the free return trajectory, performed when the last translunar MCC would be done in a nominal case, so for Apollo 8 this would be at about 61h GET. The PC+2 maneuver is similar, but done after passing the pericynthion in the case the LOI is not performed. 2 hours after PC seems to be a very DV friendly time to do a course correction. It is also possible to move the splashdown area or shorten the transfer time between Moon and Earth in the case of a time critical abort. The fast return PC+2 maneuver that was planned for Apollo 8 and read up as a Maneuver PAD would have resulted in a reentry 40 hours earlier than the free return trajectory. Apollo 13 did both a flyby course correction instead of a MCC and a fast return PC+2. They didn't move the landing area, but they speed up to reach the Mid Pacific 24 hours earlier.

For TEI, the TIG estimate is used to find the injection time with a minimal DV. So the estimate should be fairly good, 20-30 minutes off are ok. Not sure what happens when the estimated TIG is on the wrong side of the Moon though. For Flyby no such TIG search is done, the input TIG is used as the TIG. For PC+2 no TIG estimate is needed, because it calculates the time when 2 hours after pericynthion is reached itself.

To realize different return times (TIG to Entry Interface), I have implemented an option for a slow, normal or fast return. The "normal return" is what all nominal TEI and flyby maneuvers should use. Slow and fast return reach the desired splashdown area 24 hours later or earlier than the normal return. At least it should be 24 hours, in some border cases it could be 48 hours by accident. It's pretty fun playing around with these numbers for the TEI and PC+2. As a test I have performed the TEI-4 maneuver, basically a return of Apollo 8 to the Earth 2 revolutions after LOI-2 already. The normal return resulted in a 3000 ft/s maneuver with splashdown happening at the same time as the free return trajectory and the normal TEI (TEI-10) would have happened. But it is also possible to do a 24 hour slower return (in a fuel critical case I guess) with only 2800 ft/s. And additionally, Apollo 8 probably is the only mission with enough fuel for an even faster return, resulting in a 4600 ft/s TEI maneuver.

The only annoying thing with the TEI targeting is an undesirable high out-of-plane component for the maneuver. I know what causes it, but haven't found a good way to solve this problem; it is only really noticable for a Minimum DV PC+2 maneuver though. There the out-of-plane component is about 300 ft/s in my testing, while it should probably be close to zero with the overall burn being very short. For a large maneuver like the TEI this effect becomes quite small.

TLI:

You can calculate the TLI with the RTCC MFD now, which I have added as another option on the LOI page. I am really running out of pages in the MFD.  :ROTFL3453: It pretty much works exactly like a TEI (TIG optimization), but with the same targeting parameters as a translunar midcourse correction. There is no uplink capability to the IU in the RTCC MFD, so this is only really useful for the TLI PAD. But the TLI calculation will be used for calculating LVDC parameters in the future. I  also have added all the TLI and TEI options to the Apollo 8 MCC functionality and I will explain the new stuff concerning the MCC in the "What needs done?" thread once it is finished.


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: eddievhfan1984 on July 03, 2016, 04:48:16 PM
Can you crosscheck something in the Entry PADs? They're giving off RTGO .05G ranges that are 10 times as high as they should be...


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: indy91 on July 04, 2016, 03:27:09 AM
Earth Orbit Entry PAD or Lunar Entry PAD? Those are calculated very differently. Also, are splashdown latitude and longitude correct and not zero? And if you could post a scenario with the state of the RTCC MFD saved when the problem occurs, that would be great. My first immediate test doesn't show any new bugs and correct RTGOs.


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: eddievhfan1984 on July 04, 2016, 10:04:51 AM
Here. I'd include a screenshot, but the server keeps throwing HTTP 500 when I try to upload.

The odd ranges intermittently pop up, but when they do, they don't change, almost like there's some kind of overflow.


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: indy91 on July 04, 2016, 10:44:10 AM
Have you used the manual TIG and DV input on the Maneuver PAD page after calculating the deorbit maneuver? Because the manual input overwrites the TIG and DV used for the Entry PAD, while it still tries to reach the original landing coordinates. So the entry range can deviate significantly. A simple recalculation of the entry maneuver and then calculating the Entry PAD again solves the issue.

I guess this part of the code could use some rework, so that it is clear which DV is used for the Entry PAD. There are separate TIGs/DVs for the different calculation pages (Lambert, coelliptic, Entry etc.) but when the maneuver is calculated the TIG and DV are also copied to the "general" TIG and DV variables. That way you can have different TIG/DV on different pages, but also use any kind of maneuver solution for the PADs. Not a perfect system, the Entry PADs should probably only use the converged maneuver solution from the Entry page (corrected TIG and DV for finite burntime).


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: eddievhfan1984 on July 04, 2016, 12:40:01 PM
I use the MCC's PAD and just load it into the MFD for reference, since the MCC PADs are not persistent with scenario reloads.


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: indy91 on July 05, 2016, 04:15:03 AM
Yeah, as I said, it will try to use the manual loaded TIG and DV for the Entry PAD, but without having the associated splashdown latitude and longitude it will try to calculate the range to the wrong coordinates. That really is unintended behavior, so I will change the MFD to only use the TIG and DV from the Entry calculation page.


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: kneecaps on July 27, 2016, 08:02:52 AM
RTCC Lambert options  and Pad Request?

Is there a newer manual for RTCC ? I can only find one from Aug 2015. Lots of new/different options in Lambert and the Pad by the looks of things.

I'm especially interested in the Request option on the PAD and also how the Multi-Axis / X only option is working (looks to replace the old manual Z offset method?)



Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: indy91 on July 27, 2016, 08:12:13 AM
The most recent version of the manual is part of NASSP, under \Doc\Project Apollo - NASSP\Programmers Notes. It's not exactly a great manual, if you still have questions after reading it, then feel free to ask them here.


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: kneecaps on July 27, 2016, 10:55:15 PM
The most recent version of the manual is part of NASSP, under \Doc\Project Apollo - NASSP\Programmers Notes. It's not exactly a great manual, if you still have questions after reading it, then feel free to ask them here.

Thank you. The one place I didn't look :D


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: rcflyinghokie on August 20, 2016, 08:16:35 AM
I do not know if this is a bug since it can be manually changed, but the SOI in the RTCC does not switch back to earth after switching to the moon.  I know it switches automatically to moon SOI but it never automatically switches back to the earth.  Any insight into this?


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: indy91 on August 20, 2016, 08:47:19 AM
I do not know if this is a bug since it can be manually changed, but the SOI in the RTCC does not switch back to earth after switching to the moon.  I know it switches automatically to moon SOI but it never automatically switches back to the earth.  Any insight into this?

It doesn't automatically switch the SOI at all during an Orbiter session. When a scenario is loaded it will find the current SOI, but if you let a scenario run forever, then you need to switch it manually for some calculations. Ideally it would automatically detect the gravity reference all by itself, but that hasn't been implemented yet for all calculations. Especially map update/landmark tracking is still relying on the manual setting.


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: rcflyinghokie on August 20, 2016, 06:39:22 PM
It doesn't automatically switch the SOI at all during an Orbiter session. When a scenario is loaded it will find the current SOI, but if you let a scenario run forever, then you need to switch it manually for some calculations. Ideally it would automatically detect the gravity reference all by itself, but that hasn't been implemented yet for all calculations. Especially map update/landmark tracking is still relying on the manual setting.

Perfect thank you for the explanation.  I have been letting it run so that explains it :)


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: indy91 on September 15, 2016, 08:10:35 AM
A big LM update for the RTCC MFD. Already working  before for the LM was:

-REFSMMAT calculations and uplinks.
-State vector calculation and uplinks.

I had this update basically ready already, just a few more tests required. So here the changes for the LM:

-LM Maneuver PAD has been added. This will be displayed where the CSM Maneuver PAD would be, if LM is selected as the vehicle in the configuration menu. The MFD should be able to detect CSM vs. LM on scenario start, but checking doesn't hurt.
-REFSMMAT can be downlinked from the LM to the MFD so that the internal calculations of the MFD can be done with the actual present REFSMMAT in mind.
-P30 maneuver updates can now be uplinked to the LM
-Lambert targeted maneuvers can be calculated for the LM.
-An elaborate throttling scheme for the LM DPS is used, modelled after how P40 maneuvers were done during all the missions. This is necessary to take finite burntimes for the DPS into account. The calculations for the SPS are all based on 100% throttle throughout the burn. In the LM, if you just let the LGC do the burn then it will stay at 10% thrust for 26 seconds at then 100% for the remainder of the burn. So the RTCC MFD uses the throttle steps 10%, 40% and 100% as often used for the LM during the missions, especially Apollo 13. These throttle steps are taken into account for finite burntime calculations and are also displayed on the Maneuver PAD. This scheme can of course be changed in the future if it turns out that it isn't realistic.

Next up: Give the DOI burn a display on the MFD for the LM.


Title: Re: Apollo RTCC MFD (Formerly Apollo Rendezvous)
Post by: eddievhfan1984 on September 15, 2016, 08:34:42 AM
Would it be possible to also compute PADs for the DOI abort scenarios? That's a thing I've had an issue with, where I wasn't quite sure what values to use for abort rendezvous planning (especially the early aborts, where there's already an interception built in to the abort orbit that just requires fine tuning...).


Title: Re: Apollo RTCC MFD
Post by: indy91 on September 15, 2016, 09:57:33 AM
I absolutely plan to calculate the complete DOI, PDI etc. Data Cards. And there is already a function to calculate orbital midnight, so these abort maneuvers willl be calculated complete flexible for the correct lighting conditions.


Title: Re: Apollo RTCC MFD
Post by: jalexb88 on September 15, 2016, 10:07:24 AM
I guess while were discussing it, and don't mean to put too much on your plate there Indy  :D but here's a few other things I'm sure you've also thought of:

1. CSM plane change maneuver before lunar ascent

2. How are we going to go about ensuring proper landing site plane alignment for the planned time of landing? Is it going to be done on the last translunar MCC or will it be integrated into LOI-1? IE. calculate the required INC to be aligned with Tranquility base at X MET.


Title: Re: Apollo RTCC MFD
Post by: indy91 on September 15, 2016, 10:17:30 AM
1. CSM plane change maneuver before lunar ascent

One of the older CMC GSOPs has the equations for this. So they had planned to have a program onboard for this. I can easily implement that.

Quote
2. How are we going to go about ensuring proper landing site plane alignment for the planned time of landing. Is it going to be done on the last translunar MCC or will it be integrated into LOI-1, IE. calculate the required INC to be aligned with Tranquility base at X MET.

Right now we simply use inclination for the LOI-1. That got me <1NM crossrange at PDI. I have already implemented some preliminary functions for a more elaborate calculation to ensure the landing site is in-plane. The constraint for this was actually azimuth, not inclination and it was allowed to be varied within 2. The problem with taking out crossrange and also taking the desired azimuth into account is that during LOI-1 the ignition time must be varied. This can be very expensive in terms of fuel. In the actual RTCC they did a complete mission optimization and at least one MCC and LOI-1 have to be calculated together so that no fuel is wasted. These more elaborate calculations won't be ready soon. I'd say for now using the historical inclination is good enough.

EDIT: I have commited the DOI targeting. It is implemented as the 5th(!) option on the Lunar Insertion page. You have to give it the earliest GET for DOI, landing site latitude, landing site longitude, landing site altitude (always 0 in Orbiter 2010) and it will calculate the maneuver. Go to the LM Maneuver PAD, calculate and you have all the information you need for DOI. I guess the PDI PAD would be the next thing to implement...


Title: Re: Apollo RTCC MFD
Post by: jalexb88 on September 15, 2016, 01:48:19 PM
Alright I'm trying the DOI function off the undocking scenario you posted. Correct ignition time, Long, Lat, Alt.  However the resulting burn is a prograde one?  :? HA: 115 NM HP: 60 NM  Its the correct velocity, but prograde.


Title: Re: Apollo RTCC MFD
Post by: indy91 on September 15, 2016, 01:57:47 PM
Oops, that's what I get for not testing properly. I think it's just a reversed sign. Will be fixed shortly.


Title: Re: Apollo RTCC MFD
Post by: jalexb88 on September 15, 2016, 05:23:46 PM
Fixed it! But I read P30 uplinks should be working, however nothing happens when I try... Data switch and P00 are set.

EDIT: I was using the scenario "Apollo 11 - Post Undocking" from the LM status thread and for some weird reason I couldn't do the uplinks. Now I've tried the "Apollo 11 - LM P63 Test (Tranquility Base texture)" and it works.

Another problem is that on some pages in the LEM like the orbit adjust page, I get a CTD when I push calculate. I do the exact same maneuver calculation from the CSM and it works.


Title: Re: Apollo RTCC MFD
Post by: indy91 on September 16, 2016, 03:50:26 AM
Fixed it! But I read P30 uplinks should be working, however nothing happens when I try... Data switch and P00 are set.

EDIT: I was using the scenario "Apollo 11 - Post Undocking" from the LM status thread and for some weird reason I couldn't do the uplinks. Now I've tried the "Apollo 11 - LM P63 Test (Tranquility Base texture)" and it works.

I think this has to do with the PCM bitrate switch, which has to be in the low position.

Quote
Another problem is that on some pages in the LEM like the orbit adjust page, I get a CTD when I push calculate. I do the exact same maneuver calculation from the CSM and it works.

Haven't added the LM capability to those functions. The only problem really is the finite maneuver time compensation. It is looking for the thrust and isp of the main engine, but in Orbiter terms the LM doesn't have a main engine. It has a hover engine. So that's where these calculations are causing the CTD. Shouldn't be too much effort to make the CDH, orbit adjustment etc. work with the LM. Even TEI with the LM should be possible, although docked burns with full DPS propellant doesn't work too good yet.


Title: Re: Apollo RTCC MFD
Post by: indy91 on November 21, 2016, 04:20:44 PM
I have added the body relative angles to the RTCC MFD, which was talked about here: http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=2863.msg24624#msg24624

It enables you to calculate the RPY angles for pointing any axis of the CSM towards any body in the solar system. If you are confused by the axis, for an astronaut looking out of the rendezvous window up is "-Z", forward is "+X" and right is "+Y". There are no additional constraints yet, so it is very possible that the MFD will calculate an attitude in gimbal lock. I can implement some LGC routines that could prevent this, but that will follow later.

This new feature is useful for at least the Apollo 7 SPS Propellant Thermal Control Test. The actual RTCC was also able to calculate the angles to point a specific point on the CSM towards the sun, so the MFD now fulfills this RTCC (or rather RTACF) requirement.


Title: Re: Apollo RTCC MFD
Post by: indy91 on February 11, 2017, 07:34:54 AM
I've spent the last week implementing some of the Skylark guidance equations into the RTCC MFD. All the rendezvous maneuvers can now be calculated in the MFD and I have successfully performed a rendezvous with this profile used during Skylab and ASTP. There are still a few issues, but I'll get to that later. This is for Orbiter 2016 only, I won't make any changes like this to NASSP 7.0 anymore. Also, this is a big update so expect bugs.

The Skylab rendezvous profile is an extension of the concentric profile for Lunar Orbit Rendezvous used by Apollo 11 and 12. Here a picture:

(http://i.imgur.com/sb4zIN2.png)

NC1 is a phasing adjustment maneuver and NC2 is a height adjustment maneuver. In combination the DVs of these two maneuvers control the time of TPI, which usually is supposed to happen at around orbital midnight.

The NCC maneuver is Lambert-targeted, so it is setting up the NSR maneuver at the exact right location. The NSR maneuver then eliminates all the remaining out-of-plane velocity and sets up the coelliptic phase of the rendezvous. The NSR maneuver, sometimes called CDH is a maneuver we are already familiar with, because it is part of the normal Apollo rendezvous sequence.

The TPI maneuver is calculated at a specific elevation angle to the target vehicle. And then there are two midcourse corrections. That's all standard Apollo stuff.

All these maneuvers could be calculated onboard with the Skylab and ASTP AGCs, but there are some procedural differences to the ground targeting, which I have already partially implemented in the MFD. The "Skylab Rendezvous" page in the RTCC MFD can be found on the second main menu page. There are 8 sub pages: TPI Search, NC1, NC2, NCC, NSR, TPI, TPM and NPC. NPC is plane change targeting, which could be necessary if insertion didn't happen all that precisely.

I'll attach a scenario to test the Skylab rendezvous. The scenario will start before the NC1 maneuver and I have flown the maneuvers in such a way that I replicated the insertion maneuver with a GET difference of 6 hours. I have created the scenario from an Apollo 7 scenario and the target is the Apollo 7 S-IVB. If you want to use the onboard targeting, the AGC version we use for Apollo 7 can only be used for the TPI and TPM maneuvers.

The first step is to find the correct time for TPI. On the "TPI Search" page you can give the MFD an initial guess and it will calculate the time of orbital midnight. I might add an input for an offset time at some point. So press TGT until the target "AS-205-S4BSTG" is selected. The reference profile I have used, the Skylab 4 mission, had a TPI time of about 006:45:00 GET, so with the 6 hours difference, use 12:45:00 as the input. I usually get about 13:16:00 GET as a result.

On the NC1 page there are several inputs to make. The Skylab 4 NC1 maneuver happened at 2:20:54, so use this an an GET input (EDIT: plus 6 hours of course). Alternatively, you can time "ApT" and it will calculate the next apoapsis as the NC1 time. But that might be one revolution to early, depending on when you let it calculate the next apoapsis.

The normal profile has 1.5 orbits between the NC1 and NC2 maneuvers, so use this as the N input.

Now a number I actually don't really have a source for. The DH at NCC "DH1" is an input only used during the NC1 targeting, so it's a simplification to make the calculations less complicated. I have used 20NM here, but just because it looks like the correct altitude difference from a few documents I found. The Skylab Rendezvous Book doesn't have this information for some reason. Right now I think it was pad loaded and, while it is a crew input during the NC1 program, the astronaut could simply PRO through the program with these numbers already loaded.

The second DH "DH2" is the coelliptic DH, so use 10NM here. The elevation angle at TPI is 27.0, which is the "EL" input.

Now the NC1 calculation can be made by pressing CLC. Uplink and Maneuver PAD calculation work as usual. There are also a bunch of preliminary numbers for the later maneuvers displayed on the right side of the "Skylab Rendezvous" page.

The NC2 calculation is essentially identical, just with the DH1 input missing, as explained above. The preliminary time calculated during the NC1 calculations is used as the NC2 TIG. This can be changed manually or again with the input "ApT", but I usually just use the TIG calculated before during the NC1 targeting.

The NCC targeting uses the same inputs as the NC2 maneuver.

The NSR is fixed at 37 minutes after NCC. The inputs are again the same.

The TPI targeting works like on the Lambert page in the MFD. The elevation angle input is used to calculate a new TPI TIG, which should be really close to the previously predicted time. Other than the Apollo 7 rendezvous the SPS is used for the TPI maneuver for this profile, to conserve RCS fuel.

TPM (Midcourse) targeting uses the TPI time and an offset time from TPI as inputs. I don't think there were any ground solutions for midcourse corrections during the Skylab/ASTP missions though.

The last page of the Skylab Rendezvous page is for a plane change. A plane change is done when the yaw angle of the Lambert-targeted NCC maneuver becomes unacceptable large, which is greater than 60 out-of-plane. This is likely to happen in my example scenario. The plane change targeting is also based on a Skylark program, but it can only be used in combination with a ground targeted NC1 (if really necessary the NC2) maneuver. If this becomes necessary, then the NC1 ground solution has an out-of-plane component setting up a node with the target orbit 90 and 270 later. The onboard targeting calculates the TIG as 90 later, the ground solution would be a plane change maneuver 270 later and this is what I have implemented in the RTCC MFD. So when you calculate the NC1 maneuver press the "NPC" button and the page will now say "NC1 with Plane Change". If you perform the NC1 in this way then a following NPC maneuver will null the relative out-of-plane velocity. On the NPC page pressing "PCM" cycles between using the NC1 or NC2 TIG as a reference. This should say NC1 if you have set up the plane change with the NC1 maneuver. The ground targeted NPC maneuver, which I have implemented in the RTCC MFD, adds a radially downwards velocity component to the maneuver so that a REFSMMAT change does not become necessary. The velocity component is chosen so that the yaw angle is about 70. So the Gimbal Lock light will go on, but if you are careful you won't actually get into the red zone.

Now to the issue which I don't fully understand yet. The NPC maneuver between NC1 and NC2 perfectly nulls the relative inclination. But because of the big orbit difference (CSM is still in a much lower orbit than the OWS, or in this case the S-IVB) the relative inclination will increase again due to nonspherical gravity. And my scenario must be a worst case scenario, because the relative inclination increases to such a degree that the NCC maneuver gets an unacceptable out-of-plane component again. How did they deal with this during the actual Skylab rendezvous? They certainly planned the insertion parameters so that the relative inclination would be 0 after the NC maneuvers. But it really seems like the onboard NPC targeting can become useless in some worst case scenarios. Maybe I have to adjust the RTCC MFD NPC targeting for that. The biggest influence on the NCC out-of-plane component is the altitudes at which NC1 and NC2 are performed. If you perform the NC1 maneuver 10 minutes before apoapsis then the NCC out-of-plane component is zero. By moving the TIG a few minutes plus or minus this out-of-plane component changes from 15 ft/s in one direction to 15 ft/s to the other direction. I don't quite know yet how to deal with this and I don't know how they handled this back in the day. A Skylab Operational Trajectory would probably help. Maybe we'll find one at some point.

I've looked through the transcripts a bit and I do know that the actually flown Skylab 4 profile was very different from the planned one. I only know the planned one for one day earlier than the flown mission, but the normal DVs for NC1, NC2 and NCC are 225 ft/s, 165 ft/s and 25 ft/s. Those are the hardcoded initial guesses for the maneuvers in Skylark. The planned and flown mission for one day later was 38 ft/s, 153 ft/s and 209 ft/s. So that is veeery different than the profile as in the image above. So I guess I still have a lot to learn about this rendezvous profile.


Title: Re: Apollo RTCC MFD
Post by: indy91 on April 08, 2017, 09:56:33 AM
A few changes in the MFD:

-Added a free return option for Translunar Midcourse Corrections. This is the options 6 and 7 of the Translunar Midcourse Correction Processor of the actual RTCC, for a free-return flyby to specified/nominal pericynthion coordinates. The targets are the Earth-Moon-Plane (EMP) pericynthion latitude and the pericynthion altitude. There aren't many good sources for the EMP latitude parameter, but it can be reverse engineered from Operational Trajectory documents. For Apollo 8 it was -5.67822. The next step would be developing something for the option 2 of the TLMCC Processor, which is the option that was actually used during Apollo 8 for MCC-1 and MCC-2. This option optimizes the full mission DV, especially LOI, in addition to ensuring free return. I think I have some good ideas how to accomplish that.
-Reorganized the MFD. All previous calculation pages are now categorized in: Maneuver Targeting, Pre-Advisory Data and Utility. Also, the MCC and LOI targeting are on seperate pages now. TLI and MCC on one page, LOI-1 and LOI-2 on another.


Title: Re: Apollo RTCC MFD
Post by: rcflyinghokie on April 08, 2017, 11:13:25 AM
A few changes in the MFD:

-Added a free return option for Translunar Midcourse Corrections. This is the options 6 and 7 of the Translunar Midcourse Correction Processor of the actual RTCC, for a free-return flyby to specified/nominal pericynthion coordinates. The targets are the Earth-Moon-Plane (EMP) pericynthion latitude and the pericynthion altitude. There aren't many good sources for the EMP latitude parameter, but it can be reverse engineered from Operational Trajectory documents. For Apollo 8 it was -5.67822. The next step would be developing something for the option 2 of the TLMCC Processor, which is the option that was actually used during Apollo 8 for MCC-1 and MCC-2. This option optimizes the full mission DV, especially LOI, in addition to ensuring free return. I think I have some good ideas how to accomplish that.
-Reorganized the MFD. All previous calculation pages are now categorized in: Maneuver Targeting, Pre-Advisory Data and Utility. Also, the MCC and LOI targeting are on seperate pages now. TLI and MCC on one page, LOI-1 and LOI-2 on another.

This is awesome, and may I say I am continually impressed with the RTCC MFD's power.

I am wondering, however, if we can create pages on it that could help with a Docked DPS burn.  It appears Apollo 9 didnt uplink a target load and both the CSM and LM input a P30 from the Maneuver PAD.  I have run the same orbit adjustment numbers in both and I am using the P30 retro for the CSM and P30 heads up for the LM, however when I place the CSM at R300 P180 Y0 the LM is not at the P40 burn attitude suggested by the Maneuver PAD on the RTCC MFD or the angles requested by the LGC.  Would there be a way to simplify this procedure using the RTCC?


Title: Re: Apollo RTCC MFD
Post by: indy91 on April 08, 2017, 11:52:14 AM
This is awesome, and may I say I am continually impressed with the RTCC MFD's power.

I am wondering, however, if we can create pages on it that could help with a Docked DPS burn.  It appears Apollo 9 didnt uplink a target load and both the CSM and LM input a P30 from the Maneuver PAD.  I have run the same orbit adjustment numbers in both and I am using the P30 retro for the CSM and P30 heads up for the LM, however when I place the CSM at R300 P180 Y0 the LM is not at the P40 burn attitude suggested by the Maneuver PAD on the RTCC MFD or the angles requested by the LGC.  Would there be a way to simplify this procedure using the RTCC?

I'll have to look some more into the specific procedures they used here. But if both CMC and LGC have the same REFSMMAT and a good alignment then the IMU angles R300 P180 and Y0 in the CSM should always lead to the angles 0,0,0 in the LM. So if 0,0,0 was actually used in the LM for this burn, then the RTCC MFD can currently already calculate the correct REFSMMAT for the LGC, but not the CMC. So there should be an option for the CMC like "Docked P30" or so, which calculates the REFSMMAT so that the LM gets the 0,0,0 angles and not the CSM.


Title: Re: Apollo RTCC MFD
Post by: rcflyinghokie on April 08, 2017, 06:06:40 PM
Do you mean the "P30 Retro" option? 


Title: Re: Apollo RTCC MFD
Post by: indy91 on April 09, 2017, 12:29:29 AM
Actually, I got confused there with the different orientations. All you need to do is use the normal REFSMMAT P30 option, heads down, in both CSM and LM. Then move to R300, P180, Y0 with the CSM and the LM will have the angles 0,0,0. A while ago I added the heads up/down options for the P30 (Preferred) REFSMMAT. I guess it got a little bit confusing, but previously the default option was heads down, because that is what the AGC can also calculate with P52 option 1.


Title: Re: Apollo RTCC MFD
Post by: rcflyinghokie on April 09, 2017, 08:52:22 AM
Actually, I got confused there with the different orientations. All you need to do is use the normal REFSMMAT P30 option, heads down, in both CSM and LM. Then move to R300, P180, Y0 with the CSM and the LM will have the angles 0,0,0. A while ago I added the heads up/down options for the P30 (Preferred) REFSMMAT. I guess it got a little bit confusing, but previously the default option was heads down, because that is what the AGC can also calculate with P52 option 1.

So while in the CSM, do I need to choose "LM/CSM" as my vehicle to make sure the angles are correct?

EDIT: Guess it won't uplink to the CSM like that, so let me rephrase the question.  I run the Orbit Adjustment for the burn in the CSM, choose the P30 Heads Down REFSMMAT option in the CSM, and uplink that and run a P52?  Then align the LM to the CSM platform?


Title: Re: Apollo RTCC MFD
Post by: indy91 on April 09, 2017, 09:02:06 AM
So while in the CSM, do I need to choose "LM/CSM" as my vehicle to make sure the angles are correct?

The vehicle configuration won't have any influence on the REFSMMAT calculation.

Quote
EDIT: Guess it won't uplink to the CSM like that, so let me rephrase the question. 

Yeah, "LM/CSM docked" is the MFD configuration for the LM, with the CSM docked. "CSM/LM docked" is how it should be for the CSM. And then of course "LM/CSM docked" in the LM. But both of these configurations should be automatically detected and you don't usually have to change it, unless you have undocked since you started the MFD.

Quote
I run the Orbit Adjustment for the burn in the CSM, choose the P30 Heads Down REFSMMAT option in the CSM, and uplink that and run a P52?  Then align the LM to the CSM platform?

Yep. Also, don't forget to do the same steps in the LM. The LGC gets the same REFSMMAT. But in the LM you shouldn't do a P52 at that time but perform the docked alignment procedure. Then the LGC has the correct REFSMMAT and alignment. The CSM, too, of course.


Title: Re: Apollo RTCC MFD
Post by: rcflyinghokie on April 09, 2017, 09:24:31 AM
Wonderful makes total sense now, the orientation thing was throwing me off as well but I see everything coming together now.  I am going to try a docked DPS burn, I have heard horror stories about it's stability though so we shall see what happens :|

EDIT:  I am still getting differences in the LM P40 desired angles and from the RTCC MFD both being something other than 0,0,0

I have added a scn file if you don't mind taking a look.  It is very close to burn time for that I apologize.

EDIT 2:  Sorry for being back and forth, but I think I forgot to uplink the new REFSMMAT to the LM, let me try that... :beathead:

And that did the trick, and as expected oscillation began about 2 minutes into the Docked DPS burn.  For now I am going to try it with SM RCS assistance I think.


Title: Re: Apollo RTCC MFD
Post by: indy91 on April 11, 2017, 04:27:35 AM
I have commited the optimized Translunar MCC targeting. This targeting tries to emulate option 2 of the TLMCC Processor of the actual RTCC. Option 2 is: Free-return, fixed LPO orientation, landing site. This TLMCC option uses the Best Adaptive Path (BAP) reoptimization, which essentially tries to minimize fuel consumption (or rather, maximizes the mass) for a complete mission.

In the RTCC MFD this is still much simpler and doesn't use a proper optimization tool yet. At some point I'll try to find and implement a good open source library for this. But it does optimize the MCC and LOI-1 as a pair, ensures free return and the correct lunar parking orbit orientation. For that, you need to check the Lunar Insertion page before you try the calculation. There all the parameters for LOI-1 should be set. For Apollo 8, 10 and 11 that is automatically the case already, because the mission specific parameters are loaded when you open the MFD. If all the LOI-1 parameters are correct go to the Translunar page, choose option 2, check all the input parameters there and calculate the MCC. Only Apollo 8 and 10 have all the parameters preloaded for this, but I'm looking into adding more missions. The MCC calculation can take a few seconds, especially for MCC-1. I'll try to improve that. Once the calculation is done, the targeting has also calculated a nodal target. This will appear on the page for option 1. Option 1 with this nodal target should be used for MCC-3 and MCC-4. Targeting these coordinates (GET, latitude, longitude, altitude) will ensure that the trajectory intersects the lunar parking orbit at the desired point. Previously only the nodal targeting was implemented in RTCC MFD and we used the nominal pericynthion state as the target parameters.

I have also already added the FR BAP targeting to the MCC-H functionality. It's tested until before LOI-1 and I got pretty good results for the TL MCCs and the LOI-1 solution.


Title: Re: Apollo RTCC MFD
Post by: indy91 on May 15, 2017, 08:32:25 AM
Added a lunar liftoff time prediction page to the RTCC MFD. Inputs are an estimated time for the TPI maneuver and the target vessel. The page will then calculate and display all the relevant times of the rendezvous sequence from launch to Terminal Phase Final (TPF) and the necessary inputs for P12, which are the insertion velocity components. The calculation is only for the concentric rendezvous profile, I'll add the direct rendezvous (used on Apollo 14-17) next.


Title: Re: Apollo RTCC MFD
Post by: rcflyinghokie on May 20, 2017, 09:42:54 AM
I figure I would put this in here instead of LM Status, but the RTCC CDH page is still having issues for me.  It will sometimes do the calculations with zero issues, but today for example, it will not calculate a thing.  I have tried switching targets the time DH etc, it just stays on the same numbers as the first calculation I tried.  It's acting like its "frozen" even though I can switch other pages within it.  If I exit and come back in, I have no issues, but this "freezing" tends to happen a lot with that page.

EDIT:  I dont know if this is why, but there is a very weird GET on my orbit adjustment page when I load this quicksave (a very LARGE GET), I have been changing that to a more reasonable number and then going to the CDH page and it seems to work.

EDIT 2: I do not think the above issue is related afterall, I am thinking I am inputting values with no solution (like changing the GETI without changing the mode from "fixed" to "find GETI" and it locks up the program.


Title: Re: Apollo RTCC MFD
Post by: indy91 on May 20, 2017, 11:57:45 AM
Could the iteration for a solution have failed? The CDH calculation itself is done in a separate thread, so that Orbiter doesn't freeze, if the calculation takes longer. So you wouldn't really notice that the calculation is stuck. You can still change input parameters like e.g. GETI, but the MFD is still in "calculation mode" and it wouldn't allow you to start a new one. Does that sound like the behavior?

The CDH page was mostly created for the Apollo 7 maneuver and I haven't really touched it in a while, so there totally could be bugs. Maybe your maximum DH is 9.9NM and it tries to find 10NM and iterates forever. I'll take a look at it.


Title: Re: Apollo RTCC MFD
Post by: rcflyinghokie on May 20, 2017, 12:23:52 PM
Could the iteration for a solution have failed? The CDH calculation itself is done in a separate thread, so that Orbiter doesn't freeze, if the calculation takes longer. So you wouldn't really notice that the calculation is stuck. You can still change input parameters like e.g. GETI, but the MFD is still in "calculation mode" and it wouldn't allow you to start a new one. Does that sound like the behavior?

That's exactly what it sounds like actually.


Title: Re: Apollo RTCC MFD
Post by: indy91 on May 20, 2017, 12:30:39 PM
Could the iteration for a solution have failed? The CDH calculation itself is done in a separate thread, so that Orbiter doesn't freeze, if the calculation takes longer. So you wouldn't really notice that the calculation is stuck. You can still change input parameters like e.g. GETI, but the MFD is still in "calculation mode" and it wouldn't allow you to start a new one. Does that sound like the behavior?

That's exactly what it sounds like actually.

Just tried your old insertion scenario, that had a maximum DH of 10.9NM. When I try to let it find the GETI for 11NM the iteration continues forever. I guess I'll change it so that the iterations ends after a few attempts and then will output the best DH it could find.


Title: Re: Apollo RTCC MFD
Post by: rcflyinghokie on May 20, 2017, 01:52:17 PM
Just tried your old insertion scenario, that had a maximum DH of 10.9NM. When I try to let it find the GETI for 11NM the iteration continues forever. I guess I'll change it so that the iterations ends after a few attempts and then will output the best DH it could find.

Would there be a way to place a "kill" button similar to the V96 on the AGC to just manually terminate calculations to start over?  Or perhaps if the CLC button is pressed, it would terminate calculation before starting a new set of iterations?


Title: Re: Apollo RTCC MFD
Post by: indy91 on May 20, 2017, 04:22:57 PM
Would there be a way to place a "kill" button similar to the V96 on the AGC to just manually terminate calculations to start over?  Or perhaps if the CLC button is pressed, it would terminate calculation before starting a new set of iterations?

That is already halfway implemented. I tried to implement exactly that, killing the thread by pressing CLC a second time. Just doesn't work yet. I don't understand this whole thread system very well, I just copied what dseagrav was using for the MCC. I'll try to work on that again some time.


Title: Re: Apollo RTCC MFD
Post by: rcflyinghokie on May 27, 2017, 11:49:47 AM
Should the LM Maneuver PAD page in the RTCC also have an APS engine selection along with DPS and the RCS +/- X?


Title: Re: Apollo RTCC MFD
Post by: indy91 on June 12, 2017, 10:35:34 AM
Should the LM Maneuver PAD page in the RTCC also have an APS engine selection along with DPS and the RCS +/- X?

I don't think there is anything calculated differently for an APS burn, except of course for burn time etc.

I added an "update liftoff time" option to the configuration menu of the MFD. The MFD will read the TEPHEM from the AGC use that as the basis for state vector uplinks etc. This will be a little bit more precise, the actual liftoff time could vary up to 0.5 seconds from the planned time. This option doesn't work yet with the LGC.


Title: Re: Apollo RTCC MFD
Post by: indy91 on July 07, 2017, 02:20:25 PM
Update:

-Added a PDI PAD for the LM. It's in the same place where the TLI PAD for the CSM would be. The PDI PAD calculation requires a good estimate for the landing time in the MFD and it also needs the current REFSMMAT to be a landing site REFSMMAT. You will get a failure message if the calculation doesn't work.
-LM Maneuver PAD has a heads up/down option.


Title: Re: Apollo RTCC MFD
Post by: lotisully86 on July 13, 2017, 02:23:37 PM
I'm getting flying Apollo 10 and am at loi, however I think the rtcc is giving me a bad ls refsmmat. After uplinking and doing p52 opt 1 Agc can't point the optics at the right stars and I get terrible Loi results, i.e. 436x-137. Will attach scn

edit: this scn is just before refsmmat uplink


Title: Re: Apollo RTCC MFD
Post by: indy91 on July 13, 2017, 03:05:15 PM
Which uplink option did you choose on the REFSMMAT page? "REFSMMAT" or "Desired REFSMMAT"?


Title: Re: Apollo RTCC MFD
Post by: lotisully86 on July 13, 2017, 03:13:17 PM
Desired ref...and the flight plan calls for refsmmat. Sorry that could be it I guess, I just figured it might be a typo based on my (very little) understanding of the difference, other than its usage in the lm activation.


Title: Re: Apollo RTCC MFD
Post by: indy91 on July 13, 2017, 03:20:31 PM
Desired ref...and the flight plan calls for refsmmat. Sorry that could be it I guess, I just figured it might be a typo based on my (very little) understanding of the difference, other than its usage in the lm activation.

The difference is mostly AGC internal terminology. For a normal REFSMMAT change like Launch to PTC, or PTC to Landing Site you would always use the "Desired REFSMMAT" option for the uplink. That option doesn't uplink directly to the address of the REFSMMAT, but to an intermediate storage address. You will want to keep the actual REFSMMAT healthy, or else the AGC can't find any star or Earth or Moon anymore. In the process of a P52 option 1 (after the marks on stars) the new REFSMMAT then gets copied from the intermediate location to the "normal" REFSMMAT address. That's how you normally get a new alignment.

During the LM Activation the LGC doesn't really have a valid REFSMMAT yet. So in that case you uplink directly to the REFSMMAT address.

Anyway, I wanted to get this question ouf of the way, because it would have been the most obvious mistake. Now I'll take a look at the scenario.  :D


Title: Re: Apollo RTCC MFD
Post by: abr35 on July 13, 2017, 03:47:25 PM
I'm getting flying Apollo 10 and am at loi, however I think the rtcc is giving me a bad ls refsmmat. After uplinking and doing p52 opt 1 Agc can't point the optics at the right stars and I get terrible Loi results, i.e. 436x-137. Will attach scn

edit: this scn is just before refsmmat uplink

I had the same issue at LOI on Apollo 12. Completely forgot about it, or would have included it in my error report. A newly calculated and uploaded REFSMMAT and P52 Opt 1 did the job for me, but that still doesn't explain the error the first time around. Out of curiosity, did you have the NO ATT light remain illuminated long (like ~1 min) after the FDAI slewed to the new orientation? That was always the clue to to me something was amiss.


Title: Re: Apollo RTCC MFD
Post by: indy91 on July 13, 2017, 04:13:01 PM
I'm getting flying Apollo 10 and am at loi, however I think the rtcc is giving me a bad ls refsmmat. After uplinking and doing p52 opt 1 Agc can't point the optics at the right stars and I get terrible Loi results, i.e. 436x-137. Will attach scn

edit: this scn is just before refsmmat uplink

I had the same issue at LOI on Apollo 12. Completely forgot about it, or would have included it in my error report. A newly calculated and uploaded REFSMMAT and P52 Opt 1 did the job for me, but that still doesn't explain the error the first time around. Out of curiosity, did you have the NO ATT light remain illuminated long (like ~1 min) after the FDAI slewed to the new orientation? That was always the clue to to me something was amiss.

Both cases sound like an actual bad REFSMMAT then. Even if the LS REFSMMAT was calculated in a wrong way somehow, it would still be a valid REFSMMAT and you would be able to find stars etc. But if the REFSMMAT is actually bad, then alignment problems etc. can happen.

lotisully86, in your scenario I have successfully calculated a LS REFSMMAT and did the alignment. No issues and the LOI ignition attitude from the Apollo 10 flight plan is almost identical with the one from the Maneuver PAD in the RTCC MFD.

Now, in your scenario you still need to perform MCC-4. And your pericynthion is fairly high (76NM), so MCC-4 is indeed necessary. The way to calculate the LS REFSMMAT before MCC-4 is a bit tricky and I haven't really named the REFSMMAT option for this properly. If you have to do two maneuvers between "now" and lunar orbit (MCC-4 and LOI-1), then you need to use the "LS during TLC" option on the REFSMMAT page. If MCC-4 would have been scrubbed or if you want to update the LS REFSMMAT after MCC-4, then the "Landing Site" page has to be used.

In your case you need to go to the Translunar page first and calculate MCC-4. All you need to change is the TIG it seems, everything else is already in the MFD. After that you go to the Lunar Insertion page and calculate LOI-1 with the option to take MCC-4 into account. That is the "LOI-1 w/ MCC" option. After that you go to the REFSMMAT page ("LS during TLC") and there the two burns (MCC-4 and LOI-1) should be displayed with TIG and DV vector. Only then you can calculate the REFSMMAT. It's pretty complicated, but really the only way to take two maneuvers into account.

That still doesn't really explain why you both got a bad REFSMMAT from the RTCC MFD though...


Title: Re: Apollo RTCC MFD
Post by: rcflyinghokie on July 13, 2017, 08:51:38 PM
Desired ref...and the flight plan calls for refsmmat. Sorry that could be it I guess, I just figured it might be a typo based on my (very little) understanding of the difference, other than its usage in the lm activation.

Just to be clear, the flight plan changes the REFSMMAT to the lunar landing site prior to MCC4 using the preferred P52 option 1.  After MCC4 (even if it is scrubbed) you should only have to align it to REFSMMAT before LOI.


Title: Re: Apollo RTCC MFD
Post by: lotisully86 on July 14, 2017, 02:24:47 AM
I'm getting flying Apollo 10 and am at loi, however I think the rtcc is giving me a bad ls refsmmat. After uplinking and doing p52 opt 1 Agc can't point the optics at the right stars and I get terrible Loi results, i.e. 436x-137. Will attach scn

edit: this scn is just before refsmmat uplink

I had the same issue at LOI on Apollo 12. Completely forgot about it, or would have included it in my error report. A newly calculated and uploaded REFSMMAT and P52 Opt 1 did the job for me, but that still doesn't explain the error the first time around. Out of curiosity, did you have the NO ATT light remain illuminated long (like ~1 min) after the FDAI slewed to the new orientation? That was always the clue to to me something was amiss.


No I haven't gotten that behavior or atleast noticed it. I did get a 1301 alarm in one case tho.

lotisully86, in your scenario I have successfully calculated a LS REFSMMAT and did the alignment. No issues and the LOI ignition attitude from the Apollo 10 flight plan is almost identical with the one from the Maneuver PAD in the RTCC MFD.

Now, in your scenario you still need to perform MCC-4. And your pericynthion is fairly high (76NM), so MCC-4 is indeed necessary. The way to calculate the LS REFSMMAT before MCC-4 is a bit tricky and I haven't really named the REFSMMAT option for this properly. If you have to do two maneuvers between "now" and lunar orbit (MCC-4 and LOI-1), then you need to use the "LS during TLC" option on the REFSMMAT page. If MCC-4 would have been scrubbed or if you want to update the LS REFSMMAT after MCC-4, then the "Landing Site" page has to be used.

In your case you need to go to the Translunar page first and calculate MCC-4. All you need to change is the TIG it seems, everything else is already in the MFD. After that you go to the Lunar Insertion page and calculate LOI-1 with the option to take MCC-4 into account. That is the "LOI-1 w/ MCC" option. After that you go to the REFSMMAT page ("LS during TLC") and there the two burns (MCC-4 and LOI-1) should be displayed with TIG and DV vector. Only then you can calculate the REFSMMAT. It's pretty complicated, but really the only way to take two maneuvers into account.

That still doesn't really explain why you both got a bad REFSMMAT from the RTCC MFD though...

Yes the "LS  during TLC" was the option I was originally using, the scn I posted was after making a few attempts then trying just the landing site option. Will give it another shot with following the your steps above. Thanks!

Edit: partial success, had to uplink the REFSMMAT/p52 opt 1 twice tho before I got a good alignment tho.

Does uplinking a REFSMMAT or desired REFSMMAT overwrite the REF flag set by a previous P30? For example, I'm fairly certain that after performing MCC-3, per the checklist there was no p52 opt 3. I know after conducting running P30 and conducting maneuvers, the first p52 subsequently run will have opt 1 preselected. Anyways option 1 is preselected when trying to align to the ls REFSMMAT, so just wondering if the agc is still trying to align to the previous P30 computed REFSMMAT


Title: Re: Apollo RTCC MFD
Post by: indy91 on July 14, 2017, 05:43:39 AM
No I haven't gotten that behavior or atleast noticed it. I did get a 1301 alarm in one case tho.

Yeah, with a bad REFSMMAT that is a common alarm.

Quote
Yes the "LS  during TLC" was the option I was originally using, the scn I posted was after making a few attempts then trying just the landing site option. Will give it another shot with following the your steps above. Thanks!

Edit: partial success, had to uplink the REFSMMAT/p52 opt 1 twice tho before I got a good alignment tho.

Does uplinking a REFSMMAT or desired REFSMMAT overwrite the REF flag set by a previous P30? For example, I'm fairly certain that after performing MCC-3, per the checklist there was no p52 opt 3. I know after conducting running P30 and conducting maneuvers, the first p52 subsequently run will have opt 1 preselected. Anyways option 1 is preselected when trying to align to the ls REFSMMAT, so just wondering if the agc is still trying to align to the previous P30 computed REFSMMAT

Good question. But the answer is probably no. There is only one place where the AGC stores the "Desired REFSMMAT". And an uplink overwrites that. Also, the REFSMMAT calculated internally in the AGC is calculated in P40 and not P30. That's why the procedure to get an alignment for a burn (0, 0, 0 at ignition) is P30, then shortly into P40 and then P52 option 1.

There is one more important part of the procedure I forgot to mention. It is important that the Desired REFSMMAT uplink is the last upink. Usually at the time of the uplink there would also be a state vector uplink and of course the External Delta V update to get the burn solution for MCC-4 into the AGC. Any of those uplinks will overwrite the Desired REFSMMAT at least partially. So there can't be any other uplink between the Desired REFSMMAT uplink and the P52 option 1. I learned this the hard way until I figured out what is going on.


Title: Re: Apollo RTCC MFD
Post by: lotisully86 on July 14, 2017, 06:47:29 AM
I wondered if there was a preferred order with the uplinks, I was just going by the order in the flightplans. Good to know


Title: Re: Apollo RTCC MFD
Post by: indy91 on July 14, 2017, 07:22:23 AM
I wondered if there was a preferred order with the uplinks, I was just going by the order in the flightplans. Good to know

Yeah, in that case uplinking the MCC-4 target load after the desired REFSMMAT might have caused your issues. It's always the desired REFSMMAT last in a string of uplink, the order of the other uplinks (state vector, P30 target load etc.) doesn't matter. I guess knowing this isn't so important for the astronauts, MCC-H takes care of it all. But in NASSP we are both astronaut and mission control.  :D

EDIT: I had trouble finding the document where I read about the REFSMMAT uplink issue, but now I found it again. So here, for future reference, the passage from the Colossus 3 and Luminary 1E Program Notes (https://www.ibiblio.org/apollo/Documents/msc05225.pdf):

Quote
1.1.27 Any P27 update will destroy the preferred orientation matrix (e.g. that calculated by P40, P41), except an update of the matrix itself. Therefore, if a preferred alignment is to be part of an update, it should be the last quanitity in the sequence.

The Desired REFSMMAT (a term from the GSOP section 2 and used in the AGC source code) is in this case called preferred orientation matrix. It's the same thing. And this uplink issue is the same for every Colossus and Luminary version.


Title: Re: Apollo RTCC MFD
Post by: lotisully86 on July 14, 2017, 08:45:05 AM
Thanks for posting that link!
 
Page 19 paragraph 2 provides an answer to why the preburn ha hp prediction in P30 before loi is +3xx/-1xx. I suppose in real world that was a rather reassuring bit of knowledge  :D


Title: Re: Apollo RTCC MFD
Post by: indy91 on July 14, 2017, 08:58:34 AM
Thanks for posting that link!
 
Page 19 paragraph 2 provides an answer to why the preburn ha hp prediction in P30 before loi is +3xx/-1xx. I suppose in real world that was a rather reassuring bit of knowledge  :D

Yes, P30 simply adds the DV vector to the ignition state vector. It doesn't take into account that the velocity change for LOI-1 isn't instantly. That's how you get those apoapsis and periapsis altitudes. I chose to use the actual orbital parameters after a burn for the Maneuver PAD, because that is what the crews mostly got with the PAD. During the actual Apollo 11 mission they got the P30 values as an additional comment for their LOI-1 Maneuver PAD. "Noun 42 prior to LOI burn are HA, plus 431.3; HP, minus 128.2" I guess it's both useful to know what P30 is going to say, but also in what orbit you will actually end up.


Title: Re: Apollo RTCC MFD
Post by: rcflyinghokie on July 21, 2017, 10:15:44 AM
I know it won't matter too much with the MCC helping the missions, but I noticed that the RTCC MFD when calculating LM mass while docked but in the SIVB calculates what appears to be the total mass of the stage.  I assume this is because the LM isn't "created" yet?  I found this by calculating the SPS evasive maneuver and the PAD page gives a LM weight of 78864 which I know is way off. 


Title: Re: Apollo RTCC MFD
Post by: lotisully86 on July 22, 2017, 06:11:24 PM
I know it won't matter too much with the MCC helping the missions, but I noticed that the RTCC MFD when calculating LM mass while docked but in the SIVB calculates what appears to be the total mass of the stage.  I assume this is because the LM isn't "created" yet?  I found this by calculating the SPS evasive maneuver and the PAD page gives a LM weight of 78864 which I know is way off. 

I also get this, usually just recalculate the pad after sep and reload the dap.

Somewhat related, do you get accurate sep angles on the rtcc tli pad? I usually get good roll and pitch angles but yaw is off by about 45 degrees


Title: Re: Apollo RTCC MFD
Post by: rcflyinghokie on July 22, 2017, 07:42:12 PM
Yeah I just reload after the sep as well.  As for the angles I believe Indy told me that they aren't the same in rtcc as the lvdc right now so they won't line up yet.


Title: Re: Apollo RTCC MFD
Post by: indy91 on July 24, 2017, 03:59:43 AM
I assume this is because the LM isn't "created" yet?

Correct. There is no way of getting the LM mass alone at that point. I could let the RTCC MFD detect the type of vessel it is docked to though. And then it would use a default LM mass if the docked vessel isn't a LM, but a S-IVB with the LM still inside it. I'll look into doing it this way.

Somewhat related, do you get accurate sep angles on the rtcc tli pad? I usually get good roll and pitch angles but yaw is off by about 45 degrees

Even roll and pitch can be a problem in a scenario with fully configured LVDC presettings (Apollo 8, 11 and 14 right now). The yaw issue can probably be fairly easily fixed. The MFD just needs to read the padloaded separation attitude from the LVDC. The general issue with the sep attitude on the TLI PAD is a bit more complicated. It has to do with an inconsistent coordinate transformation, that just by luck works correctly for Apollo 8, but not for Apollo 11. Fixing this might take a while.


Title: Re: Apollo RTCC MFD
Post by: indy91 on August 17, 2017, 10:49:23 AM
A few updates:

-Iterations can now be stopped by pressing CLC again. The RTCC MFD is fairly prone to getting stuck in calculations, due to user errors or off-nominal cases. Previously there was no way to stop these calculations except restarting Orbiter. Now pressing CLC again will kill the calculation thread. I think this is a very useful feature.
-Added a LOI-1 at pericynthion option (see explanation below).
-Added the missing options of the Translunar Midcourse Correction Processor. Here a complete list of options (based on the actual RTCC) that were available by the time Apollo 8 flew:

-Option 1: X, y, z and t target update.
-Option 2: Free-return, fixed LPO orientation, landing site.
-Option 3: Free-return, free LPO orientation, landing site. (NEW)
-Option 4: Nonfree-return, fixed LPO orientation, landing site (NEW)
-Option 5: Nonfree-return, free LPO orientation, landing site (NEW)
-Option 6: Circumlunar free-return flyby to nominal H_PC (pericynthion height) and phi_PC (pericynthion latitude)
-Option 7: Circumlunar free-return flyby, specified H_PC and nominal phi_PC

The free LPO orientation options probably were never used during an actual flight. They would have been used to save a lunar landing mission that had an off-nominal TLI, just off-nominal enough so that the desirable lunar parking orbit orientation cannot be used. These options save some DV during the LOI maneuver, but don't lead to the planned approach azimuth to the landing site. Missions that depended on a terrain model being loaded into the LGC (Apollo 14 to 17) probably couldn't have used these options. The optimum DV for these free LPO options is with LOI-1 happening exactly at pericynthion. So I added this calculation mode for the LOI-1 maneuver. The optmized trajectory usually has a LOI-1 DV vector with almost exclusively a DVX component. DVY and DVZ are close to 0.

The new non-free return modes use the input pericynthion GET as a fixed parameter. The free-return modes iterate on that time to achieve free return. Other than that the non-free modes are fairly similar. It's still not a full mission optimization like the real RTCC did. Only the TLMCC and LOI-1 as a pair are optimized.


Title: Re: Apollo RTCC MFD
Post by: indy91 on September 16, 2017, 05:28:37 AM
Forgot to write an update post for the last update. Mostly another option was added for the TLMCC Processor:

-Option 8: SPS Lunar Flyby to specified free return inclination and a desired longitude of Earth landing

I was also asked to write a tutorial for calculating Translunar Midcourse Correction maneuvers with the RTCC MFD. All the available options are based on historical documents about the RTCC, so the real RTCC back in the day had the same options. During a given lunar mission, only a few of the options would actually be used. The options used differ for free-return trajectories (Apollo 8, 10-11) and hybrid trajectories (Apollo 12-17).

Let's say you are flying Apollo 8/10/11 and have completed TLI and all the post-TLI procedures, i.e. LM extraction, evasion maneuvers etc. How the MCCs are getting calculated and executed is (indirectly) specified in the Mission Rules for each mission. Usually there were four planned course corrections on the way to the Moon, at different times spread out over the translunar coasting period. Different calculation options are used for each MCC, see the list of options in the post above. For the free-return missions you would use option 2 of the TLMCC Processor for MCC-1 and MCC-2 and option 1 for MCC-3 and MCC-4. Option 2 optimizes the MCC and LOI-1 maneuvers as a pair and also results in: free return with a lunar flyby at the specified altitude, insertion into a lunar orbit with a fixed approach azimuth to the landing site, and an overflight of the landing site at the desired time of landing.

Because all the necessary parameters for this calculation didn't fit on the "Translunar" page of the RTCC MFD, the parameters for the Lunar Orbit Insertion maneuver, which is part of the calculation, are on the "Lunar Orbit" page. Only the options that include the landing site in the calculation need the parameters on the "Lunar Orbit" page. So that would be options 2-5. For options 1, 6-8 all the necessary numbers are on the "Translunar" page, where you calculate the MCC. Here a list of the necessary input parameters for option 2:

-Time of Ignition (TIG)
-Initial guess for the GET at pericynthion (GET)
-Selenocentric latitude in Earth-Moon plane coordinates (LAT)
-Pericynthion altitude (ALT)

-Desired time of lunar landing (GET)
-Apocynthion altitude for LOI-1 (APA)
-Pericynthion altitude for LOI-1 (PEA)
-Approach azimuth (AZI)
-Landing site latitude (LAT)
-Landing site longitude (LNG)
-Landing site altitude (ALT)

That's a whole bunch of numbers and some of them are difficult to derive from the historical documents. But we have already done most of that work and for almost every Apollo mission these parameters are preloaded in the RTCC MFD. But it's always good to check if  the numbers are there and also correct.

The time of ignition is always user specified. The time is usually relative to TLI or LOI, but the GET from the flight plans for MCC-1 and MCC-2 will do. When all the input parameters are right, press CLC and wait a few seconds. The calculation can take a few moments. Pressing UPL the maneuver solution can then be uplinked to the AGC, if that is desired. This whole procedure should be done for MCC-1 and MCC-2.

The result of the option 2 calculation is not only a Delta V vector to be burned, but it also calculates a new nodal target. The nodal target is a set of coodinates (time, latitude, longitude, altitude) of the intersection between the incoming approach hyperbola before LOI and the resulting lunar parking orbit after LOI. This set of numbers will be stored in the RTCC MFD and can be used for an option 1 calculation. For various reasons MCC-3 and MCC-4 didn't reoptimize the whole mission, as is done with option 2, but they only targeted these previously calculated coordinates. And that's what option 1 is for "X, y, z and t target update". The nodal target was fixed after MCC-2, so the only user input for the option 1 calculation is the TIG. Here all the parameters for option 1:

-Time of Ignition (TIG)
-GET of node (GET)
-Seleographic latitude of node (LAT)
-Selenographic longitude of node (LNG)
-Selenographic altitude of node (ALT)

Calculate and uplink as before. I hope this description helps with using the RTCC MFD for Translunar MCCs. Feel free to ask any question in this thread. I am bad at writing manuals, so I don't really plan to update the RTCC MFD manual (under Doc\Project Apollo - NASSP\Programmers Notes) much until the NASSP 8.0 release.