Meadville Space Center

Project Apollo - NASSP => Planning => Topic started by: Swatch on June 29, 2006, 01:16:43 PM



Title: Project Apollo MFD ideas & concepts
Post by: Swatch on June 29, 2006, 01:16:43 PM
Swatch's Proposal on the Project Apollo MFD (PAMFD)

I'd just like to thow these ideas out there and see how everyone feels about them.

1.  We should use this as an integral tool with our add-on.

2.  We should take advantage and use it as almost a swiss army knife of flexibility.
  a.  Burn Calculator (psuedo-Mission Control Think Tank) - Capable of controlling the IU and calculating the TLI burn.  Capable of calculating and displaying burn data for MCC/LOI/TEI/etc.  This data can be displayed for manual entry into the AGC (AGC++ or vAGC) or possibly using dseagrav's telemetry in the future, it can uplink straight to the AGC.
  b.  Live Checklist - Interactive repository of checklists and reference cards for in-flight usage.  When you click upon a checklist step, it initiates movieman's flashing switch locator.
  c.  Live Transcript - Have a scrolling historical mission transcript synced to the sim time.
  d.  Astronaut Control - A page capable of controlling where the astronauts are currently situated.  Send the LMP & CDR to the LEM to begin start-up proceadures, etc.  Make sure there is at least one person in LEM to make it available.  Send crew to sleep, etc. the beginnings of proper crew and environment simulation.

3.  We should set a format of the MFD and stick to it during development.  An example of this would be to researve the right 6 buttons on the MFD for global MFD mode controls (not page or program specific) and then use the right 6 buttons for page specific controls.


Title: Project Apollo MFD ideas & concepts
Post by: dseagrav on June 29, 2006, 03:13:01 PM
Re: Swatch

1) No - Please don't require the use of a MFD for anything. People should be able to fly at realism 10 without using any Orbiter-specific assistance. It can be a multi-tool type aid, but its use shouldn't be required, at least not later on.

2a) I don't know how NASA's procedure for this worked - They could "P00 AND ACCEPT" for burn data and so on, but I think they read the burn data up on voice and had the crew manually put in the data, so they had some idea what the computer was about to do and weren't "in the dark" if comms were lost or the computer failed and did the wrong thing.

2b) No problems here

2c) I had planned to do this via the TELECOM code with the debug line at the bottom of the screen. This has the advantage that you can scroll the screen elsewhere (look at something other than the MFD) and still "hear" what MCC is saying. If it's on the MFD you have to be looking at the MFD to use it - Back and forth, back and forth...

2d) Do you mean just the act of moving people around, or having a crew you can have do switch-flipping and the like for you? The latter may be too complex for us to consider right now.

3) No problems here


Title: Re: Project Apollo MFD ideas & concepts
Post by: Tschachim on June 29, 2006, 05:13:55 PM
Hi Swatch,

that are cool ideas, especially checklists are something I'm thinking about, too. I splitted this into a new topic, because I think these ideas deserve a topic of it's own and not get lost in the TLI topic.

Cheers
Tschachim


Title: Re: Project Apollo MFD ideas & concepts
Post by: BigDAS on June 29, 2006, 05:37:43 PM
Definately 2b, ala Virgin's Shuttle simulator. More times than not, I'm scrolling around the panels looking for a certain switch which is usually right under my nose. These are particuarly hard to see in high screen resolutions.


Title: Re: Project Apollo MFD ideas & concepts
Post by: Swatch on June 29, 2006, 09:09:28 PM
1) No - Please don't require the use of a MFD for anything. People should be able to fly at realism 10 without using any Orbiter-specific assistance. It can be a multi-tool type aid, but its use shouldn't be required, at least not later on.

2a) I don't know how NASA's procedure for this worked - They could "P00 AND ACCEPT" for burn data and so on, but I think they read the burn data up on voice and had the crew manually put in the data, so they had some idea what the computer was about to do and weren't "in the dark" if comms were lost or the computer failed and did the wrong thing.

What I meant was that we shouldn't make this an add-on that we'd expect to use with other programs, ala calling it a TLI Calculator as was suggested.  I agree we should reach the point where we can get by without ANY MFD, but we certainly aren't there and there's some question as to whether this is attainable, so I'm also considering that this is the only method we have right now of doing things outside of the historical panels, and we should take advantage of it.  It provides a "life-line" to a faux-mission control right now in the TLI area, so we should not shy away from making it a vital Project Apollo tool.  It does provide our only access to the IU right now.  Remember, there are some things that we'll have to make concessions on in realism.


