[16:57:26] NASSP Logging has been started by thewonderidiot [16:57:28] morning! [19:21:46] hey Mike [14:44:04] hey [14:48:39] hello hello [15:01:57] hopefully I get my document today (the avaliable parts at least) [15:02:15] I had confirmation that scanning was in process [15:04:25] oh awesome! [15:04:39] just a few parts of the full thing, right? But still, should be really interesting. [15:11:54] yeah, just 3 parts of the 22 total. still better than nothing though [15:12:14] yep [15:15:22] still researching CSM DOIs for the LDPP, I think I found a really helpful sentence in the Apollo 16 FIDO report [15:15:39] "The backup [15:15:39] computational technique of "a rendezvous with a phantom vector" was [15:15:40] utilized in order to achieve the nominal post-DOl orbital period to [15:15:40] minimize the probability of a GET update." [15:16:23] that tells me two things. This backup technique is still the same one like they used for the Apollo 11 LOI-2 [15:17:19] and the main technique can't control orbital period easily, which agrees with the main LDPP DOI calculation method which just kills the radial speed at the DOI TIG (setting up an apoapsis) and burns to achieve the height for PDI. [15:18:01] So I think that means they didn't implement a whole new complicated calculation mode for CSM DOIs, but instead made it work with the integrator (optionally) and not just the lunar AEG. [15:54:01] morning! [15:54:55] hey Mike [15:55:53] *quickly reads the CDU thead to be up to date* [15:57:10] hahaha [15:57:54] nothing new with the CDU itself, just really good progress on powering the resolvers. I'm getting nervous about all of the manual wiring so I'm switching gears to working on a connector adapter board [15:58:21] yeah, the equivalent of a code cleanup. It can work without, but it's a mess... [15:58:42] yeah, and with danger to damage irreplacable hardware [15:59:16] so it'll still be a bit yet before I get it fully running [15:59:49] totally unrelated, I picked up this document for Apollo 4 / CSM-017: https://www.ibiblio.org/apollo/Documents/FO-K-0007V1-SC107_spacecraft_ops_for_countdown.pdf [15:59:58] will be interesting to see an early version of that procedure for an unmanned mission [16:01:08] starting up the programer like a wind-up toy I imagine [16:01:57] so that it can act all human and throw switches :D [16:03:41] maybe the document has the EDS test by accident [16:03:52] that would be quite something [16:04:11] yeah, perhaps it hadn't been broken out to a different procedure yet [16:05:02] on the manned missions there were a bunch of manual steps still to do by the astronauts, they were just given via the launch control voice loop [16:05:15] were there even astronauts in the cabin on launch day hahah? I don't know [16:05:29] maybe they could only do the open loop parts of the EDS test [16:05:43] which would make it shorter and more likely to not be in a separate procedure [16:06:28] if I just get the exact sequence of blinkenlight stuff on the LV engines panel I would be very happy [16:09:29] I mean I can roughly derive it from the audio as the astronauts read back everything they see, but that's a very approximate method to get a sequence of test inputs [16:23:15] yeah astronauts in the capsule is a good question [17:21:38] one thing I do see in the pictures I have of it is that there is a banksum table that they were supposed to verify [17:21:47] finally an actual documented use of the banksum display feature lol [17:24:38] haha nice [17:24:45] it better agree with Solarium [17:25:33] yeah, if there was any argument left that Apollo 4 flew Solarium 54, Apollo 6 flew Solarium 55, and 54 and 55 were different.... this table will put that to bed [20:50:20] night! [16:14:12] good afternoon [16:39:43] morning! [16:45:55] hey guys [17:31:25] going to watch the Olympics opening ceremony and tomorrow I am travelling, see you Sunday evening! [18:06:13] good evening [18:32:27] hey Nik [18:33:37] nice ATM document [18:33:49] but it does cause appetite for more :D [18:33:59] also for LVDC EDDs, this clearly follows the same format... [18:52:57] the biggest thing I've gotten from a quick read, is that I want the other sections [18:53:14] lot of stuff on command words though [18:54:08] yeah, that is quite good [18:54:15] I would like especially sections 8 and 9 [18:56:32] it does cite some other documents that might be worth looking for [19:48:58] do they have any of them potentially, too? [20:22:35] I didn't see any on the list unfortunately. I'll ask though. [20:53:39] night! [14:01:00] hey [14:04:58] hey Nik [14:20:46] what's up? [14:30:59] not much, just trying to make it through thr week haha [14:35:37] kind of the same, bad headache day yesterday. I have some bugs to find/fix today that don't look too bad, relaxing enough :D [16:08:51] morning! [16:37:38] hey Mike [16:45:11] how's the bug hunting going? [16:45:55] well one "bug" I found. See Orbiter channel in Discord :D [16:46:21] oh hahaha [16:46:31] amazing [16:46:43] I thought it was a timing issue causing a downrange issue, I didn't bother to check SPEC 50... [16:47:30] HST mission, smaller inclination than EDW latitude, so I thought maybe the FDO MFD at least works with KSC. Calculate a deorbit for KSC, wanted to switch the landing site in the Shuttle computer and... it was already on KSC :D [16:48:13] Now I can transition to an actual bug, this time in the RTCC MFD [14:55:49] hey Nik [15:08:19] hello hello [16:36:35] morning! [16:41:55] hey Mike [16:49:50] feeling any better today? [16:52:25] Oh yeah, all good today. It's usually the same pattern with 1 day of headache and 1 day a bit nauseous and tired, maybe from the Paracetamol more than the headache. But day 3 is usually all good again, thanks for asking :D [16:53:07] excellent! [16:53:43] I've already rewritten the RTCC MED processing yet again, yesterday and today. I think it's an improvement, both in the way the code is now cleaner (and slimmer) and I am testing it now and there aren't terribly many bugs. [16:54:16] hahaha so chances of another rewrite tomorrow are low? [16:54:52] at least not a completely new system yeah [16:56:15] I started to use the new methods for all MED, but I can't be bothered to rewrite all that in one go, so I have only 15 that I am currently testing [20:23:34] night! [15:45:43] hey [16:48:19] morning! [16:49:52] hey Mike [16:50:02] what's up? [16:50:40] finished that MED processing PR, now I am trying to figure out what I wanted to do before I started that :D [16:51:09] hahaha so moving back down the project stack :D [16:51:50] good afternoon [16:52:05] hey Matt [16:52:22] yeah exactly, some backtracking projects [17:43:14] that Apollo 4 document should be arriving todya [17:43:16] *today [17:49:06] oh fun. Then we will see how much spacecraft operations and unmanned mission needs :D [17:49:12] an* [18:22:34] not sure if it will more or less than I think. should be interesting haha [18:23:05] plus a table of bugger words for Solarium, that almost certainly will contain new surprises but will be nice to have either way [18:29:03] no surprises or new surprises [18:30:17] oh I mean to say "no" [18:30:18] lol [18:30:33] but it will be one or the other :D [18:30:39] that tracks more with what I know about Solarium :D [18:31:12] from the pages I've seen it also seems like they were running an EMP [18:32:14] because they're messing with an erasable address is completely unused in Solarium [18:32:42] that kind of surprised me, such an early flight and Block I [18:40:25] also there is a page that contains the section "FIRE IN THE LUNAR MODULE" [18:40:55] which is an interesting section for Apollo 4 :P [18:47:49] uhh yeah [18:48:33] I mean, the LTA doesn't not look like a LM :D [19:39:13] night! [16:32:53] hey [17:00:53] morning! [17:02:03] that Apollo 4 procedure may have some EDS test stuff in it -- it was kind of hard for me to tell, I don't exactly what I'm looking for [17:02:24] but I at least didn't see a obvious callout to an external TCP [17:05:34] hey guys [17:09:00] hello hello [17:09:22] I have to search a bit more, but I at least see some things you would see in the cockpit from the EDS test [17:09:36] like that the LV rates light will be on 18 times [17:10:05] I think the math there is: triple redundancy, three axis and simulated overrrate either plus or minus [17:12:49] that makes sense! [17:14:07] I know from the (barely audible) MOCR recording of the EDS test that they also had a bit of a light show with the other LV lights [17:14:27] I have the EDS test document number, but I still think I just have to invent a procedure to run in NASSP :D [17:14:45] I think it would be fun to do [17:18:18] yeah it would! [17:18:30] I will continue to keep an eye out for the proper document [17:19:21] TCP-K-0042 [17:20:02] The one difficulty I have not solved is that there are steps of the EDS test that can't be timed but have to be done when a specific step was done in the CSM [17:20:34] e.g. closing a CB [17:21:36] maybe it could be done with a "deadline". If, by the nominal end time of the test, the LCC computer side of the EDS test wasn't completed then it just resets everything to the launch configuration [17:22:25] More realistic would be that you have to have a MFD open from which you control a few steps of the test, like the LCC personnel would [17:23:00] I will have to review it again, maybe it can just be run on a timed schedule actually [17:23:09] at worst you don't see everything happening [17:23:33] hmm but if we include it in the Checklist MFD then you would expect to see things and might be confused/don't continue [17:26:34] and where are the notes I already took of the Apollo 11 EDS test... [17:33:26] I'm trying to follow the ATOLL language with the test procedures, I'm sure there was a error detection method that could handle all this [15:35:59] hey [15:36:46] hey Matt [17:48:59] Are you following the "Skylab 1973 rebuild" thread on the forum at all? Anything relevant for the NASSP Skylab? [19:55:28] indy91, I have been watching it closely [20:02:31] I've been thinking about asking gattispilot (John iirc), if he'd have any interest in his mesh improvements becoming part of NASSP [20:28:58] sounds better than two different projects just doing the same work [20:48:16] night! [16:22:36] good evening [17:23:11] morning! [17:39:49] hey Mike [17:44:21] what's up? [17:46:03] doing some reading for upcoming RTCC projects. And you? [17:47:28] I have two resolvers hooked up to the trunnion channel of the CDU and it is solving angles :D [17:48:28] they're meaningless angles because I don't have the two resolvers coupled together yet. I'm working on the mechanical design for a resolver assembly now that actually makes one spin 16x faster than the other [17:48:48] but everything appears to be working [17:48:52] awesome [17:51:12] what does it need as input again? Isn't it 4 resolvers? 1x and 16x for sine and cosine? [17:55:20] two resolvers. each resolver has a sine and a cosine output winding [17:55:53] oh of course, I was just thinking in terms of inputs to the CDU haha [17:56:05] each of which is two wires, so that is 2 * 2 * 2 = 8 resolver wires per channel [17:58:20] these are the resolver connections: https://i.imgur.com/fawOE5L.png [17:58:30] red/black pairs are cosine, yellow/blue pairs are sine [18:20:54] now you need a system to input an angle that actually makes sense :D [18:21:44] preferably without having to manually do some sin(16xAngle) math [18:24:45] working on it! https://i.imgur.com/tIaLYgP.png [18:25:27] plan is to couple them together through a 16:1 reduction gearbox. and then potentially gear that to a dial or something, but step 1 is just getting the 16:1 relationship working well so I can make meaningful angles [20:57:27] night! [17:52:21] hey [17:53:43] morning! [17:54:51] I think I need a smaller RTCC project, my current ideas are too ambitious and time consuming :D [17:55:07] hahaha how many small project options do you have left? [17:55:55] there are plenty of user friendliness improvements that probably would be small RTCC projects [17:56:39] in terms of features, hmm, I guess I should add the additional RTE REFSMMAT options [17:57:29] a few things like that [19:51:35] hello [19:52:02] hey Matt [20:17:04] I fixed a little kg vs. grams issue in one of your commits in the big systems update, caused Apollo 13 venting thrust to be 1/1000 of what it should be [21:08:42] night! [15:18:56] morning! [15:28:12] hello hello [15:53:51] what's up? [15:57:15] haha I chose my next little project that I can actually finish in a reasonable time, the actual TEI search algorithm from the RTCC requirements for the RTE. Just something a bit better at finding not only a local optimum DV solution but the global minimum in a given timespan. [15:58:25] nice! that does sound like a nice little project :D [16:01:12] I think the algorithm in the document works (for once) exactly as it is written, but I will still go through it to understand it completely to add code comments and make sure there isn't actually a small error somewhere [16:04:11] hello [16:04:17] hey Matt [16:05:19] Yeah I think my current solution just works with an initial guess TIG and it finds a local minimum DV. Where the real algorithm as a min and max time, which could span multiple lunar orbits, and every orbit there will be one local minimum, but the algorithm can find the global minimum. [16:05:32] has* [16:09:17] thanks for fixing that venting thrust bug [16:09:44] ah oh no problem. Easily happens. [20:33:53] night! [15:46:04] morning! [15:52:01] hey [15:56:23] what's up? [15:57:28] I have noticed that I will have to be a bit careful with this new TEI search mode with the MCC. Previously it just found the optimum TEI that is the closest to the initial guess time, but now it will search the whole interval for the best solution. [15:57:54] so I already can't make the interval one whole orbit long, because it is quite likely that it finds a solution one orbit too early or too late [15:59:31] Maybe +/- 40 minutes will do. Initial guess time should be close enough to not run into those limits, but at the same time there isn't really a chance that it finds the solution on the wrong revolution. [16:01:45] Or I need something a bit more sophisticated. The MCC always knows for which rev it wants a TEI solution, so the MCC could use its current rev number and time since the start of the rev to generate a quite good initial guess time, the time when the rev for the TEI starts. [16:06:11] ah, overoptimizing the maneuver at the expense of the flight plan :D [16:06:24] yep exactly! [16:06:34] TEI one orbit later might be 10 ft/s cheaper [16:07:00] if it finds the global minimum in a given timespan it could find that solution instead [17:48:32] good afternoon [18:12:19] hey hey [16:18:14] morning! [16:30:33] hello hello [16:32:56] what's up? [16:36:30] not much haha. And you? [16:37:27] eating breakfast before getting started on soldering my CDU connector board :D [16:37:54] if you had to assign the colors blue and green to coarse error and fine error, which would be which? haha [16:40:55] Red, Green, Blue (RGB). Green comes before blue, coarse before fine. Green = coarse, blue = fine. [16:41:18] haha great [16:41:31] Q.E.D. [16:41:54] I had a similarly strange argument (blue and fine are both four letter words that end in e) but we ended up in the same place :D [16:43:30] seems like the natural choice then :D [16:39:47] hey [12:53:50] morning! [12:54:12] hey Mike [12:54:19] up early! [12:55:06] rockets do not care for sleep schedules :P [12:56:03] haha [12:57:14] Reminds me of the Apollo 12 stream, rest period on the first day starts at 18h GET [12:57:21] that is 18 hours after launch, not waking up [12:57:24] poor Turry :D [12:58:01] hahaha ouch [12:58:24] 12 is especially cruel, I guess it's mostly a sleep schedule adjustment [12:59:17] I've come up with a big new project, as if I need one... [12:59:52] oh boy, what is it? [13:00:39] standalone RTCC, but take the RT out of it. Well, I was thinking that Skylab and Shuttle ground-up rendezvous planning is quite similar. So I want to put some (a lot) of code together, everything already existing, from RTCC and Shuttle FDO to sort of plan missions. [13:01:35] standalone Visual Studio project [13:02:02] you input a target state vector somehow and you can plan stuff and get either SSV targeting or Saturn IB LVDC targeting parameters [13:02:16] none of this really needs to be inside of Orbiter [13:02:27] So it can be a separate project [13:03:12] What we can't do on the NASSP side yet is to find a good launch day to Skylab for example [13:03:26] check how many orbits from launch to rendezvous you need [13:03:45] tweak insertion parameters for the launch scenario etc. [13:04:51] maybe a bit like my tool for planning lunar Apollo missions, just for Earth orbit rendezvous only [13:05:30] but flexible enough to be useful for both NASSP and SSV [13:05:44] oh awesome! [13:05:57] sounds like a very useful tool :D [13:06:07] yeah, lots of fun custom missions to be had [13:08:37] I probably don't have to write a lot of new code for it, so it can be a project that just trails along [15:44:57] hey [15:45:11] hey Matt [15:46:59] morning! [15:51:52] hello hello [15:59:58] my long-term goal is to not be eventually not be on this 7-day work week thing, and have time again for projects...slow progress [16:00:40] that sounds like a healthy goal haha [16:04:00] ouch yeah, that sounds like something that should be a short-term goal [14:30:57] good morning [15:34:52] hey Matt [16:08:11] I am putting together an Earth orbit rendezvous planning tool. In a way it's a bit like the standalone RTCC we were talking about, but with a very limited feature set. [16:09:16] I am basically reusing lots of stuff I already have, currently porting the Orbital Maneuver Processor from the Shuttle FDO to it. [16:09:43] One problem remains with it being independent of Orbiter, how to best get state vectors into it. [16:11:30] I will probably have to support multiple input methods [16:11:44] One way would be copy and paste from Orbiter scenarios, so that is J2000 ecliptic, left handed. [16:12:04] More useful, especially for the target vehicles, would be TLE support. [16:22:12] morning! [16:30:39] hey Mike [16:33:18] what's up? [16:36:53] porting FDO MFD code to a standalone VS project for pre-mission planning for Skylab, ASTP, Shuttle missions [16:37:08] there is surprisingly little that really depends on Orbiter [16:37:39] oh that's nice :D [16:37:44] I had some old code that uses the Orbiter API to get sun vectors for sunrise/sunset calculations, that's the one major change required [16:38:36] are any of these changes going to be pushed back to FDO MFD or are you going to mostly leave that as-is? [16:39:09] I am seeing some bad code that I might want to improve, yeah haha [16:39:59] I think I want to add support for drag [16:41:11] The SSV aerodynamics model goes to zero drag coefficient above 150km though :D [16:41:44] I guess they didn't want to bother with the orbital drag effects for rendezvous and such [16:44:50] that might be easier to add once OpenOrbiter is released [16:44:57] the aerodynamics that is [16:45:40] oh? What has OO changed for aerodynamics? [16:45:56] ah I remember now [16:46:07] CreateAirfoil4 [16:46:31] This issue with airfoils not really working well at 90° slip angles [16:47:00] that you fixed haha [16:47:09] yep :) [16:47:27] While that is annoying, for trajectory propagation they often simplify things. [16:47:42] The OMP just uses a hardcoded CD of 2.0 [16:47:46] fixed area, too [16:48:22] But that is for targeting, the integrator has the capability to take the Shuttle attitude timeline into account [16:48:31] variable area [16:49:09] So if SSV just had a hardcoded CD independent of attitude, for my targeting purposes that would be good enough [16:50:37] Even with your new airfoil, I am stil unsure how to handle docked vehicles though [16:50:53] One reason why I still haven't set CSM and LM drag to 100% in NASSP [17:01:59] Yeah that's going to be both very orientation dependant and very kundsen number dependant [17:06:16] for high Kn it could almost be done by multiplying drag coefficient by 1-dot(velocity, docking axis) [17:14:41] hmmmmmmm OpenFOAM has a DSMC solver.... [17:15:36] checks ram and cpu cores [17:19:24] I am mostly worried about the logistics of the two separate aerodynamics forces in Orbiter [17:20:16] of the two vehicles [17:20:30] Their "normal" airfoil will be the vehicles alone [17:20:38] but when docked they can't be independent [17:20:49] not just drag force, but torque from the drag, too [17:21:12] Was apparently noticable on Apollo 9 in the out-of-plane attitude for the docked DPS burn and such [17:22:11] But if you are flying in a prograde attitude you have a smaller area, then the undocked aerodynamics would be about 2x too strong [17:23:01] I think my simple concept would be that the airfoil function checks if you are docked and if the other vehicle is "in the wind" instead of yourself [17:23:31] if the docking port is used and pointing into the wind then your own contributation to the drag goes to zero [17:23:59] essentially you would get only the drag force from the vehicle that is pointing forward [17:24:06] maybe that concept would work [17:24:23] at least well enough that the combined drag is not totally random or off [17:36:20] that's exactly what I was thinking [17:39:13] While not perfect, it just has to be about right over time [19:07:07] cya! [15:00:13] morning! [15:22:45] hey [15:22:48] what's up [15:24:45] lots of progress on the CDU :D [15:25:23] I got the CDU->AGC pulses and read counter zeroing working last night [15:25:47] and also enabled the error counter for the first time and was able to set it to different values and observe the effects on the AC D/A output :D [15:26:01] next up is enabling the DC D/A output [15:47:06] that's awesome [15:53:50] and you? still swamped with work? [15:55:13] hey guys [15:55:18] oh wow, nice :D [15:56:39] D to A is where the real fun is [15:56:59] uhh [15:57:14] wait, what do you mean with AC vs DC [15:57:28] I got my letters confused [15:59:40] are the two possible sets of outputs in one case DC and the other is AC? [16:00:38] indeed! [16:01:01] attitude error out to the FDAI is AC, and analog output to the TVC or crosspointers is DC [16:01:25] or FCC [16:01:38] fun, I never knew that [16:01:54] yeah I didn't either haha [16:03:11] I need to flip a relay in the mode module to allow DC error out, hopefully its contacts are still good [16:05:38] I think that relay is getting directly powered by the IU (through CSM switch contacts) in the case of the CSM ICDUs [16:07:12] oh yeah, you're right [16:07:25] "S/C CONTROL OF SATURN SWITCHED 28V" instead of an internal 28V connection [16:08:48] I think the equivalent relays for TVC are also powered externally from the CDU in the CM [16:12:48] yeah, but controlled by an AGC output bit I think [16:12:52] for RR, too [16:13:25] there's an AGC output bit also required in all circumstances [16:13:39] power for the relay vs. actually flipping it [16:13:49] we don't use our CDU class for our IMU yet, so it seems I took a shortcut and don't simulate this relay separately, just controlled by the output bit [16:14:04] for optics and RR [16:14:42] for RR the relay is actually powered internally to the CDU [16:15:47] I see a derived class for ICDU vs the others coming [16:15:54] hehehe [16:19:49] so for this relay in the OCDU (TVC output)... power actually goes through a bit of a chain [16:20:04] it's derived from +28VDC IMU OPERATE [16:20:42] which is switched through the S/C control source switch on panel 1 (SCS/CMC must be in CMC) [16:21:09] and then it goes through the THC which needs to... I think not have a clockwise rotation [16:21:20] and then finally arrives at the CDU and gives power to the relay, allowing the CMC to flip it if it wants [16:22:31] yeah makes sense with the SC CONT switch and THC, which control mode is used is always determined by those two [16:25:13] any plans to get a simple simulation of the connected device(s) going? IMU, RR, or optics? [16:25:22] just so that it returns some signals [16:25:29] and current angles [16:25:51] unfortunately nothing is so simple :D [16:26:28] haha [16:26:54] my main goal right now is to build up a mechanical contraption that actually gets these two resolvers into a 16:1 relationship [16:27:10] so I can turn them without the read counter completely freaking out and losing the angle [16:27:55] and then if I want a device simulation I might need to have motors to drive that contraption? [16:28:12] it'd more or less be building mechanical stand-ins for them lol [16:28:17] unless you meant other signals [16:29:01] ah so you want to have it mechanical as much as possible instead of software, makes sense [16:29:19] would be fun to try a mini RR with it or so :D [16:29:22] drive* [16:29:50] I would do it in software if I could! but the electrical signals required are not easy to make at the voltages and frequencies the CDU wants [19:09:02] thewonderidiot, yes, I just need to add like 3 people to my team, but that is also, unfortunately, more work [19:29:15] oof yeah that is a tough spot [19:51:13] cya! [14:26:57] good afternoon [17:39:14] morning! [17:53:06] what's up? [17:54:40] should be all wired up to get DAC DC out of the CDU [17:55:12] and I think I have a (somewhat dumb) plan for replacing the jacking screws [17:55:30] and if that works out, I'll probably go ahead and install all of the rest of the malco pins on the connector plate [17:56:06] they're actually not hard to remove, which makes me feel less bad about using up a limited resource [17:58:37] time to find a cross pointer :D [17:58:56] or really just some device that shows the DC output [18:10:53] hahaha I could get a little meter or so :D [18:11:07] but for now it will just be a voltmeter or oscilloscope haha [18:12:39] cross pointer is just a 2D voltmeter anyway [18:26:04] I got the Orbital Maneuver Processor from the FDO MFD working as a standalone program now [18:26:26] Testing it with a Skylab 2 rendezvous profile and some state vectors from a scenario I had [18:27:35] Because I am so talented in writing GUIs I instead use text files with the required inputs [18:27:46] so maybe that becomes a command line version :D [18:29:07] next up would be the launch window processor. I have a RTCC and a Shuttle version that slightly differ, I guess I should use the NASSP version as a basis, that has less extra stuff I don't really need for now [18:30:13] some day I still need to get the Skylab launch targeting document from NARA, I really had to piece that together from multiple sources [18:38:34] oh nice! that was very fast [18:38:43] I guess no GUI helps speed things up :D [18:38:53] haha yeah [18:40:29] barely any new code to write, anything that was different I could just put in a wrapper function [18:43:30] still have to do a lot of cleanup, add a few smaller features and write the OMP output to a text file. Just formatted like the real display, this part I cannot really take from MFD drawing in Orbiter. [20:24:08] night! [17:30:40] morning! [17:32:34] hey Mike [17:38:04] what's up? [17:39:23] https://i.imgur.com/t2XCXOv.png [17:40:03] ooooooooooooo nice :D [17:40:19] Written to a text file which is of course very different from the FDO MFD printing on the MFD. Formatting the individual parts of this is still like the FDO MFD though. [17:40:32] looks great! [17:40:56] Here an example from the Shuttle FDO Console Handbook: [17:41:11] https://i.imgur.com/KZkVUft.png [17:41:30] I can follow this very closely [17:42:00] this is actually a text file format as well, some examples in the handbook are shown in a computer window [17:42:52] https://i.imgur.com/ryYR3Mr.png [17:43:04]