Meadville Space Center
Welcome, Guest. Please login or register.
May 26, 2020, 08:50:08 AM

Login with username, password and session length
Search:     Advanced search
Project Apollo - NASSP 6.4.3 released!
http://nassp.sf.net
25068 Posts in 2094 Topics by 2266 Members
Latest Member: twa517
* Home Help Search Login Register
+  Meadville Space Center
|-+  Project Apollo - NASSP
| |-+  Project Apollo - NASSP Development
| | |-+  Programming (Moderators: movieman, dseagrav, Swatch, lassombra)
| | | |-+  Apollo RTCC MFD
« previous next »
Pages: 1 [2] 3 4 ... 16 Print
Author Topic: Apollo RTCC MFD  (Read 38237 times)
jalexb88
Sr. Member
****
Posts: 328


View Profile
« Reply #15 on: April 12, 2015, 04:55:55 PM »

Good stuff, the entry targeting is working good on my end  Thumbs Up 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
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #16 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.
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #17 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?
Logged
jalexb88
Sr. Member
****
Posts: 328


View Profile
« Reply #18 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
Logged
meik84
Project Team Member
Sr. Member
****
Posts: 454



View Profile
« Reply #19 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
Logged
jalexb88
Sr. Member
****
Posts: 328


View Profile
« Reply #20 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
« Last Edit: April 17, 2015, 01:26:43 AM by jalexb88 » Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #21 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).
Logged
jalexb88
Sr. Member
****
Posts: 328


View Profile
« Reply #22 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
« Last Edit: April 17, 2015, 02:56:53 PM by jalexb88 » Logged
pattersoncr
Project Team Member
Full Member
****
Posts: 212


View Profile Email
« Reply #23 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!
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #24 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.  ROTFL
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #25 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.  Thumbs Up

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.
« Last Edit: April 19, 2015, 12:35:41 PM by indy91 » Logged
jalexb88
Sr. Member
****
Posts: 328


View Profile
« Reply #26 on: April 19, 2015, 12:25:12 PM »

Awesome!  Thumbs Up 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


* SPSRCS.jpg (236.49 KB, 735x696 - viewed 223 times.)
« Last Edit: April 19, 2015, 01:20:36 PM by jalexb88 » Logged
eddievhfan1984
Hero Member
*****
Posts: 737



View Profile
« Reply #27 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.
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #28 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.
« Last Edit: April 20, 2015, 01:20:58 PM by indy91 » Logged
meik84
Project Team Member
Sr. Member
****
Posts: 454



View Profile
« Reply #29 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. Sad
Logged
Pages: 1 [2] 3 4 ... 16 Print 
« previous next »
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.10 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!