Quote
2d) Do you mean just the act of moving people around, or having a crew you can have do switch-flipping and the like for you? The latter may be too complex for us to consider right now.

Yes, I was considering it more a simulation of the astronauts, not their switch-flipping abilities.  :D  I just htought it would make sence to be able to move people around the two crafts (also useful for EVA activities, since we can't use an EVA switch anymore)  While definately more of an "extra", there is something to be said for simulating the astronauts living cycles and movement within the crafts.  I'll post some conceptual drawings of what I'm thinking of about this stuff later on.


Title: Re: Project Apollo MFD ideas & concepts
Post by: BigDAS on June 29, 2006, 11:41:57 PM
It may not be feasable to eliminate all MFD ops. These missions also include Ground Control operation and flight calculations sent to the Apollo computers and Astronauts directly. Certain MFD's could be considered part of the GC mirrored on the vehicle panels.


Title: Re: Project Apollo MFD ideas & concepts
Post by: Swatch on July 05, 2006, 05:46:19 PM
My extremely rough suggestion for an Astronaut/Spacecraft Status/Simulation page in the MFD.

(http://swatch.homeip.net/MFDStatussuggestion.jpg)

I figured you could move them around from location to location using somehting along these lines, any suggestions would be greatly appreciated.


Title: Re: Project Apollo MFD ideas & concepts
Post by: Tschachim on July 05, 2006, 05:51:07 PM
Looks quite cool, I was always thinking about how to tell the ECS how many astronauts are in the vehicles, currently there are always 3 guys in the CSM...

Cheers
Tschachim


Title: Project Apollo MFD cont
Post by: BigDAS on July 29, 2006, 08:09:50 AM
I'd assume you would want to make the Apollo completely MFD independant for historical accuracy. The AGC should be made to handle everything.


Title: Re: CSM Power system question and Apollo 7 discussion
Post by: Swatch on July 29, 2006, 10:47:55 AM
I don't believe that that is historically possible...the Mission Control guys would feel bad if you said they weren't needed. :wink:

To me, the ProjectApolloMFD is something of a necessity, at least for now and the foreseeable future.  It takes the place of Mission Control and the large navigation computers on the ground, as well as providing an interactive location for the numerous documentation and other spacecraft interactions.

Remember, the astronauts, while not having an MFD, did have many more resources at their disposal.


Title: Re: CSM Power system question and Apollo 7 discussion
Post by: Christophe on July 29, 2006, 04:22:29 PM
Totally agree with you Swatch.
The AGC is not a magical versatile tool. It's a just a parent of the today FMS. But it is totally dependant from the ground controllers and ground computers for the build of maneuver.
A MFD for Apollo should have to do that ground job.


Title: Re: CSM Power system question and Apollo 7 discussion
Post by: BigDAS on July 29, 2006, 04:43:35 PM
I stand corrected. I forgot that we're taking both rolls, Air and Ground control, however, the Apollo MFD should be only one you would rely on, and not other more exotic, unrealsitic gadgets.



Title: Re: CSM Power system question and Apollo 7 discussion
Post by: movieman on July 29, 2006, 05:23:14 PM
Quote
I don't believe that that is historically possible...the Mission Control guys would feel bad if you said they weren't needed.

I noticed there's some information on what data was sent to the ground through the telemetry system in the Saturn V and Saturn 1b Flight Manuals, so in NASSP 12.0 we can probably have a full mission control room too.


Title: Re: CSM Power system question and Apollo 7 discussion
Post by: Christophe on July 29, 2006, 06:21:27 PM
The problem is not to have a full mission control with some virtual guys wearing white shirts and black ties; the problem is: how can I do to fly with Apollo and the vAGC.
Right now the answer is: NO WAY.
The CSM is just a beautiful static model because there's no environment for it. A spacecraft is not like a plane: you line up on the runway and take off.
Apollo is a whole project with a spaceship , some ground network, computers, dozen of astronauts and engineers working hard while the mission is flying...
Of course the purpose of NASSP is not to simulate the deep space network antenna of woomera but we must accept that just release a spacecraft is like to build a static model.
You like it or not, but the environment of NASSP is Orbiter and we need to use it to fly. And in orbiter, the only way to avoid the simulation of the whole Manned Spacecraft Center is called: an MFD.


Title: Re: CSM Power system question and Apollo 7 discussion
Post by: BigDAS on July 29, 2006, 07:29:44 PM
Which MFD (s) would be appropriate without sacrificing realism, besides Apollo MFD? Which ones would best emulate gMissin Contol computer? If they don't exist yet, can we make them?




Title: Re: Project Apollo MFD ideas & concepts
Post by: Swatch on July 21, 2007, 07:57:48 PM
Well, here we are, one year later, and I figured I'd resurrect this a bit....not because I'm a necroposter :evil: or because I feel bad for the thread :cry: but instead because with the increased work in dseagrav's Mission Control capabilities, its time we revisit two parts of this.   The Mission Control interface and the Crew Simulation.

I was not aware of this until recently, but DanSteph has a new tool called Universal MMU, and I figured I'd present this as a possible option for the latter of the two subjects.

For the former (mission control interface), I would like to ask if this is where we should implement the simulated CapCom (like M$ FlightSim's ATC) or rather this should be done elsewhere.


Title: Re: Project Apollo MFD ideas & concepts
Post by: Tschachim on July 22, 2007, 06:32:19 PM
Well, lets see what dseagrav and lassombra think, for my part I'd like to see a "internal MCC interface" rather in the ProjectApolloMFD than as a DebugPrint line, mainly because it looks nicer. An additional voice interface would also be cool, of course.

The crew is simulated in the CSM itself; the crew status can be monitored and the crew count can be changed in the ProjectApolloMFD. For me this is fine for a Apollo 7 release, for proper EVA and LM support this needs to be extended, of course.

Cheers
Tschachim


Title: Re: Project Apollo MFD ideas & concepts
Post by: dseagrav on July 23, 2007, 02:04:50 AM
The UMMU license is not compatible with the GPL, so we cannot use it unless we want to relicense the project. (The UMMU does not allow use unless your project is fully compatible with all of its features, which includes giving the crew jetpacks and parachutes. This restriction is not compatible with the GPL.) It's also not compatible with VS6, so we would have to force everyone working on the project to go buy new versions of VS.

The problem with using an MFD for communication is that you cannot "hear" the ground unless you are looking at the MFD. I wanted to use a text line because it's easiest to convert to text-to-speech later. The only ground voice the crew ever hears is the capcom, so we would only have to deal with one voice. As long as the TTS engine doesn't suck to hard it should work out.


Title: Re: Project Apollo MFD ideas & concepts
Post by: Swatch on July 23, 2007, 10:17:21 AM
Then in that case, why don't we do this a slightly different and hopefully better way...

  We can create the Virtual CapCom seperate from the MFD so that it can run the TTS stuff at all times.  We can then set up the MFD to access the Virtual CapCom's "buffered conversation" and display it, that way the transcript is easily accessable, but we're not limited to the MFD.  Additionally, we can have an option via one of the many Audio Switches that will turn on or off the seperate text-line display, which also accesses the Virtual CapCom's 'buffer'.  This way we have best of both worlds, both a running transcript via the MFD and a more immediate communication method via the text-line and TTS.  If this sounds acceptable, then I'll start work on that soon while I'm unable to work on the Virtual Cockpit (that computer is down in Cincinnati while I'm up in Cleveland working at NASA).
  In all honesty it shouldn't be too difficult to set up, mostly time consuming creating all the text-based communication lines with tokens to be replaced.  The rest will just be text parsing and writing to a file, followed by TTS/text-line/MFD interfaces that read from that file and 'speaks' to us. I figure that it will be easy to create a basic text file that you write lines from capcom to that way you have a transcript that is also legible to the computer.

Keep in mind though that there were many capcom's that did the mission....so having one voice is not quite accurate, but much easier to implement.


Title: Re: Project Apollo MFD ideas & concepts
Post by: dseagrav on July 23, 2007, 11:18:42 AM
Then in that case, why don't we do this a slightly different and hopefully better way...

There's a MCC routine in mcc.cpp that gets called once a timestep, and already does parts of AOS determination - That would be where you would put your code. Do it however you want, but make sure it's as event-driven as possible, that way we don't have to store times per-mission and handle failure cases and whatnot. I can clean up whatever you do later.


Title: Re: Project Apollo MFD ideas & concepts
Post by: Swatch on July 23, 2007, 01:03:07 PM
I was actually going to set up the following way....

One (or more) text file(s), possibly compiled into the code as a resource, but probably seperate to allow easy editing.  These store different text phrases that will be used in the mission, each defined by an ID of some sort, with provision for multiple, randomized phrases in the cases of common responses.  Within these phrases will be a method of defining tokens that will be replaces by such things as Spacecraft name, numerical values, etc.  Within the MCC code, I'll write a routine that is called to access the file(s) and find a specific phrase, whose ID has been passed in as a variable, along with any additional numerical values to be added to the phrase.  This routine will then print the phrase to the transcript file (a generic text-file that will also serve to record someones mission for later review) along with a sim-tymestamp and a flag character for use by whatever reads the file to tell it what kind of information the line contains.  This routine should be able to be called from anywhere within the Apollo code, so it will be up to you guys to place it at the proper events.  And of course, it will be affected by the audio subsystem panel controls....but maybe not at first.  At some point there will also be code written into the ProjectApolloMFD to provide display of the most recent lines in the transcript file.  Additionally, code will be incorperated to convert this text to speech (which, surprisingly enough, appears to be quite easy through the Windows API) and the text-line interface will be written, along with possible user-input recognition of keywords.

First I'm going to work on setting up a good format for the "phrase database(s)" and then set up some generic phrases.  Once I have a fairly robust identification method, I'll start incorperating the phrase parser and transcript writer into the MCC code.  Then I'll actually set about to working on the user-interface.


Title: Re: Project Apollo MFD ideas & concepts
Post by: dseagrav on July 23, 2007, 03:14:37 PM
This routine should be able to be called from anywhere within the Apollo code...

Don't do that. Please keep all MCC related things inside mcc.cpp, otherwise we'll have thousands of checks scattered everywhere for whether or not the MCC is active. Keep it in one place.


Title: Re: Project Apollo MFD ideas & concepts
Post by: Swatch on July 23, 2007, 03:55:29 PM
I may be missing something, but I fail to see what you mean by we need to check if MCC is active.  I figured that once the Capsule Communications code was implemented, it would be active all the time.

Anyway, there are definately ways to keep it all within one location, but it will require the code to be monitoring the simtime and capsule status, and I thought that was what you were trying to avoid when you said....
Quote
Do it however you want, but make sure it's as event-driven as possible, that way we don't have to store times per-mission and handle failure cases and whatnot.

Maybe I missed something here, could you explain what you were thinking?


Title: Re: Project Apollo MFD ideas & concepts
Post by: dseagrav on July 23, 2007, 07:05:10 PM
I may be missing something, but I fail to see what you mean by we need to check if MCC is active.  I figured that once the Capsule Communications code was implemented, it would be active all the time.
Not necessarily. It can (and should) be turned off when the user wants to do everything themselves - I.E. People who want to use IMFD, or fly non-normal-Apollo missions, or by US when we are debugging and don't want the interference, etc. The internal MCC will also be turned off whenever the external MCC is active.

Quote
Maybe I missed something here, could you explain what you were thinking?

I just meant don't rely entirely on the timer. Make a block of code for each MCC station, with a script of what that person would be doing at that phase of the mission. For each step of the script, watch for the event that person would be waiting for, then announce it and/or react appropriately. For example, during boost, the booster crew watches for S1C CECO. Instead of waiting for the "expected" time and blindly making an announcement, monitor the engine thrust level and make your announcement when it drops to zero. This keeps you from having to re-code your MCC if we change mission parameters,implement random failures, implement non-Apollo missions (Skylab, ASTP), implement distance-based voice lag, or something like that.


Title: Re: Project Apollo MFD ideas & concepts
Post by: Swatch on July 23, 2007, 07:52:17 PM

Not necessarily. It can (and should) be turned off when the user wants to do everything themselves - I.E. People who want to use IMFD, or fly non-normal-Apollo missions, or by US when we are debugging and don't want the interference, etc. The internal MCC will also be turned off whenever the external MCC is active.

I just meant don't rely entirely on the timer. Make a block of code for each MCC station, with a script of what that person would be doing at that phase of the mission. For each step of the script, watch for the event that person would be waiting for, then announce it and/or react appropriately. For example, during boost, the booster crew watches for S1C CECO. Instead of waiting for the "expected" time and blindly making an announcement, monitor the engine thrust level and make your announcement when it drops to zero. This keeps you from having to re-code your MCC if we change mission parameters,implement random failures, implement non-Apollo missions (Skylab, ASTP), implement distance-based voice lag, or something like that.


Ahh, now I understand.... but I'm not sure you understood what I meant by capcom code.  The capcom I was going to make is the a chunk of code that essentially creates CapCom's phrases.  It would then store these to a file.  Now within your MCC code you would call this code whenever an event is tripped and you would request the proper phrase.  Your capcom code would then "listen" to that file and when it detects a new phrase, it would handle displaying that to the user however the proper way to do that is.  I guess in proper terms, my code isn't so much CapCom as it is just a phrasebuilder.  In the immediate future, I never intended on doing anything that an in-game user would notice, that would be up to the ProjectApolloMFD and your internal MCC code. 

Perhaps I put too many ideas into my last post.  When I was talking about TTS and text-line stuff, that would go into your MCC code when you have it started.  And when I was talking about the running transcript in ProjectApolloMFD, that would be seperate from my phrasebuilder routines.  Both your MCC and the MFD could be controlled in whatever way they normally are, my routines that I'm working on are more of a background process.  Admittedly, they will probably eventually be merged into your MCC code since that's where the majority of the calls will be coming from, but until you create a project for it and start work on that I was going to write my stuff seperate.


Title: Re: Project Apollo MFD ideas & concepts
Post by: Tschachim on July 25, 2007, 10:47:35 AM
Admittedly, they will probably eventually be merged into your MCC code since that's where the majority of the calls will be coming from, but until you create a project for it and start work on that I was going to write my stuff seperate.

I'm not sure if I'm right, but reading dseagrav's post and looking at mcc.cpp (http://nassp.cvs.sourceforge.net/nassp/projectApolloSource/mcc.cpp?view=markup) it looks like the work already started and you should use the existing design. I think this is especially fine with your cool idea of a central transcript administration supporting multiple "clients" (MFD, DebugPrint line, etc.), but perhaps dseagrav could enlighten us here a little bit more...  :)

There's a MCC routine in mcc.cpp that gets called once a timestep, and already does parts of AOS determination - That would be where you would put your code.

Cheers
Tschachim


Title: Re: Project Apollo MFD ideas & concepts
Post by: Swatch on July 25, 2007, 12:37:04 PM
that's odd...I can't see mcc.cpp

I've done an update and its not there.....hmmmm.....  when was it posted?


Title: Re: Project Apollo MFD ideas & concepts
Post by: Tschachim on July 25, 2007, 12:43:36 PM
when was it posted?

It exists since February this year, it's in Orbitersdk\samples\ProjectApollo.

Cheers
Tschachim


Title: Re: Project Apollo MFD ideas & concepts
Post by: Swatch on July 25, 2007, 12:53:04 PM
Yea, I was looking through the capitalized letters....and it's lowercase.  I have it.   :Duh!39835:


Title: Re: Project Apollo MFD ideas & concepts
Post by: dseagrav on July 25, 2007, 01:49:30 PM
I'm not sure if I'm right, but reading dseagrav's post and looking at mcc.cpp (http://nassp.cvs.sourceforge.net/nassp/projectApolloSource/mcc.cpp?view=markup) it looks like the work already started and you should use the existing design. I think this is especially fine with your cool idea of a central transcript administration supporting multiple "clients" (MFD, DebugPrint line, etc.), but perhaps dseagrav could enlighten us here a little bit more...  :)

Well, it's everyone's project, so whatever happens is fine, as long as it works and isn't too ugly. I'm just trying to offer input, not direct the project.
I haven't hashed out all of the details yet myself, I just have a mental image of where I would like it to be.
That said, the script could be used for the ground as well, provided the ground does not have a person acting as their capcom. In that case, the ground software would be running the show, so it would have its own copy of the text file and send it as the capcom speech.

I totally encourage having a phrase database for the capcom. That would be far less work to localize later. We're going to have to organize a translation effort once the code gets banged out... I know we have at least French and German speakers here, I don't know what else. Of course, if a person is acting as the capcom, it is their responsibility to speak a language their crew can understand. ^_^

The reasoning behind the external MCC capability is simply that, if desired, some external process can turn off the internal MCC and substitute in anything they desire. The internal MCC should never become a limitation. Some people would like to play "what-if" scenarios or things like that, and the external MCC would allow them to make their own custom MCC to accomplish their goal without having to burden us with supporting their activity. The external MCC can be anything - a do-nothing routine that simply generates a debug log of capsule status, a totally automated program doing all of the tasks, a single person manning one (or several) virtual consoles, or even a set of real physical consoles installed in a classroom or museum. Of course, not all of this will be done before release, but that's my goal.




Title: Re: Project Apollo MFD ideas & concepts
Post by: Swatch on July 26, 2007, 05:09:56 PM
Hey dseagrav, I think I have a much better idea of what you were saying earlier.  Before I start on it though, I have a suggestion about the internal MCC and I want to know how you feel about it.

Right now you have MCC as its own super-class in mcc.cpp, but within that class all you are doing is the ground track stuff....  How would you feel about making another groundtrack class that inherits the MCC class and then I'll make a capcom class that inherits the MCC class as well, that way we globalize the MCC class a bit and make the addition of seperate functions within the scope of an internal mission control a bit cleaner to program?  The other thing this might allow us to do is to set up a method to selectively turn on and off the individual functions of the MCC from the External MCC, so that it's not an all or nothing type of thing.

If you want to see what it would look like, I went ahead and tested it to see if it would work, so I can post what I have here on the forums for you to look at and see if its good or not.

EDIT:

I attached the .h and .cpp file for you to get a good idea of what I changed.  if you like it I can commit what I have so far since it compiles correctly (there were 1 or 2 other changes made to other files).


Title: Re: Project Apollo MFD ideas & concepts
Post by: dseagrav on July 27, 2007, 11:35:13 AM
Sorry for the lateness of the reply.

That doesn't look bad. Go for it. Having a class for each MCC station would make it easier to standardize information flow between them and make it possible for someone to mix local and remote MCC.


Title: Re: Project Apollo MFD ideas & concepts
Post by: jc121081 on February 16, 2009, 04:20:52 PM
Here is an idea I had that has been stirring through my brain recently...

The GNC button in PAMFD has, in my opinion, the probability to house new potential. What I was thinking is maybe there could be a new set of options (buttons) to select after selecting the GNC button? Confused? Here is what I had in mind, clear and simple...

The GNC function would contain these new options that the user could select:
A "ORB" option
A "TLC" option
A "LOI" option
A "TEI" option
And a "TLC" option

Now I know that this may seem unlikely, but what if hypothetically each of these options, once selected, could ask the user to define option-specific desired trajectory or orbital parameters, each calling upon their own set of formulas to calculate burn velocities, then uplink the burn pad values to the vAGC?

Now again, it may seem like all of this may be way off in left field, so to speak, but the capability is there. If you take a look at our very own AGC++ coding, for example, some formulas are there to calculate from Orbiter's relative vessel position to determine orientation and resultant parameters. (Simple AGC programs 19 and the rendezvous programs for example). What if there were some way to take these types of code and modify them into different, mission phase specific formulas that could be incorporated into PAMFD?

Here is an example of how it would work:

User is flying Apollo 8 vAGC, prior to MCC1. The user would open PAMFD, click the GNC button, and then click the proposed "TLC" button (Trans-Lunar Coast navigation mode). PAMFD would display a blank screen similar to what we would see when we request burn data from IMFD. There would be another set of buttons the user would click to specify the desired trajectory parameters. During the TLC phase, the desired lunar pericinthion conditions are the variables, so the user would set values for the desired mission time of pericinthion, the PeA, Lat, and Lon. Once set, PAMFD would perform calculations based on Orbiter's relative vessel state vectors and the moon, and display the calculated variables into LVLH velocities that either A: Can be stored into the vAGC via P30, or B: be uplinked to the AGC in a similar fashion that our state vectors are, and performed from there.

Again, this is only an idea...


Title: Re: Project Apollo MFD ideas & concepts
Post by: Tschachim on February 17, 2009, 05:47:27 AM
PAMFD would display a blank screen similar to what we would see when we request burn data from IMFD. There would be another set of buttons the user would click to specify the desired trajectory parameters...

Well, given the complexity of this stuff the plan is to actually use IMFD for this as we're using it for TLI already. Currently PAMFD can request burn data for all the burns you listed including MCC's and display them in proper coordinates and units for P30. Next step would be automatic uplink of the burn data similar to the state vector uplink IMHO...

Cheers
Tschachim


Title: Re: Project Apollo MFD ideas & concepts
Post by: bluespace88 on February 17, 2009, 12:16:03 PM
I can work on the automatic uplink of the burn data. 


Title: Re: Project Apollo MFD ideas & concepts
Post by: Tschachim on February 17, 2009, 12:50:33 PM
Great!  :)

Please wait until I finished the source code move (almost ready), then we should discuss that in a new thread.

Cheers
Tschachim


Title: Re: Project Apollo MFD ideas & concepts
Post by: bluespace88 on February 17, 2009, 01:04:40 PM
ok, roger  :D